@wlastas

Как правильно организовать два Solution с общим проектом, чтобы...?

Суть проблемы наверное в кривой архитектуре:
есть два Solution, в каждом из которых подключен один и тот же общий проект, условно наз Core.
Server_Solution = (условно Server(с#)+Core(с#) ) отлаживается и запускается на сервере.
Client_Solution = (условно Client(с++)+Core(с#) ) отлаживается на сервере, запускается на удаленных клиентах - условно игровой бот с AI, запущенный на GPU VPS/VPS
Все проекты обоих Solution собираются в одну папку на сервере: условно \\server\c$\bin
Каждый клиент отслеживаются изменение версий файлов в Client+Core, и автоматически перезапускается при принятых(утвержденных) обновлениях в режиме отладки из VisualStudio 2019.
Сервер запускается в режиме отладки из VS на \\server
При нахождении глюков в работе какого либо клиента на сервере вносятся изменения в "Client", и иногда в "Core"(условно добавляются новые фичи, изменяются старые) проект Client_Solution пересобирается. Тестовый Client видит изменения и перезапускается. Остальные работают на старой версии.

Проблема:
Я не могу пересобрать Client_Solution не выключив работающую Server_Solution, так как она содержит тот же Core проект, который уже запущен из \\server\c$\bin как Server_Solution.
Но мне надо, чтобы сервер продолжал работать со старой версией, чтобы я мог интерактивно наблюдать разницу поведения старых и новых клиентов. Также сервер не желательно перезапускать, так как он содержит условное "состояние мира".
Вопрос;
как правильно организовать размещение файлов\структуру Solutions \ процесс отладки в моем случае.
Возможно надо сделать два независимых "Core", которые будут как-то синхронизироваться, но это жуткий доп геморрой, так Core на самом деле микс из 10+сборок, которые также обновляются.

PS варианты с контролем версий не предлагать, так как у
меня есть отдельное приложение которое закачивает измененные .cs/ .cpp с сервера и пересобирает из них Client_Solution ​на клиентах - мне удобно только так и всё устраивает.
  • Вопрос задан
  • 190 просмотров
Решения вопроса 1
@wlastas Автор вопроса
Правильным решением оказался вариант, предложенный
Евгений Шатунов Куратор тега C++

У тебя конфигурация сборки неправильная. Твои Intermediate и Output Path должны быть строго относительно $(SolutionDir). Никаких абсолютных путей. Никаких путей относительно проекта. Никаких висящих в воздухе путей. Все должно быть строго от корня солюшена.
В этом случае один проект, открытый в двух солюшенах, будет иметь разное рабочее окружение. Только так проект не будет мешать сам себе в разных солюшенах.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
vabka
@vabka Куратор тега C#
Токсичный шарпист
В вашем случае, я бы держал все три проекта в одном sln.
Если очень хочется два решения - скопировал бы Core
Ответ написан
BasiC2k
@BasiC2k
.NET developer (open to job offers)
Запуск продакшен из Debug/bin не очень хорошая идея. Продакшн должен публиковаться и крутиться на сервере. А версия из Debug/bin должна запускаться только IDE VS.
Понятно, что Вы уже к чему-то привыкли, но лучше привыкать к общепринятым шаблонам.
В Вашей ситуации стоит:
1. Начать публиковать рабочую версию (продакшен, релиз) на сервере;
2. Реализовать логгирование в БД, чтобы понимать - что происходит;
3. Продумать - как работать с отладочной (Debug) версией кода. И как потом ее беспроблемно релизить.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы