[0] NuGet Package Task & Targets

[rrelyea]

As part of the move from Project.Json/xproj to csproj, we need to enable msbuild to be able to generate .nupkgs as part of its build output, in an integrated way.

[kovalikp]

Couple remarks:
I think the Pack target should be exposed via .sln metaproject, or be able to build Pack as a Deploy.

Once you start dealing with project to project references, you will inevitably depend on ResolveReferences and subsequently ResolveProjectReferences targets. The later uses <MSBuild Properties="%(_MSBuildProjectReferenceExistent.SetConfiguration); %(_MSBuildProjectReferenceExistent.SetPlatform)" /> set by AssignProjectConfiguration. Not using MSBuild task with exactly same properties breaks incremental builds and causes rebuilds of the projects.

As a workaround, user could use uniform Configuration|Platform settings for all projects. But I don't think this would work in every situation. Further more, consider this ;)

msbuild NuGet.Core.sln /t:Pack

[kovalikp]

IsTool:
I don't think this is sufficient as proposed in the document: There are currently three possible directories where to put project output: lib, tools and analyzers. Analyzers folder has additional structure (analyzers/dotnet/{language}), that is independent from any other project properties. There might be some workarounds, like looking for DiagnosticAnalyzer and/or ExportCodeFixProvider attributes, or maybe making analyzer option in PackageType metadata.

[mrward]

Why is the summary nuspec value no longer supported in the csproj file?

The summary is used as the short description for the NuGet package in the UI and is used by several NuGet packages (e.g. Automapper, Bootstrap, NUnit). For many NuGet packages the description is too long to be displayed in the list of packages so a summary is specified.

[mrward]

Why is Owners not available to be specified in the csproj file?

[mrward]

For the content files the spec says you have to specify a package path otherwise all files will be in the root of the NuGet package.

 <Content Include="..\win7-x64\libuv.txt">
     <Pack>true</Pack>
     <PackagePath>content\myfiles</PackagePath>
 </Content>

How is this PackagePath determined/specified? Is it based on the directory the Content file is added to in the project or do you have to specify it separately?

Just wondering if instead of a separate PackagePath property the folder structure of the project is used instead.

So for a file inside the project:

<Content Include="content\myfiles\libuv.txt">
  <Pack>true</Pack>
</Content>

For a file outside of the project:

<Content Include="..\win7-x64\libuv.txt">
  <Link>content\myfiles\libuv.txt</Link>
</Content>

Where the Link or Include determines the location of the file in the NuGet package.

The PackagePath could be used to override the location or specify that the file is used in multiple NuGet package locations.

[kovalikp]

Btw, what kind of packages could we possibly expect to be supported by this feature?

• Single platform lib package: lib\net452\Lib.dll
• Multi platform lib package: lib\net35\Lib.dll;lib\net452\Lib.dll
• Single tools package: tools\Tools.dll
• Single analyzer package: analyzers\dotnet\Analyzers.dll
• Multiple analyzers package: analyzers\dotnet\cs\Analyzers.CSharp.dll;analyzers\dotnet\vb\Analyzers.VisualBasic.dll

[kzu]

Regarding Output Assemblies, the targets should rely on BuiltProjectOutputGroupOutput. No need to deviate from the standard way for project targets to expose what they build. Likewise, there is no need to rely on file lookups for including symbols, rely on DebugSymbolsProjectOutputGroupOutput instead.

[kzu]

@rrelyea I'm going to track the implementation of this at #3477, since it's just one part of the whole NuGetizer feature. We added the Area:NuGetizer to easily filter. I'm also going to give the new Project stuff a short for this.

@kovalikp how about this (which I'm implementing as part of NuGetizer):

msbuild Foo.sln /p:BuildPackage=true

By passing that property, all projects will automatically add a target after build that will build the package for all projects that are configured to create packages (IsPackable==true, defaulted to PackageId != '').

Maybe it should be /p:Pack=true? Would that be too confusing with the /t:Pack that will also be available for a project?

@mrward I think the N/A mostly refers to stuff that doesn't have another (existing or new) mapping in MSBuild already in use for other purposes (like Copyright used for AssemblyInfo.cs generation). I don't read that as meaning it won't be available via an MSBuild property.

[kovalikp]

I can only second using BuiltProjectOutputGroupOutput or similar targets to get items to package. This way it should be possible to pass package related metadata to referencing projects. Then you could use the information to filter outputs and use them to build package dependencies. Ideally it would be the same metadata that are provided by projects using project.json (NuGetPackageId, NuGetPackageVersion, ...)

Regarding the target or property switch to enable packaging, I would suggest following:
Create package on Build by plugging new target into BuildDependsOn or other appropriate target.
Define project level property PackageType or NuGetPackageType with these recognized values:

• (empty) - Do not create package.
• Lib(rary) - Package assemblies into lib\[targetFramework] folder and resolve referenced projects and assemblies to package dependencies.
• Tools - Package assemblies into tools folder. Do not resolve package dependencies.
• Analyzers - Package assemblies into analyzers\dotnet folder. Same behavior as Tools.

Further-more, Library type projects should set relevant metadata so that any project referencing it can identify its package id and version.

Edit: I just had a look at NuGet.Packaging.targets and realized you already do plug Pack to BuildDependsOn. Nvm, going to look further. For now I likey

[rohit21agrawal]

@kovalikp @kzu thanks..i'll make sure to use the BuiltProjectOutputGroupOutput ..currently booked with some integration stuff, will look into this after that..

[kzu]

@rohit21agrawal we have support for Pack now in NuGetizer at https://github.com/NuGet/NuGet.Build.Packaging.

[joelverhagen]

Adding to what @kovalikp said, I think having a special $(IsTool) MSBuild property is weird. In PR NuGet/NuGet.Client#918, $(IsTool) does two things: defaults the $(BuildOutputTargetFolder) to tools and makes it so build artifacts aren't added under TFM subdirectory.

Instead of treating tools specially in this way, we should have another property $(SkipFrameworkFolders) (different name maybe) which does the same but does not imply any $(BuildOutputTargetFolder).

When nuget.exe calls into the pack target, -Tool will set $(BuildOutputTargetFolder) to tools and $(SkipFrameworkFolders) to true (so as to not break existing functionality).

[MaxG117]

I have a question about mapping from NuSpec attributes to MSBuild properties. This issue is mentioned at https://github.com/NuGet/Home/wiki/Adding-nuget-pack-as-a-msbuild-target#feedback. I spent a few hours looking for the answer and couldn't find a better place to ask this.

Does the NuSpec <references> element have an equivalent in MSBuild / csproj? My nupkg contains multiple assemblies, but the target projects that use my package should only reference one of them.

I was able to do this with a .nuspec file per https://docs.microsoft.com/en-us/nuget/reference/nuspec#explicit-assembly-references, but I'm trying to move everything to .csproj and this is the only missing piece.

[honzajscz]

There is a type in the property IncludeBuildOuput - a missing t

[jnm2]

Instead of treating tools specially in this way, we should have another property $(SkipFrameworkFolders) (different name maybe) which does the same but does not imply any $(BuildOutputTargetFolder).

Following on, since this need hasn't gone away:
#6184 (comment)
#6793