Станислав Макаров

> экземпляр класса и обьект выходит тоже разные вещи?
К сожалению, в рамках современной терминологии и с учетом разнообразия объектных моделей сложно ответить однозначно на ваш вопрос. Скажу так: если у вас статически-типизированный классовый язык (class-based, т.е. C#/C++/Java), то всякий объект - всегда это экземпляр класса, но в других языках и объектных системах может быть по-другому. Чтобы получить конкретный ответ, нужно точно знать о каком языке идет речь.
Вообще, небольшая разница есть и между самими терминами: объект это прежде всего черный ящик с identity и некоторым известным интерфейсом, и вовсе не факт, что этот объект "создан по чертежу", как сказал brainick, однако если рассматривать классы как множества, то во многих языках есть понятие корневого класса в иерархии (класса object или "класса всех объектов"). Вот если такое понятие существует, то тогда можно сказать, что любой объект является экземпляром класса object.

> третья суровая разработка на кроссплатформенном C++ (опять же ближе к миддлу)
Чего же вы ждете? Это штучные вакансии, черт возьми!

Я часто советую взять что-нибудь из реальной жизни и автоматизировать. Я вот, к примеру, так и не нашел для себя удобной домашней бухгалтерии - чтобы вбивать чеки за день максимально быстро (с автодополнениями всякими), и считать простейшую статистику - набросал за пару вечеров сам. То же и вам советую - может вы любите что-то, спорт, или игры какие - нескончаемый источник статистики, графиков, и данных. Поставил личный рекорд стометровки - открыл прогу, забил инфу.
Если любите книги - то можете потренироваться в автоматизации личной библиотеки.

@Mr_Sinister
> но он создает кучу объектов
безусловно, библиотека библиотеке рознь, но если вы всерьез заморочились производительностью этой де-факто стандартной JSON-либы, то:
0) вы ищите проблему производительности там, где ее нет (а есть в другом месте)
1) самое время все-таки протестировать, и написать свое, более подходящее (редко, но бывает и такое)
2) вам не нужен JSON, возьмите protocol buffers
3) вам не нужен C#, возьмите C++

Направление мыслей верное, с технической точки зрения тоже. Не уверен насчет необходимости обновления апдейтов и делитов - если вы уже проверили UserId и выяснили, что запись принадлежит конкретному пользователю, и получили ее Id - то и удалять уже достаточно только по Id (за исключением, конечно, случая, когда вам нужно удалить ВСЕ записи конкретного пользователя).
Правильность этого варианта зависит от вашей задачи. Если вам достаточно знать пользователя-владельца - то все хорошо, но если вы потом захотите более сложную систему доступа к записям - например давать и другим пользователям доступ к записям пользователя A, то и схема базы также усложнится.

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

Может попробуем решить более общую задачу? Вам зачем показывать диалог в потоке? Что в принципе это даст?

Возможно я не понял вопроса, но так или иначе в метаинфе о классе есть инфа об интерфейсах, которые он реализует (было бы странно, если бы ее не было :)). Т.к. указана и сборка, и полное имя интерфейса, и IDE-шкам ничего не мешает идти по дереву типов и смотреть где что есть.
Оффтоп: т.к. "наследовать" из интерфейса нечего, принятно говорить, что интерфейс "реализуется" (implemented) классом, чтобы подчеркнуть отличие от наследования, когда помимо установления отношения is-a классом наследуется и какая-то реализация. То, что в описании класса и базовый класс и интерфейсы перечисляются в одном списке не значит, что суть одна и та же.

Можно сделать линки на файлы в другой папке, в 2015-й студии появились Shared-проекты - это проекты, которые не компилятся в привычном понимании (в отдельную сборку), а "инклудятся" в каждый проект, который на этот shared-project ссылается. Однако,
> чтобы избежать создания лишних *.dll библиотек?
в чем собственно проблема? Под разные дотнет можно скомпилить, сделав разные конфигурации проекта, это нормальная ситуация. Вам нужно, чтобы один exe-шник был строго?

