Как найти библиотеки DLL для межкомпонентных ссылок - PullRequest
2 голосов
/ 25 июня 2009

В моей компании SAAS есть два продукта C # .NET, которые называются Application Alpha и Application Beta. Они оба ссылаются на некоторые библиотеки, которые мы можем назвать Core.

На данный момент кодовая база является монолитной, хранится в одном репозитории SVN с одним решением .NET, и мы пытаемся сделать его более модульным / компонентным. Мы разделились на отдельные репозитории для двух приложений и базовой библиотеки, но теперь мы сталкиваемся со следующей проблемой:

Альфа и Бета должны ссылаться на Core, но мы стараемся избегать прямой ссылки на код, потому что тогда мы практически вернулись к исходной точке: вам нужно проверить и разместить все репозитории. Итак, как нам ссылаться на сборки между этими компонентами?

Каждый компонент может иметь каталог, содержащий библиотеки DLL от других компонентов, на которые необходимо ссылаться, которые хранятся в SVN, но это будет означать дополнительные усилия при каждом обновлении Core для отправки новых библиотек DLL в Alpha и Beta.

Или мы могли бы хранить библиотеки DLL в центральном месте SVN (и / или в GAC), но это будет означать дополнительные усилия в любое время, когда обновляется Core, чтобы все остальные могли использовать новые библиотеки DLL.

Есть третий вариант, который мы пропускаем?

Ответы [ 3 ]

0 голосов
/ 25 июня 2009

вы можете иметь свой сценарий перестроения для Alpha и бетат создавать артефакты (а именно ядро ​​сборки) и размещать результат сборки ядра в определенном месте, ссылающемся на это местоположение.

0 голосов
/ 25 июня 2009

Вы можете использовать SVN: externals . Он был разработан для этого типа сценария.

Если вы хотите избежать этого, это, вероятно, ваши лучшие варианты. Я бы не стал помещать файлы в GAC, если только ваш основной проект не очень стабилен и не очень часто меняется. Наличие локальных библиотек DLL обеспечивает большую гибкость.

Каждый компонент может иметь каталог, содержащий библиотеки DLL от других компонентов, на которые необходимо ссылаться, которые хранятся в SVN, но это будет означать дополнительные усилия при каждом обновлении Core для отправки новых библиотек DLL в Alpha и Beta.

Это можно сделать довольно легко с помощью хорошей системы сборки. Этот подход имеет некоторые недостатки (то есть: возможные отклонения в системе сборки), но имеет некоторые преимущества, в том числе позволяет каждому зависимому проекту иметь разные версии при необходимости и т. Д.

0 голосов
/ 25 июня 2009

У меня есть нечто похожее, в котором у меня есть 5 приложений, использующих серию веб-элементов управления, которые я создал. Элементы управления скомпилированы в серию DLL для модульности, и приложения, которые их используют, живут на отдельных серверах.

Я использую утилиту сборки VS2008 для запуска пакетного файла, который копирует скомпилированные (обновленные) библиотеки DLL на рабочие серверы при выполнении Release Build.

Чтобы сделать это, перейдите в проект, который встроен в DLL (или DLL), и щелкните правой кнопкой мыши по этому проекту и перейдите в Свойства. Затем вы переходите на вкладку СОБЫТИЯ ДЛЯ СТРОИТЕЛЬСТВА. Там вы видите командную строку Pre-Compile и текстовые поля командной строки Post-Compile.

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

Надеюсь, это поможет, JP

...