Ссылка на проект VS NuGet

Как мне ссылаться на другого project A от project B в том же решении?
Что я получу и что я потеряю, если я:

  • Добавить ссылку на project A в качестве ссылки на проект.
  • Установите пакет NuGet project A в project B,

Вещи, которые меня беспокоят, это зависимости сборки, управление версиями..?
Или это полностью разрушает цель решения?

Источник

4 ответа

Решение

При первом подходе вы получаете простоту, так как вам не нужно генерировать новую версию пакета nuget ProjectA, каждое изменение, которое вы вносите в него (например, ProjectA.nupkg).

Однако при втором подходе вы получаете мобильность, так как вы легко можете использовать тот же пакет nuget для других проектов / решений.

Лично я создаю пакеты nuget только для проектов, цель которых - поделиться с другими решениями. (Например, библиотеки и рамки).

Надеюсь, это поможет вам решить!

Источник

Ссылка на проект VS NuGet

Ссылка на проект или NuGet - очень распространенная проблема в нашем процессе разработки, нам нужно выбрать, какой из них использовать, исходя из нашей реальной ситуации.

Например, если ссылочный проект A часто изменяется в процессе разработки, мы рекомендуем использовать ссылку Project. Потому что, если вы используете nuget, вам нужно пересобрать упомянутый проект, воссоздать пакет nuget, переустановить этот пакет nuget в проект B, даже если вам придется опубликовать его на сервере. Это принесет много ненужной работы, и мы часто забываем обновить наш пакет nuget после того, как изменим ссылочный проект A. Если вы используете ссылку на проект, у вас не будет этих проблем. Измененный ссылочный проект A будет автоматически обновлен до того, как мы построим проект B.

С другой стороны, когда мы делимся ссылочным проектом А из решения или передаем этот проект другим, лучшим выбором будет Nuget. У него больше мобильности.

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

Кроме того, имеется расширение https://github.com/rsuter/NuGetReferenceSwitcher для Visual Studio, которое автоматически переключает ссылки на сборки NuGet на ссылки на проекты и наоборот.

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

Источник

В настоящее время с новым форматом csproj вы можете использовать оба одновременно (если у вас есть оба проекта в одном решении).

В вашем примере вы могли бы ссылаться project A от project B в качестве ссылки на проект. Тогда, если вы хотите выпустить project A как пакет NuGet, вам просто нужно добавить следующий тег в его csproj внутри PropertyGroup:

    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>

Сюжетный поворот: если вы хотите выпустить project B как пакет NuGet тоже просто добавьте GeneratePackageOnBuild target - MSBuild установит projectA.nupkg как зависимость в projectB.nupkg,

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

Источник

Вы можете использовать как ссылки на проект во время разработки (быстрее), так и ссылки на пакеты во время производства.

В вашей.csprojфайл проекта:

      <ItemGroup Condition="'$(Configuration)'=='Debug'">
  <ProjectReference Include="../../../Library1/Library1.csproj" />
  <ProjectReference Include="../../../Library2/Library2.csproj" />
</ItemGroup>
<ItemGroup Condition="'$(Configuration)'!='Debug'">
  <PackageReference Include="Library1" Version="1.0.0" />
  <PackageReference Include="Library2" Version="1.0.0" />
</ItemGroup>

В разработке: проект скомпилирован в режиме отладки, поэтому будет использоваться ссылка на проект.

В производстве (сервер CI, контейнер докеров): проект скомпилирован в режиме выпуска, поэтому будет использоваться ссылка на пакет.

Источник
Другие вопросы по тегам