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


83

Я хочу запустить локальный / внутренний репозиторий 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 можно свернуть в пакет build-project / nuget, что я действительно хочу видеть.


Я только что наткнулся на это расширение VS eyecatch.no/projects/nuget-package-template, которое мне нужно изучить ...
drzaus

3
Спустя пять лет спецификация или пакет nuget 4.x по-прежнему не может определить зависимости.
StingyJack

Есть ли обновление для этой проблемы? Или у вас все еще есть эти проблемы?
Доминик Йонас

Я отказался от этого некоторое время назад, но посмотрите NuProj, о чем говорится в этом ответе
drzaus

Эта проблема все еще существует. :(
BrainSlugs83 05

Ответы:


75

Ваш пункт № 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 вашего проекта.


3
вздох №1 по-прежнему слишком ручной на мой вкус. Собственно, «создать свой собственный (внутренний) пакет NuGet с этими файлами» - это то, что я пытаюсь сделать - весь смысл этого вопроса в том, что я хочу автоматически свернуть не-NuGet .dll-файлы в пакет NuGet. Не просматривать и перечислять каждую dll вручную в файле .nuspec, что, я думаю, вы предлагаете?
drzaus

Вам не нужно указывать каждую DLL отдельно. Это действительно было бы много работы, если бы у вас их было много . При перечислении файлов для включения вы можете использовать (рекурсивные) подстановочные знаки ( docs.nuget.org/docs/reference/… ), поэтому, если вы, например, поместите все эти библиотеки DLL в отдельную папку, это будет однострочное включение торговый центр.
Джулиан

Ах, теперь я добираюсь туда, куда вы идете - поэтому, если я создам проект-оболочку, включаю ссылки с помощью обычного «щелкните правой кнопкой мыши проект> Добавить ссылку», тогда я могу создать, nuspecкоторый включает все в binкаталоге (при условии, что мои ссылки все "копируют локально"), он автоматически подхватит все, что я добавил. Кажется немного неуклюжим, но, вероятно, сработает.
drzaus

6
Он не будет автоматически подобрать все , что находится в каталоге BIN, вы должны указать это явно, что - то вроде этого:<file src="bin\release\*.dll" target="lib" />
Julian

2
Следует отметить, что если проекты, на которые ссылаются, имеют файл nuspec, тогда nuget будет рассматривать его как пакет и НЕ включать в папку lib, но добавит его к зависимостям пакета
workabyte

5

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

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

7
Звучит многообещающе, но информации недостаточно для практической реализации. Что это за файл NuGet.targets, о котором вы говорите? Я знаком с целевыми файлами сборки в целом, но не с этим конкретным вариантом использования
bikeman868

2

Проверь это!

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

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

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


1
Есть еще решение для VS2017?
Доминик Йонас

Это не работает в случае создания пакетов на сервере сборки.
Michi-2142

Жаль, что это устарело. Было бы полезно.
Joelc

2

Я нашел хорошо написанную статью по этой теме. У меня такая же проблема с некоторыми пакетами, которые имеют иерархию зависимостей, и до сих пор я загружал каждый как отдельный пакет 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>

1
это сразу решило мою проблему. Я выполнил инструкции, указанные в ссылке, и это сработало. Приятно, что в ответ добавлена ​​и суть.
Jabez
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.