Как обеспечить зависимость от проекта другого решения в visual studio?
У меня есть программа, которая имеет решение.
В результате возрастания числа независимых друг от друга модулей (программа также не зависит от них, ведь импорт идет по ходу запроса). Решено выделить их в проекты.
Проектов много. Например я хочу редактировать определенный модуль, но я не хочу перебирать проекты других модулей. Есть фильтр решений, но он не обеспечивает удобное с ними обращение, потому что это будет плодить огромную кучу .slnf файлов.
Я подумал, почему бы не сделать модули программы - проектами в других решениях.
Но есть проблема - у них есть зависимость от самой программы (точнее от dll, которая обязательна для программы, и она тоже отдельный проект). Если я в решение модуля добавляю проект решения программы, то я могу через решение модуля менять код проекта самой программы.
Как правильно добавить зависимость?
Для каждого проекта придется делать репозиторий? Нельзя ли такое сделать для решения?
Плюс как избежать копирования проекта в проект при git-submodules (чтобы копировался как проект наравне с существующими)?
Будет ли CMake хорошим решением для микросервисов?
Илья Голец, есть ехе с зависимостью от dll (назовем ее базовой). Базовая dll дает интерфейс для самого ехе и для dll-модулей.
У меня решение, где лежит проект ехе, проект базовой dll и проект модуля-dll. В будущем будет больше модулей-dll. То есть в решении будет больше проектов и они буду огромным списком. Плюс хотелось бы разграничить решение модулей от решения ехе+базовая dll от модулей-dll (ибо в модулях уже свои проекты могут добавиться). Если ничего не предпринять будет месево из ехе, базовой dll, dll-модулей и других проектов, нацеленных на работу с dll-модулями.
CMake это вопрос относительно вашего ответа в пункте о микросервисах.
slnf я не хотел бы принимать ибо модули могут писаться не мной и в других репозиториях.
Павел Соколов, приведенное выше описание напомнило классический шаблон проектирования Плагин — если модулей будет много, может возникнуть желание иметь возможность подключать модули без пересборки основного приложения.
Илья Голец, у меня в модулях-dll есть классы наследники классов базовой dll. В случае плагинов там действия не связаны с клиентом - нет зависимости от клиента, зависит только от действий клиента.
В базовой dll есть абстрактный класс basicfunction, который имеет внутри себя поля для описания логики, все остальные импортируемые классы (в модуле-dll) должны быть его наследниками, ибо хранятся как basicfunction* в векторе базовой dll.
у меня код на С++ (не знаю, зачем убрали тег), а для NET я нахожу только VB, C#, а для С/С++ только упоминание, у вас есть ссылки, где это сделано для С++?
Павел Соколов, опять новый термин — «клиент» ;) не очень понятно, о чем это. почему я предложил шаблон Плагин — потому что в этом случае главное приложение не знает ничего о плагине и не имеет от плагина зависимости, а плагин — имеет обычно одну связь (интерфейс, или базовый класс). Таким образом можно разделить проекты на разные солюшены/команды.
Средний
