Исключая сборку библиотеки из пакета nuget в. NET Стандарт - PullRequest
Новая
       56

Исключая сборку библиотеки из пакета nuget в. NET Стандарт

4 голосов
/ 13 января 2020

Терпите меня - это необычный сценарий. У меня есть 4 проекта в моем решении. В самом верхнем проекте упоминаются 3 других проекта. Ни один из 3 других проектов не ссылается друг на друга. Итак, архитектура выглядит следующим образом:

enter image description here

Теперь, когда я собираю проект AI, хочу, чтобы он создавал пакет nuget, содержащий проекты B, C и D, но не проект А. Поскольку это стандарт. NET, я могу настроить вкладку «Пакеты» проекта А для автоматического создания пакета nuget при его сборке, установив флажок «Создать пакет NuGet при сборке». Затем я могу включить B, C и D, внеся следующие изменения в файл csproj A: 

<ItemGroup>
    <ProjectReference Include="..\B.csproj">
      <PrivateAssets>all</PrivateAssets>
    </ProjectReference>
    <ProjectReference Include="..\C.csproj">
      <PrivateAssets>all</PrivateAssets>
    </ProjectReference>
    <ProjectReference Include="..\D.csproj">
      <PrivateAssets>all</PrivateAssets>
    </ProjectReference>
  </ItemGroup>

  <PropertyGroup>
    <TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
    <Version>1.0.0-beta</Version>
    <PackageId>A</PackageId>
    <Company></Company>
    <Product>A</Product>
    <Description></Description>
    <Authors></Authors>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
  </PropertyGroup>

  <Target Name="CopyProjectReferencesToPackage" DependsOnTargets="ResolveReferences">
    <ItemGroup>
      <BuildOutputInPackage    Include="@(ReferenceCopyLocalPaths-&gt;WithMetadataValue('ReferenceSourceTarget', 'ProjectReference')-&gt;WithMetadataValue('PrivateAssets', 'all'))" />
    </ItemGroup>
  </Target>

В идеале я хотел бы добавить строку для удаления A.dll из nuget пакет. Это возможно? A - это проект-обертка, который никогда не понадобится потребляющему коду. Невозможно, чтобы B, C и D. ссылались друг на друга.

ОБНОВЛЕНИЕ Так я решил (спасибо @tom redfern)

Я создал файл nuspe c вручную: 

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>A</id>
    <version>1.0.0-beta</version>
    <authors>Foo</authors>
    <owners>Bar</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>A package</description>
    <dependencies>
      <group targetFramework=".NETStandard2.0">    
      </group>
    </dependencies>
  </metadata>
  <files>
    <file src="bin\Release\netstandard2.0\B.dll" target="lib\netstandard2.0\B.dll" />
    <file src="bin\Release\netstandard2.0\C.dll" target="lib\netstandard2.0\C.dll" />
    <file src="bin\Release\netstandard2.0\D.dll" target="lib\netstandard2.0\D.dll" />
  </files>
</package>

Затем в мой файл .csproj для AI поместите следующее, чтобы автоматически упаковать его после сборки: 

 <Target Name="__PackNuGetPackage" AfterTargets="Build">
    <Exec Command="$(NugetPackage)nuget.exe pack &quot;A.nuspec&quot;" />
  </Target>

Ответы [ 2 ]

2 голосов
/ 14 января 2020

Используя запатентованные (1) elite (2) навыки отладки, мы можем выяснить, возможно ли это без ручного создания и поддержки файла nuspe c.

Сначала давайте начнем с Документов NuGet при создании пакета с do tnet CLI . Он говорит: «msbuild -t: pack - это функциональность, эквивалентная do tnet pack». Итак, первая подсказка, это просто запуск целей MSBuild.

Итак, запустите dotnet msbuild my.csproj -pp:pp.txt. Это «предварительная обработка» (оценивает все операторы импорта MSBuild и записывает результат в один файл) csproj (просто стандартный файл MSBuild). Затем мы ищем цель пакета и прокручиваем вверх, пока не найдем имя файла импортированного файла. Мы видим, что это NuGet.Build.Tasks.Pack.targets, и поскольку NuGet является открытым исходным кодом на GitHub, я могу указать вам на источник .

Поиск NuGet.Build.Tasks.Pack.targets для Condition, чтобы увидеть, какие варианты расширяемости команда NuGet предоставила, я вижу <IncludeBuildOutput Condition="'$(IncludeBuildOutput)'==''">true</IncludeBuildOutput>. Таким образом, настройки <IncludeBuildOutput Condition="'$(IncludeBuildOutput)'==''">false</IncludeBuildOutput> в вашем csproj могут работать.

(1) не запатентован

(2) стандартно, но так как люди не изменяйте файлы MSBuild так часто, как C#, навыки и инструменты не так хорошо известны

1 голос
/ 14 января 2020

Этого можно добиться, используя файл nuspe c. Используйте nuspe c, когда вам нужен абсолютный контроль над процессом nuget pack . Простой файл nuspe c: 

<package >
  <metadata>
    <id>MyPackage</id>
    <version>1.0</version>
    <authors>Something</authors>
    <owners>Something</owners>
    <description>Somthing</description>
    <copyright></copyright>
    <dependencies>
       <!-- any nuget package dependencies -->
       <dependency id="AnotherPackage" version="2019.2.4.1" />
    </dependencies>
  </metadata>
  <files>
    <!-- this is where you can have complete control over which assemblies get added to your package. You can add them individually pr using wildcards. -->
    <file src="..\obj\**\*.dll" target="lib" />
  </files>
</package>

Когда вы создали файл .nuspe c, добавьте его в свое решение, а затем выполните шаг сборки Nuget Pack, прочитав nuspe c файл, а не файл проекта.

...