есть ли способ избежать ссылок на пакеты 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 может получить новые зависимости по любой причине.