Работаем над клиент-серверной версией движка IDE.
Все поддерживаемые IDE и Nitra.Visualizer будут работать с ним.

В последних сборках изменился API поддержки проектов. Для просмотра проектов которые еще не переведены на новый API используйте ревизию Найрты с тегом BeforeRemoveReSharper (80ef49d903613bb0d7007eb93ad2efc71de69575).

Введены четыре новые сборки:
Nitra.ClientServer.Server.exe — Nitra-сервер. Сама Nitra и языковые сборки грузятся в него.
Nitra.ClientServer.Client.dll — клиентская сборка инкапсулирующая взаимодействие с сервером.
Nitra.ClientServer.Messages.dll — интерфейсная сборка содержащая сериализуемые типы используемые для передачи данных между клиентом и сервером.
Nitra.ClientServer.Macros.dll — вспомогательная сборка с макросами (сериализации и прочие). Конечным пользователям ненужна.

Клиентские процессы (IDE, Nitra.Visualizer.exe и Nitra.TestsLauncher.exe) загружают только сборки Nitra.ClientServer.Client.dll и Nitra.ClientServer.Messages.dll. Их интерфейс очень простой, но исчерпывающий. С их помощью клиент делает запросы к серверу (передавая ему информацию о солюшене) и получает обратно ответы с данными (подсветка, фолдинг, список ошибок, информация об индетификаторах и т.п.).

Взаимодействие между клиентом и сервером ведется через именованные каналы по средствам сообщений (из сборки Nitra.ClientServer.Messages.dll). Есть основной канал работающий в основном на прием, но позволяющий, если надо, отдавать данные в синхронном режиме (это надо для фич вроде получения данных для подсказок и т.п.). Так же есть канал предназначенный для асинхронной передачи клиенту вычисляемых сервером данных (подсветка, фолдинг, ошибки, ...) об активных файлах.

Активный файл — это файл открытый в редакторе кода и отображаемый на экране. Их может быть более одного.

Преимущества такого подхода:
1. Меньше проблем с клинчем сборок (разными версиями т.п.).
2. Проблема блокировки сборки при перекомпиляции решается простым срубанием процесса.
3. Не будем толкаться в студии с Roslin и ReSharper. Студия по прежнему 32-битная и когда выйдет 64 битная не ясно.
4. Проще отладка, так как в процессе сервера нет лишнего кода (студии, решарпера и прочих плагинов).
5. Есть четкое разделение на презентационную логику и контроллер, роль которого выполняет сервер.
6. Работа клиента теперь полностью асинхронна. Пока сервер "шуршит" пользователь может менять код или переключать файлы.
7. Это позволит нам в будущем сделать Веб-IDE и Веб-песочницу для популяризации Нитры и языков поднятых на ней.

Минусы:
1. Для отладки приходится цепляться к другому процессу, даже если отладка идет в Визуалайзере.
2. Коммуникация между сервером и клиентом существенно дороже нежели прямой вызов. Надо контролировать размер передаваемых данных. По сему передаваемые типы фактически сводятся к примитивным и используется реляционная модель (как при работе с БД). Например, вместо использования строковых путей к файлам для их идентификации используются числа. Тоже самое происходит с рядом других строк и типов. Например, с типами описывающими SpanClass-ы.

На сервере массово используются рабочие потоки (по одному на физическое ядро), так что фалы обрабатываются параллельно. Чем больше у вас в системе процессоров, тем потенциально быстрее будут у вас работать нитровские языки.

Hardcase занимается переводом самой Nitra на новый движок типизации. Так что как только он закончит и доведем новый движок до ума у нас будет и интеграция для самой Нитры.

На сегодня сервер уже:
1) загружает проекты;
2) парсит файлы;
3) производит семантический анализ (типизацию) проектов;
4) выдает информацию для фолдинга и подсветки (ключевых слов и символов).

На очереди:
1) информация об ошибках.
2) Поиск вхождений символа.
3) Переход к определению символа.
4) Автодополение идентификаторов.
5) Правка генератора интеграций так чтобы сгенерированный код использовал новый клиент-серверный движок, т.е. перевод на новый движок плагинов к VS.

Хинты (для символов), рефакторинги и т.п. требуют больше работы, так как не были реализованы ранее.