Попробуйте поработать с этим флагом: https://msdn.microsoft.com/en-us/library/system.di... , т.к. вам нужно выполнять запрос к AD асинхронно.

> Не каждый пользователь будет его устанавливать.
Кто еще не установил - тому стоит это сделать, MS даже через апдейт систему предлагает дотнет поставить. А еще фишка в том, что и программам на плюсах в подавляющем большинстве случаев приходится ставить райнтайм. Конечно, его dll-ки можно просто положить в папку с программой, но это плохой путь по ряду причин. Итого, и для шарпа и для плюсов нужно ставить "среду", единственное отличие - рантайм плюсов будет легче (правда сама прога, юзающая Qt и включающая его библиотеки будет значительно тяжелее).
> На сколько я знаю, на семерке "из коробки" стоит 3 версия фреймворка
Тройка - на Висте, на семерке - 3.5.
> Так что же лучше - использовать C# или посмотреть в сторону C++ и Qt?
Тут обычно гораздо важнее вопрос кроссплатформенности. Сейчас Mono обеспечивает только WinForms, т.е. того же WPF на никсах пока не видать (и видимо уже не увидим). Поэтому я сейчас безоговорочно выбрал бы Qt, если б делал десктоп-софтину не только для винды (в 2015 году лично я не могу относиться к функциональности и CPU-oriented архитектуре WinForms всерьез). Поэтому решение принять достаточно просто:
1) если у вас line of business-приложение (напр., очередная утилитка для расчета кредитных условий по продуктам банка) и windows-машины в парке - смело берем C#, WPF, и решаем поставленную задачу;
2) если у вас приложение для широкого круга лиц, и его интерфейс сложнее интерфейса перекодировщика WAV в MP3 - берем Qt, пишем код без и получаем приложение, которое запустится на большинстве десктопных машин, а не только на тех, где винда.

P.S.
1) безусловно, есть и более чем приличные коммерческие десктопные программы на шарпе, например очень удобный и навороченный референс-менеджер Citavi, но я думаю её авторы просто приняли решение поддерживать только винду, и это их устраивает. Кроме того, они используют много сторонних платных GUI-контролов у себя в продукте.
2) реализовывать взаимодействие управляемого и нативного кода не так уж приятно, поэтому если ключевая библиотека реализована на плюсах, то и остальное приложение логично сделать нативным.

> На что мне нужно смотреть для оценки общей производительности?
сами себе уже ответили - смотреть, какой код тратит больше всего времени процессора. На ваших скринах все это есть, в процентах и миллисекундах. Вот берете вызов ProcessDirM, у которого 60+%, и раскрываете дерево вызовов, смотрите, кого эта функция вызывала, и у кого также макс. время и так до тех пор, пока не поймете куда эти 60% растрачиваются.

System.DirectoryServices.AccountManagement - более подходящего для вашей задачи набора классов не найти. Статья с автопереводом, поэтому если совсем ничего не понятно, берите этот неймспейс и вбиваете в гугл. Советую как можно быстрее начать исправлять потребность в русскоязычных источниках.

> выкидывать полученные знания на помойку и начинать все с начала
ничего вы никуда не выкинете. На плюсах вам просто чуть больше решений придется принимать самому, и дисциплина, скажем так, строже. Главные Знания - это методологии разработки, алгоритмы и общие навыки по написанию и отладке кода. В конце концов вы не на Хаскелл переходите, и даже не на F#, а на язык, который на основе плюсов был создан. Если после перехода вы все же скажете, что выбросили все знания на помойку, то видимо их и не особо много было.
Конечно, есть стандартная библиотека .net, CLR и прочие платформенные вещи, но в современных реалиях и так приходится постоянно что-то новое учить. После бума джаваскрипта в последние 5 лет отрекаться от этого факта бессмысленно.