У нас есть решение VS2010, которое содержит одно приложение формы Windows и 4 проекта библиотеки классов (DLL). (Библиотеки классов - это такие вещи, как BusinessTier, DataTier, CommonCode, ControlLibrary) Все это нацелено на фреймворк 2.0. Так было уже три года.
Ok
Таким образом, наше приложение выросло до такой степени, что мы хотим добавить большую новую функцию, а маркетинг хочет развернуть ее как отдельный продукт. Наш продукт используется для заполнения налоговых форм, а второй продукт заполнит другие налоговые формы.
Мы хотим получить два exe-файла (два установочных MSI), которые будут продаваться / устанавливаться / обновляться независимо, и оба могут быть запущены одновременно на одном компьютере. Большая часть кода является общей для двух приложений.
Я пытаюсь найти лучший способ структурировать решение для достижения желаемого результата.
1) Вариант 1 может заключаться в создании нового EXE-проекта и нескольких новых DLL-проектов в одном и том же исходном решении (например, в папке решения), которые имеют уникальные имена, версии, руководства и т. Д., Причем большинство кодовых файлов, таких как ссылки на файлы кода в оригинальной аналогичной DLLS. Это позволяет нам иметь две совершенно разные системы с уникальными именами для всех файлов, номерами версий и т. Д., Но позволяют выполнять любую настройку для каждого проекта / dll. Это хорошая идея или излишество?
2) Второй вариант - создать новый exe-проект в решении и связать его с теми же библиотеками, что и первый exe-проект. Это кажется достаточно простым, но я не знаю, будет ли хорошей идеей иметь два проекта, которые используют одни и те же библиотеки DLL. Я не очень хочу использовать GAC. Если у нас есть два exe-файла, которые используют одни и те же библиотеки DLL (даже если они находятся в отдельных папках приложений), возникнет проблема, если у DLLS одинаковые / разные номера версий, имя или GUID?
Какие у вас идеи?
Как мне реструктурировать решение с учетом нового продукта?