[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.