[Packaging] Define the way/ways that we want to create the nuget packages

[maririos]

Should we have by default dotnet pack and if the needs of a repo ask for more, then let them implement their own packaging way?

[tmat]

It's gotta be dotnet pack. That's what our customers use, we should use it as well.

[maririos]

As a default, I agree, but yesterday @weshaggard was talking about how corefx needs custom nuget packages because of the nature of the content.

[tmat]

I believe any package can be built from a project using Pack target. We have projects in Roslyn, Roslyn Analyzers, and other repos that pack meta-packages, tool packages, analyzer packages, etc.

We either use pack with handwritten nuspec, or we generate nuspec in a target.

If package just aggregates outputs of other projects (like meta-package or analyzer package) we have a dummy .csproj with no-op Build and Test targets, so that the only target that's executed is Pack target.

It works well. In future, I expect these kind of packages to be supported directly by NuGet Pack task. Once they will we can just remove our custom target without the need of changing anything else.

[weshaggard]

While I agree with the general push to use the shipping tools there are a lot of things not currently supported so we will likely be on our own custom packaging targets/tasks for the core repo's for a while to come. We can look at converting that system but that is way down on our backlog.

To give some idea we have defined our on project type call pkgproj and it handles a lot of stuff for us, such as supporting refs and multi-targeting for many TFMs that are not necessary supported by the SDK. We also have a mechanism to harvest binaries from our older packages so we can maintain compatibility with our old packages. Our package tools also have a lot of static validation built in to ensure we ship consistent and compatible packages.

@ericstj designed most of it so if you want more details I'm sure he would be happy to chat about it.

[tmat]

Custom targets are fine as long as they are chained to Pack target.
Custom project type is not ideal since it can't be part of a solution opened in VS, but still ok since your build has multiple entry points (solutions/projects) anyways.

[JohnTortugo]

I was assigned to work on what we decide here. :-)

@ericstj Do you think that we can manage to chain the custom packaging that you implemented in the Pack target?

Cc'ing @natemcmaster as this discussion might interest him as well.

[natemcmaster]

Let me lob a hand grenade.

IMO we should take a close look at using https://github.com/nuproj/nuproj. It has most of the things I want for NuGet package authoring -- dedicated project files ✅ , VS integration ✅ , simple project schema ✅, written by Microsoft (or at least, written by msft devs) ✅ .

[markwilkie]

I like using things already done. :)

What are the downsides? I presume that some of the things that Wes noted are not supported?

Also, there's much to be said for incremental steps. Implementing something we KNOW works is sometimes advantageous.

@natemcmaster - do you know yet if the current implementation in CoreFx would work for ASP?

[natemcmaster]

What are the downsides?

I'm not sure if dotnet pack works on nuproj. We might need to make a contribution to add support for running on MSBuild for .NET Core - cc @AArnott @terrajobst

I presume that some of the things that Wes noted are not supported?

Correct. AFAIK the harvesting and validation is very specific to dotnet/corefx. I have not seen stuff like this in other repos.

From my (admittedly limited) understanding of nuproj, I don't think it would be too hard to port the custom harvesting and validation from pkgproj to run in nuproj.

do you know yet if the current implementation in CoreFx would work for ASP?

I don't think it would work without a few tweaks. ASP.NET has two pieces of custom stuff.

1. One of those was this PR Add PackNuspec MSBuild task #57 which wasn't merged due to reasons I think we can resolve.
2. The other is our "NuGetPackageVerifier" console tool which runs some simple acceptance tests on .nupkg's. I think @Eilon would be happy to move this into dotnet/arcade.

[AArnott]

There's no one working on nuproj any more. It probably works (or can be made to work) with dotnet pack merely by supporting the Pack target, if it doesn't already. But it's woefully outdated in many ways. I never use nuproj any more.

My vote in virtually any use case is to use csproj's self-packing capabilities now. Even in cases where a package has to ship multiple assemblies.

[weshaggard]

It should be pointed out that our existing pkgproj stuff started with nuproj and then morphed to handle the complexities of corefx. So I think we could attempt to use the pkgproj stuff and make it work for asp.net.

The other is our "NuGetPackageVerifier" console tool which runs some simple acceptance tests on .nupkg's

It would be interesting to see what verification you guys do as we include a lot of validation in our pkgproj support.

Custom project type is not ideal since it can't be part of a solution opened in VS, but still ok since your build has multiple entry points (solutions/projects) anyways.

One of the biggest reasons we needed a custom project type was because we need to build multiple other projects in order to get all the assets necessary to create our new packages.

[AArnott]

Custom project types can load in VS so long as you follow the rules necessary for CPS to load your project. No VS extension required, potentially.

[tmat]

One of the biggest reasons we needed a custom project type was because we need to build multiple other projects in order to get all the assets necessary to create our new packages.

That's doable without custom projects. We use csproj with overridden Build target for meta-packages and tools packages.

See dotnet/roslyn#29408.