Home: Static Nuspec not included when pack the project using a .csproj file

[kmuthukumar23]

Hello guys,

Thanks in advance..

i have faced the issue in nuget pack generation by dotnet pack using .nuspec file.

I have scripts and styles in my project's wwwroot folder and nupec file for my project. These folder is shipped into the package as staticassets when i am run the command "dotnet pack ~/projects/app1/project.csproj".

But my project's nuspec file not shipped in to pack. The packed content have default dotnet nuspec file.

Actual issue:

Local .nuspec not shipped in to package when we run "dotnet pack ~/projects/app1/project.csproj". But wwwroot folder shipped as static assets. But my local nuspec file not included in generated nuget package

is this issue?

Can any one please help me on this?

[nkolev92]

Hey @kmuthukumar23,

Can you ensure that you are following the steps described in https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-using-a-nuspec?

Can you please provide a repro project?

[Denis535]

@nkolev92, I faced this problem too.

Visual Studio Pack doesn't use .nuspec file. But nuget.exe pack does use it.
I thought .nuspec is deprecated in sdk-styled projects. But now I do not understand anything.
Here is my example

Also I need to ask: what is "convention-based working directory"?
I thought nuget can automatically include files in special folders (without .nuspec). But no. Nuget can automatically include only files with build-action=content.

I wasted a lot of time. And I'm still confused ((

[Denis535]

It seems I have understood. One need to define NuspecFile property in csproj.

    <NuspecFile>ProjectName.nuspec</NuspecFile>

But this is strange, because in other projects I had seen this is not done.

[nkolev92]

@Denis535

NuGet includes the build output automatically. Content files are also included automatically.

You either use the NuGet defaults, or you use a nuspec. When you use a nuspec, it's on you to ensure the right files are packed.

[Denis535]

@nkolev92
1) Why does "VS/Build/Pack" require NuspecFile property to define? It looks like a bug. I'm sure NuspecFile property must have default value equivalent to $(MSBuildProjectName).nuspec.
2) The nuget pack command then automatically adds all files in that folder structure.
I'm confused. Should it add all files or only files with ActionBuild == Content?

[nkolev92]

For 1.

• They are different pack systems. msbuild /t:pack, dotnet.exe pack & VS pack are MSBuild based. They can only discover files based on what's included to the msbuild project. In nuget.exe pack, it's discovered based on convention.
  The migration from nuget.exe pack to msbuild.exe /t:pack should be straightforward for most scenarios given that the heavy lifting is really moving from packages.config to PackageReference.

For 2.

Convention based pack only works for nuget.exe pack, not msbuild.exe /t:pack, dotnet.exe pack and VS pack..

[Denis535]

Oh my God... At least I understand it now))

[Denis535]

@nkolev92
What features does "MSBuild Pack" not support too? And why it's so limited?

"Replacement tokens" also doesn't work in "MSBuild Pack".

    <file src="bin\$configuration$\**\*.dll" target="lib/" />
    <file src="bin\$configuration$\**\*.deps.json" target="lib/" />

[nkolev92]

@Denis535

MSBuild pack supports most features with the exclusion of assembly sniffing for version/id. It relies on the MSBuild metadata for that.

Working with a nuspec is just slightly different before of the different underlying system.
Please refer to the following doc for some examples: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-using-a-nuspec.

Replacement tokens work, but they need slightly different set-up steps.

[Denis535]

@nkolev92

Let's sum it up.
There are two ways to create a package:

• dotnet.exe
• nuget.exe

They have some differences:

• dotnet.exe requires the property <NuspecFile>***.nuspec</NuspecFile> to be defined.
• dotnet.exe requires the replacement tokens to be defined manually: <NuspecProperties>configuration=$(Configuration)</NuspecProperties>.
• dotnet.exe doesn't work with convention-based working directory. So, you should write your own *.nuspec file.

If that's all, then I guess you can close this issue.

[zivkan]

• dotnet.exe requires the property *.nuspec to be defined.

In the context of this issue, yes. But if someone reads your comment without understanding the context of the rest of the issue, no. The msbuild-based pack (msbuild -t:pack, dotnet pack, VS pack) is designed to contain everything in the csproj, so there's no longer any need for a nuspec. I'm only aware of a small number of scenarios where the MSBuild-based pack cannot do something a custom nuspec can, but many projects are able to migrate without issue.

• dotnet.exe doesn't work with convention-based working directory. So, you should write your own *.nuspec file.

The msbuild-based pack allows you to include arbitrary files in the package. There are more examples in the license file/expression and icon file sections, with a simpler syntax: <None Include="images\icon.png" Pack="true" PackagePath="\"/>

Knowing MSBuild has file globbing support, we can change the include to Include="**/*" Exclude="obj/**;bin/**".

However, this will probably cause all the files to be put in the package's root, due to PackagePath="\". My MSBuild skills are not advanced enough to know how to use the file's relative path in the project as the PackagePath metadata value.

Once that is solved, you can then use the property <IncludeBuildOutput>false</IncludeBuildOutput> to avoid a dll with no content from being put in lib/<tfm>/.

If your directory layout contains any files that a normal project will try to compile, the Microsoft.Build.NoTargets SDK might help. Despite the name NoTargets, it does have targets, just not a default target, or maybe the build target was removed. We use it as a packages.config/nuget.exe restore alternative, and restore works fine, but might need a package reference to NuGet.Build.Tasks.Pack to bring in the pack target, unless the NoTargets SDK uses the .NET (Core) SDK, in which cause it's included already.

Anyway, my point is that it's possible. It's not as easy as having a nuspec and running nuget.exe pack. Maybe it's an opportunity for someone in the community to create a MSBuild SDK that does this, so that anyone who wants it can use a proj file that contains <Project Sdk="FolderNuGetPack/1.0.0">, plus their package metadata (version, authors, description, license, icon, etc), no nuspec file needed.

Otherwise, I would say your summary is accurate.