Руководящие зависимости от блока.NET dll ссылкой, а не ссылкой проекта в VS

Я также использовал SmartAssembly. Я нашел что Реактор Ezrinz.Net намного лучше для меня на .net приложениях. Это запутывает, Моно поддержка, блоки слияний, и это также также имеет очень хороший модуль лицензирования, чтобы создать пробную версию или связать лицензию на конкретную машину (очень легкий реализовать). Цена также очень конкурентоспособна и когда я нуждался в поддержке они где быстро. Eziriz

Только, чтобы быть ясным я - просто custumer, кому нравится продукт и ни в коем случае не связанный с компанией.

9
задан mark 10 November 2009 в 07:33
поделиться

3 ответа

Проблема с конфигурацией сборки заключается в следующем: допустим, у вас есть 3 проекта и 2 решения.

Solution1
- Project1
- Project2
Solution2
- Project1
- Project3

Внезапно сборка Solution2 строит часть кода для Решение1, оставив его в недопустимом состоянии (последние двоичные файлы либо несовместимы, либо их не нужно собирать).

Каждый проект должен быть включен в одно решение. На другие решения можно положиться, но не следует активно изменять код этих проектов. Таким образом, они могут ссылаться на встроенную DLL, потому что нет причин для перестройки внешних зависимостей.

Подводя итог, вам следует потратить некоторое время и реструктурировать свои решения, чтобы они соответствовали следующим условиям:

  • Каждый проект включен точно в одно решение.
  • Если проект зависит от другого проекта в том же решении, сделайте его ссылкой на проект.
  • Если проект зависит от другого проекта в другом решении, сделайте его ссылкой на 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 только тогда, когда вы будете готовы применить сборку ко всем остальным решениям.

7
ответ дан 4 December 2019 в 22:28
поделиться

Есть ли причина, по которой вы хотите разрешить произвольные решения? Похоже, было бы проще создать единое решение и поместить в него все проекты. Я стараюсь по возможности избегать множественных решений.

2
ответ дан 4 December 2019 в 22:28
поделиться

Мне кажется, что проблемы, с которыми вы сталкиваетесь, являются прямым результатом неправильного использования вашего набора инструментов. В Visual Studio нет другого способа автоматического расчета зависимостей проекта, если вы не разрешаете ему управлять ими.

Похоже, у вас есть два варианта.

  1. Используйте Visual Studio для управления зависимостями проекта
  2. Используйте другую систему сборки ( как NAnt)

Похоже, вы исключили вариант №1, поэтому я больше не буду его рассматривать. Остается только вариант № 2.

Вы можете использовать NAnt для создания ваших индивидуальных проектов CSproj и использовать ваш сценарий сборки NAnt для определения зависимостей между проектами. У этого есть два недостатка.

  1. Вы должны управлять всем этим, чтобы купить руку (что, похоже, вы готовы сделать).
  2. Visual Studio будет для вас так же сломана, как и сейчас.

С другой стороны, Visual Studio не будет невозможно скомпилировать ваше решение в целом, потому что эта логика была бы перенесена из VS во внешний скрипт сборки. Это может привести к путанице среди разработчиков и затруднить процесс отладки. Я не говорю, что эти вещи невозможно преодолеть ... просто говорю, что на этих этапах процесса разработки потребуется дополнительная настройка.

-1
ответ дан 4 December 2019 в 22:28
поделиться
Другие вопросы по тегам:

Похожие вопросы: