Я также использовал SmartAssembly. Я нашел что Реактор Ezrinz.Net намного лучше для меня на .net приложениях. Это запутывает, Моно поддержка, блоки слияний, и это также также имеет очень хороший модуль лицензирования, чтобы создать пробную версию или связать лицензию на конкретную машину (очень легкий реализовать). Цена также очень конкурентоспособна и когда я нуждался в поддержке они где быстро. Eziriz
Только, чтобы быть ясным я - просто custumer, кому нравится продукт и ни в коем случае не связанный с компанией.
Проблема с конфигурацией сборки заключается в следующем: допустим, у вас есть 3 проекта и 2 решения.
Solution1
- Project1
- Project2
Solution2
- Project1
- Project3
Внезапно сборка Solution2 строит часть кода для Решение1, оставив его в недопустимом состоянии (последние двоичные файлы либо несовместимы, либо их не нужно собирать).
Каждый проект должен быть включен в одно решение. На другие решения можно положиться, но не следует активно изменять код этих проектов. Таким образом, они могут ссылаться на встроенную DLL, потому что нет причин для перестройки внешних зависимостей.
Подводя итог, вам следует потратить некоторое время и реструктурировать свои решения, чтобы они соответствовали следующим условиям:
В дополнение к вышесказанному, я рекомендую создать каталог «Externals» для размещения сборок, когда на них ссылаются другие решения. Предположим, вы реструктурируете его до следующего:
Solution1
- Project1
- Project2 -> reference project Project1
Solution2
- Project3 -> reference Project1.dll
В этом случае вы должны разместить копии Project1.dll и Project1. pdb в Externals \ Project1 \ Debug
и Externals \ Project1 \ Release
и ссылку External \ Project1 \ $ (Configuration) \ Project1.dll
в Project3. Обновляйте сборки в каталоге Externals только тогда, когда вы будете готовы применить сборку ко всем остальным решениям.
Есть ли причина, по которой вы хотите разрешить произвольные решения? Похоже, было бы проще создать единое решение и поместить в него все проекты. Я стараюсь по возможности избегать множественных решений.
Мне кажется, что проблемы, с которыми вы сталкиваетесь, являются прямым результатом неправильного использования вашего набора инструментов. В Visual Studio нет другого способа автоматического расчета зависимостей проекта, если вы не разрешаете ему управлять ими.
Похоже, у вас есть два варианта.
Похоже, вы исключили вариант №1, поэтому я больше не буду его рассматривать. Остается только вариант № 2.
Вы можете использовать NAnt для создания ваших индивидуальных проектов CSproj и использовать ваш сценарий сборки NAnt для определения зависимостей между проектами. У этого есть два недостатка.
С другой стороны, Visual Studio не будет невозможно скомпилировать ваше решение в целом, потому что эта логика была бы перенесена из VS во внешний скрипт сборки. Это может привести к путанице среди разработчиков и затруднить процесс отладки. Я не говорю, что эти вещи невозможно преодолеть ... просто говорю, что на этих этапах процесса разработки потребуется дополнительная настройка.