Senture, можно сделать так: определите соль как ID-шник юзера(он вроде бы как long - 8 байт), он для всех строк в таблице уникален. Так вы избавитесь от лишнего поля salt в объекте, правда это не совсем корректно в том смысле что для создание нового юзера придется делать сразу две операции - создание и обновление объекта в базе(ибо ID вы получите лишь сохранив новый объект в БД). Решайте сами что для вас вернее будет.
anelegalniy, тогда вариант - не включать его в репозиторий (gitignore) и переложить эту ответственность на разрабов, пусть сами ручками настраивают как им надо
А вот это лучше не надо=).
Покурите про TPL, перепишите код с использованием этой библиотеки.
Ну или как я уже написал в ответе - юзайте асинхронку через старые добрые(неудобные) Begin/End операции.
(по сути вам тот поток с MessageDecode уже будет нафиг не нужен)
Ilya Smirnov: значит перепиливайте/отлаживайте алгоритм. Я не в курсе что он у вас делает и указал лишь на суть ошибки (ну и возможное её решение, которое по видимому не подошло). Полагаю вы этот алгоритм где-то стянули, не разобравшись как он работает. Либо написали сами но запутались в нём.
В общем удачи вам в отладке=)
BadCats: Правильно. Первое объявление массива идёт в контексте класса MainWindow. Этот массив ничем не инициализируется, поэтому null. Второе объявление с инициализацией - в контексте конструктора MainWindow. Это два разных экземпляра массива. Полагаю вам нужно в конструкторе убрать определение типа VideoArray
CompositionTarget[] VideoArray;
// затем
public MainWindow()
{
InitializeComponent();
this.VideoArray = new CompositionTarget[MyMedia.Source.UserInfo.Length];