Возможность избежать добавления ссылки на пакет nuget в пользу ссылки на сборку, в т.ч. зависимости? - PullRequest
0 голосов
/ 04 февраля 2020

есть ли способ избежать ссылок на пакеты nuget, чтобы упростить разработку на компьютере разработчика?

В настоящее время мы собираемся переместить некоторые из наших проектов в нашем решении " shared " в новую csproj файловую структуру (используя <Project Sdk="Microsoft.NET.Sdk">) и используя <TargetFramework>netstandard2.0</TargetFramework>.

При этом нам пришлось включить <PackageReference Include="System.Text.Encodings.Web" Version="4.7.0" /> и изменить часть нашего кода в проекте " S " нашего общего решения.

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

<Reference Include="ournamespace.S">
   <HintPath>..\..\artifacts\Shared\ournamespace.S\ournamespace.S.dll</HintPath>
</Reference>

Когда мы собираем все работает нормально. Однако при запуске нашего веб-приложения W из backend решения мы получаем следующее исключение:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Text.Encodings.Web, Version=4.0.5.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

До мы перенесли передал проекты в формат файла проекта "новый SDK", прежде чем использовать .netstandard 2.0 (мы использовали. net framework 4.7.2) и перед тем, как мы переключили ссылку на пакет на System.Text.Encodings.Web ( мы использовали <PackageReference Include="AntiXSS" Version="4.3.0" />), мы не получили никаких ошибок.

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

Однако использование пакетов nuget для наших общих проектов решений и разработка в backend проектах станет настоящим кошмаром, поскольку нам потребуется создать новый пакет nuget (и опубликовать его ) при каждом изменении S и должен постоянно увеличивать номер версии в ссылках на пакеты в backend проектах. Кроме того, это стало бы очень непрактичным, поскольку наши разработчики также используют различные ветви функций git (думая о конфликтах версий; приходится выпускать незаконченные пакеты и, возможно, использовать суффикс версии "alpha _" + {branchName}, чтобы отличить ветку, к которой относится эта версия. с).

Как разрабатывать на localhost? Есть ли способ избежать nuget (но правильно разрешить его зависимости!)?

Я уже читал о наличии ссылок на сборки для локальной разработки при использовании ссылок на пакеты nuget для сборок CI с помощью условных выражений в файле csproj ( однако это также не очень хорошо работает с VS2017, и это не решило бы нашу проблему с проблемой зависимости, написанной выше для localhost)

Какие еще есть возможности? Есть ли лучший способ о том, как с этим справиться?

Заранее спасибо!

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

1 Ответ

0 голосов
/ 06 февраля 2020
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>

решил мои проблемы (см. Как получить. NET Базовые проекты для копирования ссылок NuGet для вывода сборки? для деталей)

...