Как найти библиотеки DLL для межкомпонентных ссылок

Question

Как найти библиотеки DLL для межкомпонентных ссылок

2

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

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

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

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

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

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

Rune FS 25 июнь 2009, в 21:52

Источник

1

Почему вы храните производные файлы (.DLL) в системе контроля версий? У вас есть сценарий сборки и процесс на месте?
Eric Smith 25 июнь 2009, в 19:14
0

Мы не, прямо сейчас. В настоящее время сборки просто ссылаются друг на друга по проекту в VS2008, потому что все они находятся в одном решении и в одном репозитории. Однако это не вариант, когда они находятся в разных решениях и в разных репозиториях. Поэтому я пытаюсь решить, как лучше управлять библиотеками DLL для связи между компонентами.
Kyle Woodlock 25 июнь 2009, в 22:43

Теги:

c#

dll

.net

reference

modularity

3 ответа

Ещё вопросы

Почему вы храните производные файлы (.DLL) в системе контроля версий? У вас есть сценарий сборки и процесс на месте?
Мы не, прямо сейчас. В настоящее время сборки просто ссылаются друг на друга по проекту в VS2008, потому что все они находятся в одном решении и в одном репозитории. Однако это не вариант, когда они находятся в разных решениях и в разных репозиториях. Поэтому я пытаюсь решить, как лучше управлять библиотеками DLL для связи между компонентами.

Jonathan · Answer 1 · 2009-06-25T17-41-00.000Z

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

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

Вы делаете это, перейдя в проект, который строится в DLL (или DLL), и щелкните правой кнопкой мыши на этом проекте и перейдите в "Свойства". Затем вы переходите на вкладку BUILD EVENTS. Там вы видите текстовые поля командной строки Pre-Compile и Post-Compile.

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

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

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

Rune FS · Answer 2 · 2009-06-25T17-04-00.000Z

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

Это по-прежнему требует, чтобы каждый разработчик делал проверку Core отдельно, чего он пытается избежать.
Как сказал Рид Копси, для этого потребуется наличие ядра и создание его в определенном месте, от чего мы (надеюсь) отходим. Меня интересует, что вы подразумеваете под «создавать артефакты». Это термин Visual Studio, с которым я раньше не сталкивался?

Reed Copsey · Answer 3 · 2009-06-25T16-59-00.000Z

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

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

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

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

Я посмотрю в SVN: внешность, спасибо. Возможно, я смогу найти способ настроить его так, чтобы внешние зависимости каждого хранилища проверялись в режиме только для чтения, просто чтобы убедиться, что я случайно не испортил Core, когда я работаю над бета-версией, например.
Да, вы можете сделать это с помощью стандартной обработки безопасности SVN.