Как вы разделяете внешние зависимости между решениями Visual Studio? - PullRequest
Новая
       66

Как вы разделяете внешние зависимости между решениями Visual Studio?

6 голосов
/ 01 августа 2009

У меня есть фон Java, поэтому я привык к тому, что Maven решает все проблемы, связанные с загрузкой и обновлением зависимостей. Но в среде .NET я еще не нашел хорошего способа управления всеми этими внешними зависимостями.

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

Я понял, что одним из решений может быть включение внешних библиотек в «библиотечный проект», который включен во все решения, и позволить другим проектам ссылаться на них через него. (Или просто убедитесь, что для всех проектов указаны внешние dll из одного места.)

Но есть ли лучшие способы сделать это? (Предпочтительно использовать какой-нибудь плагин для Visual Studio.)

Я посмотрел на Диспетчер зависимостей Visual Studio , и он кажется идеальным, но кто-нибудь пробовал его по-настоящему? Я также видел .NET-порты Maven, но, к сожалению, меня не слишком впечатлило их состояние. (Но, пожалуйста, продолжайте и рекомендуйте их всем, если вы думаете, что я должен дать им еще одну попытку.)

Так, каков был бы самый умный способ решить эту проблему?

Обновление:

Я понял, что мне нужно объяснить, что я имел в виду, когда ссылается на тот же набор .

.

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

Обновление 2: Обратите внимание, что это старый вопрос, заданный до того, как появились такие инструменты, как NuGet или OpenWrap . Если кто-то захочет предоставить более актуальную информацию, пожалуйста, продолжайте, и я изменю принятый ответ.

Ответы [ 3 ]

2 голосов
/ 01 августа 2009

  1. Найдите место для хранения сборок. Например, я храню сборки ядра .Net примерно так:

    • <branch> \ NetFX \ 2,0527 \*
    • <branch> \ NetFX \ 3,0 \*
    • <branch> \ NetFX \ 3,5 \*
    • <branch> \ NetFX \ Silverlight 2 \*
    • <branch> \ NetFX \ Silverlight 3 \*

  2. Используйте свойство ReferencePath в MSBuild (или AdditionalReferencePath в Team Build), чтобы направлять проекты по соответствующим путям. Для простоты и удобства обслуживания у меня есть 1 * .targets файл, который знает о каждом таком каталоге; все мои проекты Импортируйте этот файл.

  3. Убедитесь, что ваша стратегия управления версиями (ветвление, слияние, сопоставления локальных <-> серверов) поддерживает постоянные относительные пути между вашими проектами и ссылочными путями.

EDIT

В ответ на обновление в вопросе позвольте мне добавить еще один шаг:

4) Убедитесь, что каждая ссылка на сборку в каждом файле проекта использует полное строгое имя .Net и ничего больше .

Bad: 

<Reference Include="Microsoft.SqlServer.Smo">
  <SpecificVersion`>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\Shared\Microsoft.SqlServer.Smo.dll</HintPath>
</Reference>

Хорошо: 

<Reference Include="Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL" />

Преимущества последнего формата:

  • Использование HintPath в среде совместной разработки неизбежно приведет к ситуациям, когда «это работает для меня», но не для других. Особенно ваш сборочный сервер. Если вы пропустите его, вы получите правильные пути ссылки, иначе он не скомпилируется.
  • Использование слабого имени открывает возможность "DLL ад". Как только вы используете строгие имена, тогда будет безопасно иметь несколько версий одной и той же сборки в ваших ссылочных путях, потому что компоновщик будет загружать только те, которые соответствуют каждому критерию. Кроме того, если вы решите обновить некоторые сборки на месте (вместо добавления копий), то вы будете уведомлены о любых критических изменениях во время компиляции вместо всякий раз, когда появляются ошибки.
1 голос
/ 01 августа 2009

В дополнение к тому, что говорят все остальные, в основном это сводится к двум вещам:

  1. Убедиться, что все разработчики имеют одинаковые версии внешних библиотек
  2. Убедиться, что все разработчики имеют внешние библиотеки, расположенные в одном и том же месте (по крайней мере, относительно исходного кода)

Как указывает Ричард Берг, вы можете использовать ReferencePath и / или AdditionalReferencePath, чтобы помочь решить # 2. Если вы используете msbuild в своем процессе сборки (в нашем случае мы используем CruiseControl вместо MS Team Build), вы также можете передать ему ReferencePath в командной строке. Чтобы решить # 1, я нашел svn: externals полезным (если вы используете SVN).

Мой опыт работы с Maven заключается в том, что в большинстве случаев это слишком излишне.

0 голосов
/ 01 августа 2009

У меня обычно есть отдельная структура папок в элементе управления источником для внешних или внутренних зависимостей, и эти фильтры имеют сборки в соответствии с номером сборки или версии, например

общественное \ Внешние \ библиотеки \ Nunit \ 2,6 \

или

Public \ Internal \ библиотеки \ Logger \ 5.4.312 \

и внутри решений все проекты, которым требуется любая из зависимостей, просто добавляют ссылку на эти сборки в общедоступных внутренних или внешних папках.

...