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

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

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

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

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

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

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

обновление:

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

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

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

6
dependencies projects-and-solutions visual-studio

3 ответов

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

    • <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 *.целевой файл, который знает о каждом таком каталоге; все мои проекты импортируют этот файл.

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

редактировать

в ответ на обновление в вопросе добавлю еще один шаг:

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

плохое:

<Reference Include="Microsoft.SqlServer.Smo">
  <SpecificVersion`>False</SpecificVersion>
  <HintPath>..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server0\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 hell."Как только вы используете строгие имена, безопасно иметь несколько версий одной и той же сборки в ссылочных путях, потому что компоновщик будет загружать только те, которые соответствуют каждому критерию. Кроме того, если вы решите обновить некоторые сборки на месте (вместо добавления копий), вы будете уведомлены о любых изменениях во время компиляции вместо всякий раз, когда ошибки начинают поступать.
2

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

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

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

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

1

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

public\External\libraries\Nunit\2.6\

или

Public\Internal\libraries\Logger\5.4.312\

и внутри решений все проекты, которые должны использовать любую из зависимостей, просто добавляют ссылку на эти сборки в public internal или extrenal папки.

0