Вопросы Теги

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

Можно представить свойства тот же путь как поля. Для определения дополнительной информации как только для чтения или только для записи, можно использовать

+Name:string {ТОЛЬКО ДЛЯ ЧТЕНИЯ}

6
задан Ola Herrdahl 10 June 2011 в 12:57
поделиться

3 ответа

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

    • <ветка > \ NetFX \ 2.0527 \ *
    • <ветка > \ NetFX \ 3.0 \ *
    • <ветка > \ NetFX \ 3.5 \ *
    • <ветка > \ NetFX \ Silverlight 2 \ *
    • > \ NetFX \ Silverlight 3 \ *

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

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

РЕДАКТИРОВАТЬ

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

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

Плохо: 

<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". Если вы используете сильные имена, Безопасно иметь несколько версий одной и той же сборки в ваших ссылочных путях, потому что компоновщик будет загружать только те, которые соответствуют каждому критерию. Кроме того, если вы решите обновить некоторые сборки на месте (вместо добавления копий), то вы будете уведомлены о любых критических изменениях во время компиляции вместо , когда начнут появляться ошибки.
2
ответ дан 17 December 2019 в 18:18
поделиться

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

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

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

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

1
ответ дан 17 December 2019 в 18:18
поделиться

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

public \ External \ libraries \ Nunit \ 2.6 \

или

Public \ Internal \ libraries \ Logger \ 5.4.312 \

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

0
ответ дан 17 December 2019 в 18:18
поделиться
Другие вопросы по тегам:

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