AxisPod

Поглядите JWT это стандарт, не совсем готовое решение.

Увы байт не имеет за собой квантовой основы и сохранить в одном байте 256 чисел одновременно вы не сможете.

Все хэш-функции подвержены коллизиям. Есть смысл сравнивать размер, затем хэш и уж если они равны, то сравнивать целиком файлы.

Запускайте второй поток. Thread, BackgroundWorker и т.д., но напрямую с формой работать из второго потока нельзя, тут копать в сторону Dispatcher.

Вот не знаю как в .NET, но помнится в WinAPI есть механизм определения размера в пикселах для блока текста. В итоге берем размер пробела, берем размер каждого слова и вычисляем. И в данном случае будет правильно работать с символами разной ширины. А посимвольно только для моноширинных шрифтов.

Межпроцессное взаимодействие (IPC), механизмов море. Ну и какой вопрос, такой ответ. Сами не пытались взглянуть со стороны и подумать, возможно ли что-то понять?

В XAML это делается на ура, а вот в дизайнере не стоит, но и в коде не стоит оставлять.

И как вам процессор не жалко? Будет 100% загрузка на ядре. Хотя бы паузу поставьте в 100мс к примеру в while. А на деле я так понимаю, что там уже внутри реализована вся работа как надо и отдельный поток не нужен.

Если взять Рихтера по .NET 4.0, то там ошибок столько, что лучше русскую вообще не читать, часто просто блоки текста скопированы и повторяются. В Dragon Book к примеру отсутствуют прям целые абзацы. Так что подобные ошибки это нормально.

Я бы не советовал начинать с данной книги, много тонкостей, но при этом далеко не все базовые вещи есть. Начинайте с чего-нить попроще. Албахари к примеру или Шилдта. Вот как с ними разберетесь, тогда можно и за Рихтера браться. А смысла колоться и продолжать есть кактус я не вижу.

Используйте https://msdn.microsoft.com/ru-ru/library/system.wi...
Ибо из другого потока UI обновлять нельзя и MS для этого сделала готовый инструмент. Да и велосипеды не требуются в этом случае.

Не буду отвечать развёрнуто, уже ответили нормально.
5. Единственное на что можно на старте посмотреть, это MVVM Light, он упростит рутину, но при этом оставит стандартную архитектуру. Prism на старте вообще брать нельзя, мозг сломаться может, да и при этом позволяет реализовать только типовые проекты, опять же с кучей магии. Catel тоже монстр, он мне куда больше нравится, чем Prism, более гибкий. Caliburn Micro главное зло MVVM, для мелких проектов может и подойдет, но большие проекты с ним поддерживать очень сложно будет, ибо нет явных связей, всё построено на магии внутренней реализации.

С Prism и Catel познакомиться надо обязательно, но не сразу. Caliburn Micro лучше даже не трогать, не засорять мозг.

С архитектурой явная проблема. По хорошему в таком случае надо работать с интерфейсами по возможности и использовать ковариантность/контравариантность.

Частично metanit.com , всё коротко и по делу.

Ну если достаточный уровень знания английского, то зачем русская книга? Если же нет, то о каком собеседовании на английском может быть речь?

Слабо верится, что встроенный будет функциональнее autofac, да и уж если привык к autofac, что-то другое использовать не хочется.

А зачем 3 окна, почему бы к примеру не использовать Wizard диалог.

Как вариант AutoFixture.