Автоматическая сборка пакета NuGet с указанием зависимостей

Я хочу запустить локальный / внутренний репозиторий NuGet . Думаю, я понял, как «повторно использовать» существующие пакеты NuGet, включив их в фиктивный проект с помощью NuGet и просканировав файл пакета, чтобы получить мои .nupkgфайлы из локального кеша , но ...

Как создать пакет nuget ( .nupkg) из проекта, автоматически включающий все dll зависимости, а не только те, которые были получены через NuGet?

В частности:

1. Создать решение
2. Добавить новый проект
3. Добавляйте ссылки на различные .dllфайлы / другие проекты <- это недостающая часть
4. Добавить пакеты NuGet через диспетчер пакетов / cmdline / что угодно
5. что-то автоматически создает.nupkg

Из того, что я нашел, вы должны делать такие вещи, как

• вручную отредактируйте .csprojфайл, чтобы добавить <BuildPackage>true</BuildPackage>и включить зависимости
• вручную создайте .nuspecфайл и вручную укажите свои зависимости ( аналогично? )
• вручную запустить nuget packсвой .nuspecфайл

Но все вручную, что глупо. Даже полуавтоматические решения остаются неудобными или полуавтоматическими:

• Создавайте .nuspecшаблоны - похоже, не включают зависимости, только метаданные

• Пакет nuget через событие сборки (шаг 5), который вам нужно добавить вручную в каждый проект, и у него есть свои особенности :

  "$(SolutionDir).nuget\NuGet.exe" pack "$(ProjectPath)" -Properties Configuration=Release
  move /Y *.nupkg "$(TargetDir)"
  

Я соглашусь на то, что автоматически создает .nuspecманифест из ссылок на проекты. Тогда теоретически это + событие сборки nuget можно свернуть в пакет build-project / nuget, что я действительно хочу видеть.

Ваш пункт № 3 ( Добавить ссылки на различные файлы .dll / другие проекты <- это недостающая часть ) действительно содержит две разные проблемы: (1) добавить ссылки на различные файлы DLL и (2) добавить ссылки на другие проекты в такое же решение.

Номер (2) получил дополнительную поддержку, начиная с NuGet 2.5 . Вы можете добавить возможность включения ссылок на другие проекты в том же решении при создании пакета NuGet для проекта:

nuget pack projectfile.csproj -IncludeReferencedProjects

Если projectfile.csprojв вашем решении есть ссылки на какие-либо другие проекты, которые также представлены как пакеты NuGet, пакеты NuGet этих проектов будут добавлены как зависимости. Если он ссылается на проекты в вашем решении, которые не представляют себя как пакеты NuGet, их библиотеки DLL будут включены в этот пакет NuGet.

Что касается (1), если вы обнаружите, что часто добавляете в свои проекты библиотеки DLL, которые недоступны в виде пакетов NuGet, вы можете просто создать свои собственные (внутренние) пакеты NuGet с этими файлами. Если затем вы добавите эти библиотеки DLL как пакет NuGet вместо файлов напрямую, этот пакет NuGet станет зависимостью в пакете NuGet вашего проекта.

Для других сотрудников Google вы можете использовать это, если вы используете файл NuGet.targets для запуска пакета NuGet:

<Target Name="PrePackage" BeforeTargets="BuildPackage">
  <PropertyGroup>
    <BuildCommand>$(BuildCommand) -IncludeReferencedProjects</BuildCommand>
  </PropertyGroup>
</Target>

Проверь это!

Решение, которое я нашел, является расширением для Visual Studio: https://visualstudiogallery.msdn.microsoft.com/fbe9b9b8-34ae-47b5-a751-cb71a16f7e96/view/Reviews

Вы просто добавляете новый проект под названием NuGet Package NuGet Package

Потом добавляете интересные вам проекты в ссылки и БУУМ !! Все зависимости и файловые каталоги добавляются автоматически. Если вы хотите изменить данные NuSpec, щелкните прямо в проекте и перейдите в «Свойства», а затем измените то, что хотите. Сгенерированные NuSpec и nupkg будут находиться в папке obj вашего нового проекта. Я надеюсь, что это помогает ;).

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

Я только что протестировал найденное здесь решение: https://dev.to/wabbbit/include-both-nuget-package-references-and-project-reference-dll-using-dotnet-pack-2d8p

И после изучения пакета NuGet с помощью NuGet Package Explorer библиотеки DLL, созданные ссылочными проектами, действительно присутствуют. Я собираюсь протестировать, фактически отправив этот пакет в NuGet и протестировав его.

Вот мой источник на случай, если он будет вам полезен: https://github.com/jchristn/NuGetPackTest

И тестовый пакет NuGet: https://www.nuget.org/packages/NuGetPackTest/1.0.0

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

.csproj из библиотеки NuGetPackTest, которая ссылается на проект TestLibrary (части удалены для краткости)

<Project Sdk="Microsoft.NET.Sdk">
 
  <PropertyGroup>
    <TargetFrameworks>netstandard2.0;netcoreapp3.0;netcoreapp3.1;net461</TargetFrameworks>
    ...
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>

    <!-- added this line -->
    <TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
  </PropertyGroup>

  <ItemGroup>

    <!-- modified this ProjectReference to include the children ReferenceOutputAssembly and IncludeAssets -->
    <ProjectReference Include="..\TestLibrary\TestLibrary.csproj">
      <ReferenceOutputAssembly>true</ReferenceOutputAssembly>
      <IncludeAssets>TestLibrary.dll</IncludeAssets>
    </ProjectReference>
  </ItemGroup>

  <!-- added this section -->
  <Target DependsOnTargets="ResolveReferences" Name="CopyProjectReferencesToPackage">
    <ItemGroup>
      <BuildOutputInPackage Include="@(ReferenceCopyLocalPaths->WithMetadataValue('ReferenceSourceTarget', 'ProjectReference'))"/>
    </ItemGroup>
  </Target>
  
</Project>