How can I publish my API results but produce a .nupkg for the output?

[julealgon]

I would like to experiment with the idea of packaging our deployable modules from a monorepo as .nupkg files and then use that as the mechanism for installing our projects into various VMs later. This would be somewhat similar to what Octopus Deploy does (or did? not sure if they still use NuGet for that purpose, but that's beside the point): using NuGet packages as the medium for transporting and installing runnable projects, APIs and services.

My question then is: can I customize my projects in a way that when running dotnet pack on them, what is output is a .nupkg file where its contents are the same contents that are usually produced when executing dotnet publish?

I know I could manually produce a .nuspec file and then manually generate NuGet packages from the outputs of dotnet publish for each folder, but this would make our deployment procedure significantly more convoluted. Instead, I wanted to be able to call dotnet pack against the entire solution, and have it produce the packages for the projects that I customized (I'd annotated all irrelevant ones with IsPackable=false), so that I can then just push those packages to one of our internal nuget feeds.

What would the best approach be to achieve this?

[baronfel]

This is more a question for the NuGet/Home repository, but I can at least get you pointed in the rigth direction.

Check out the docs at https://learn.microsoft.com/nuget/reference/msbuild-targets#advanced-extension-points-to-create-customized-package - there are many extensibility points in the NuGet Pack Targets that you can use to
a) trigger whatever projects you need to Publish (or whatever your goal is)
b) discover and add whatever files you need to the automatic Pack implementation

[julealgon]

Why do you feel like this is more of a NuGet question @baronfel ? Isn't this solely dependent on MSBuild publish/pack targets and the exposed variables from that?

As I mentioned, I know how to create a raw .nuspec file and then generate a package from that, but that's not what I'm attempting to do here.

Do you happen to know, for instance, if there is a simple way to ensure that the files produced in the pack process are the same as the ones that are normally output by the publish process? Is there a way to "layer" them, or is this already what happens behind the scenes?

Check out the docs at https://learn.microsoft.com/nuget/reference/msbuild-targets#advanced-extension-points-to-create-customized-package - there are many extensibility points in the NuGet Pack Targets that you can use to
a) trigger whatever projects you need to Publish (or whatever your goal is)
b) discover and add whatever files you need to the automatic Pack implementation

Will definitely take a look regardless, thanks!

[baronfel]

It's NuGet because MSBuild doesn't own the definition or behavior of the Pack Target - anything related to pack is owned and controlled by that team. We work together quite often, but for attribution purposes, it's important that issues and discussions be raised on the appropriate repo.

[julealgon]

Fair enough. I'll move the question there then.

And do you happen to know whether pack builds on top of publish somehow or if they are completely isolated from each other?

[baronfel]

What Pack does depends a lot on the project that's being Packed - most projects that are packed implicitly depend on the Build Target through this default linkage that the NuGet Pack MSBuild logic sets up. However, the .NET SDK has a feature called 'dotnet tools' that takes a more hands-on role in determining what files to package - you can see that logic here. I think tools will be very close to what you want to do.

In either case, though, I will strongly suggest getting the MSBuild Log Viewer and digging into some binlogs of projects you would like to Pack to understand how all of the existing NuGet packaging knobs work together to actually create the package.