Dotnet Pack включает пакеты nuget в выходной пакет nuget - PullRequest
Новая
       27

Dotnet Pack включает пакеты nuget в выходной пакет nuget

0 голосов
/ 30 октября 2019

Итак, я сталкиваюсь с очень странным поведением с пакетами nuget.

Допустим, у меня есть пакет с именем Framework, и этот пакет является зависимостью от Package A и Package B

Теперь у меня есть Client 1, который имеет в качестве зависимостей Framework, Package A, Package B, и он ДОЛЖЕН быть таким, потому что, например, Client 2 может не нуждаться в Package A, но нужны другие 2 иликлиент, которому нужна только инфраструктура.

Теперь вот, где все становится странным. Если в целях тестирования я создаю локальную версию Framework для Client 1, чтобы протестировать некоторые изменения, но Package A/B все еще находятся в реестре, в котором они были опубликованы, он будет жаловаться, что более старая версия платформы ненайдено (с какой версией Package A/B были созданы), поэтому я хотел бы сейчас k, если есть какой-либо способ буквально связать пакет nuget со всеми его зависимостями как автономный пакет?

Вотпример .csproj 

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <TreatWarningsAsErrors>false</TreatWarningsAsErrors>
    <WarningsAsErrors />
  </PropertyGroup>

  <ItemGroup>
    <Folder Include="Component\" />
    <Folder Include="Model\" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Package.A" Version="1.0.1-SNAPSHOT" />
    <PackageReference Include="Framework" Version="[5.*,)" />
  </ItemGroup>

</Project>

И моя команда pack обычно: 

dotnet pack -p:PackageVersion=1.1.2-SNAPSHOT -o C:\Users\SomeUser\Desktop\Projects\NuGetPackages

1 Ответ

0 голосов
/ 30 октября 2019

если есть какой-либо способ буквально связать пакет nuget со всеми его зависимостями как автономный пакет?

Не с текущим набором инструментов, но это самый высокийupvoted проблема на GitHub .

Если это то, что вам действительно нужно, вы можете использовать PackagePath , чтобы включить dll в ваш пакет (например, <None Include="path\to\framework.dll" PackagePath="lib/<tfm>/" />). В качестве альтернативы, создайте файл nuspec и укажите все сборки для включения .

Однако существует несколько проблем с этим. Во-первых, когда версия framework.dll, поставляемая в комплекте с Package.A, отличается от версии, поставляемой с Package.B, какую версию будет использовать приложение? Имена файлов должны быть уникальными, поэтому оба не могут существовать одновременно. Сохраняя фреймворк как отдельный пакет, который зависит от обоих других пакетов, становится понятнее, что выбран только один, и ясно, какая версия была выбрана. Другая проблема заключается в том, что если в Framework есть ошибка, если это зависимость, приложение может просто ссылаться на Framework как на прямую зависимость, используя версию, которая исправляет ошибку. Если framework.dll входит в состав других пакетов, то необходимо не только исправить Framework, но и затем опубликовать новые версии других пакетов, которые включают эту новую версию. Вы делаете исправление ошибок обслуживания более сложным, когда вы связываете.

Однако я не верю, что что-то из этого решит вашу проблему. В вашем описании, что «он будет жаловаться на то, что более старая версия фреймворка не найдена» не хватает подробностей, чтобы понять, в чем именно заключалась ошибка, но я предполагаю, что у вашей dll фреймворка подписано строгое имя, и он не работает во время выполнения с ошибкой файла не найдено версии, с которой были скомпилированы пакеты. В этом случае вы, вероятно, захотите использовать перенаправления привязки , хотя для проектов в стиле SDK я подумал, что это следует делать автоматически, когда он обнаруживает несколько сборок, ссылающихся на разные версии одного и того же имени сборки.

Еслиэтот ответ не помогает, я думаю, что нам нужно больше информации о том, что именно вы получили, и как именно вы «создаете локальную версию Framework для клиента 1, чтобы протестировать некоторые изменения» (вы добавили ProjectReference к framework.csproj, или вы скомпилировали framework.dll и добавили ссылку на эту dll в ваш тестовый проект, или что-то еще?)

...