allow dotnet pack to pack nuspec file without needing a csproj file

[natemcmaster]

Follow up to #3904 (comment)

Scenario:
I want to pack a nuspec file in an x-plat build system.

Inputs:

• nuspec
• files

NB: I am not packing a csproj, just files.

In <= 4.0.0-rc2, this was available as dotnet nuget pack (nuspec) file. This was removed in 4.0.0-rc3 NuGet/NuGet.Client#1065 without a suitable replacement.

More data to consider:

• This is is a common scenario for the ASP.NET Core runtime team.
• Although possible to use nuget.exe, this requires running 'mono nuget.exe' on xplat, which is less than ideal, not to mention buggy.

cc @emgarten @rohit21agrawal

Please 👍 or 👎 this comment to help us with the direction of this feature & leave as much feedback/questions/concerns as you'd like on this issue itself and we will get back to you shortly.

Thank You 🎉

[rohit21agrawal]

closing this as a duplicate of : #4250

[natemcmaster]

I don't think these are duplicates. #4250 is about issues packing with csproj + nuspec. This one is about packing nuspec without a csproj file.

[rohit21agrawal]

aah i see, i don't think this will be accommodated in 4.0-RTM as you need a way of getting the Pack targets imported so dotnet pack can work properly - which is why we have a requirement of having a dummy csproj right now

[enricosada]

Same issue there. But if possibile can be done like csproj instead of nuspec? One thing less to learn.

For me is not an issue use a csproj instead of nuspec who can dotnet pack, but without doing AND requing the build.
If i use --no-build the dotnet pack anyway expect the built assemblies so fail.

Maybe we can use the csproj, but the dotnet pack --no-build --no-assemblies who doesnt build and doesnt expect built assemblies.
A property inside csproj is ok too <PackageNoAssemblies>true</PackageNoAssemblies> to configure that.

[rohit21agrawal]

@enricosada you can use <IncludeBuildOutput>false</IncludeBuildOutput> to achieve the same.

[rohit21agrawal]

To see a list of all possible scenarios in dotnet pack, refer to : https://github.com/NuGet/Home/wiki/Adding-nuget-pack-as-a-msbuild-target

[natemcmaster]

For a little more context: the scenario I have in mind is that we produce some custom nuget packages with layouts that are hard to achieve using csproj, or even some packages that don't come from a .NET project at all.

Example: https://github.com/natemcmaster/libsqlite3-package/blob/ba16e2ede7768cf80cfe7a6023109e2c5a59e30e/SQLite.nuspec

[enricosada]

@natemcmaster using a csproj like

    <Content Include="files/SQLite.props">
      <PackagePath>build\net45\</PackagePath>
      <Pack>true</Pack>
    </Content>

doesnt work? i can set <PackagePath> to specify any directory inside package

[natemcmaster]

Yes, that would work for that specific example, but why should I need a csproj when I'm just packing things? I'm not compiling C#.

[rohit21agrawal]

You need a way to import the pack targets, and that is being achieved by having a csproj that does that for you.

[enricosada]

@natemcmaster

• dotnet pack --no-build doesnt compile
• one sintax to lean, the msbuild based csproj/fsproj (used often i think if dotnet pack works) instead of the nuspec

[enricosada]

thx @rohit21agrawal works, using

    <IncludeBuildOutput>false</IncludeBuildOutput>
    <DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>

and

dotnet restore
dotnet pack --no-build

generate the nuspec, with no compile and no dependencies (i dont need these)
the dotnet restore is unfortunate, but better than nothing atm

[karajas]

Just wanted to follow up in this thread, I too would like a way to pass in the nuspec directly with the option to pass in command line nuspec properties. Is something like this in the pipeline?

dotnet pack /p:NuspecFile=myproject.nuspec /p:NuspecProperties=""

Could a default pack.targets file be imported if a nuspec file is passed on the command line? This would ensure that the right targets would be imported in the case of both csproj and nuspec files.

[anangaur]

We should allow dotnet pack with nuspec files. Currently this is a major dissatisfaction for pack on Linux and non Windows platforms.
I think the following option would be better:

> dotnet pack <project> --nuspec-file=myproject.nuspec 

[FredrikLarssonn]

+1 We create our own nuspec from a csproj to tell other dependencies and set other dependency versions

[anitsch-scs]

+1

[JonDouglas]

Hi friends,

As you may have seen, we've tagged this issue as a potential item for this year. I know there have been a number of "+1s" and 👍, but we need some more help.

If you can give us a quick comment on how this functionality will help your scenario if it's not already listed(installers, re-packing, templates, wrapper packages, repository migration from nuget.exe to dotnet CLI, etc) that would be especially helpful. The more the merrier.

[Nirmal4G]

You don't need to have a project file to pack MSBuild SDK and Extension packages if they don't need to have compiled code. Having project files in this scenario just complicates things...!

[Nitschi]

This would help us in 3 ways:

• Allows the chocolatey team to get rid of the mono/nuget dependency and move to dotnet core => Allow packaging chocolatey packages on Linux
• Or it allows us to do that directly without waiting for the chocolatey team to implement this

Non-choco:

• Allow for simple csproj files for development and use NUKE to worry about what should and what shouldn't be packed inside the .nupkg

[gao-artur]

We are distributing proto files with nuget as described here. We don't need the project file, we don't want to run build/restore to pack non-dotnet files.

[Steinblock]

As described here: #4254 (comment)

I have a backend asp.net project and a frontend vue project.

I pack the frontend in a single nuget package via a CI/CD pipeline that only needs to contain content files (html/js/css). The backend project uses this package to serve the files from wwwroot.

With .net 4.x I could just use nuget.exe pack and a nuspec file for that.

Now my frontend is build in a linux docker container with npm build so I want to use dotnet pack with the same nuspec file which is not possible without a project.

[aronweiler]

I have a CI/CD system that dynamically produces NuGet packages, and we don't want to modify CSPROJ files!

[dzuerrer]

We have 3rd party software that is made available only as .dlls. Currently we use nuget.exe to package them as nuget packages and reference them in our projects.
If dotnet nuget supported this, we could use our linux build environment to do this instead of the windows developer machines.

[csdahlberg]

My scenario is that I want to build a single analyzers NuGet package that targets multiple versions of Roslyn. It needs to contain analyzers/dotnet/roslyn2.6/cs/Analyzer.dll, analyzers/dotnet/roslyn3.8/cs/Analyzer.dll, etc., each variant built from the same project but with different properties set.

As far as I can tell, the authoring experience (mentioned in dotnet/sdk#20355 (comment)) for this scenario still has not [yet] been implemented.

I threw together some PowerShell scripts that fit my needs, including one to build a NuGet package from a .nuspec file: https://gist.github.com/csdahlberg/56e482c6ab28f93680bef3879c6473b0

[zivkan]

Just an FYI to the people in the thread who say they want to just use the dotnet CLI, a workaround is to use the MSBuild pack NuspecFile property: https://learn.microsoft.com/en-us/nuget/reference/msbuild-targets#packing-using-a-nuspec-file

It's not perfect, I'm not proposing this as a "solution" to avoid implementing the proposed feature. I'm just saying that using features that have been shipping for multiple years, it's possible to pack a nuspec using only the .NET SDK CLI.

It can be scripted by running dotnet new classlib in an empty folder, then dotnet pack -p:NuspecFile=/path/to/your.nuspec -o /path/to/outputDirectory/. There are of course many more options, like committing the csproj to source control, specifying NuspecFile in the project file's <PropertyGroup>, perhaps using Sdk="Microsoft.Build.NoTargets" (although the docs propose a different solution to avoid building the project).

[davezhouwa]

In our case, we have used nuget pack to create packages without requiring a csproj file. We have close to 100 repositories doing this way. As we are looking into the new mariner docker 2.0 image, we found mono is required to make it work. However, mono is not available.

Our repositories are mainly Python based and for AI & Machine learning, the production system requires shipping the artifacts through nuget format. Having every repository creating a dummy csproj is a non trivial task.

Bringing back a previously function which worked before and for a large set of cases is highly desirable.

We tried above approach suggested by @zivkan above and it didn't work.

[tebeco]

sounds like a perfect opportunity to create an nuproj @zivkan
with MSBuild support and defacto feature parity with csproj + dotnet pack out of the box

which also would allow dotnet/nuget team to continue killing nuspec files and nuget.exe

[Nirmal4G]

which also would allow dotnet/nuget team to continue killing nuspec files and nuget.exe

Removing nuspec files won't happen as they are what defines a NuGet package!

[tebeco]

not really no.
they are one way to define it
when you run dotnet pack on a csproj you don't explicitly have a nuspec file and you don't need it

nuspec is inherently bad if you try to integrate your build system with msbuild
which is what the current dotnet pack + csproj fix

the remaining issue is bundling static content like raw dll for example.

as per my first sentence, getting a an nuproj could leverage on all the existing msbuild integration already done by nuget team and just don't call the c# compiler but still produce an output nupkg

in all that a nuspec is not / was not / would not be necessary to exists

[Steinblock]

Correct me if I'm wrong but I think the csproj creates a nuspec file under the hood anyway.
Eventually the nuspec file is copied to the nuget package and holds the metadata. So we still need it.

Maybe someone can tell if the creation of the nuget package itself is just based on the nuspec file (which would be possible IMHO) or the csproj file is needed internally.

But I agree. There shouldn't be a dedicated nuget.exe that I as a developer need to call but it should be possible to just use dotnet pack with the right arguments to trigger a nuget package build from a nuspec file.

Just one thing I would like to mention.

I use the replacement tokens ($id$, $version$) a lot.

With nuget.exe I could just use nuget pack -properties <name>=<value>;<name>=<value>

With dotnet core and a csproj file I need to use

<PropertyGroup>
    <NuSpecProperties>version=$(Version);owner=itsamemario</NuSpecProperties>
</PropertyGroup>

The dotnet pack ... -p:Version=1.2.3 -properties "version=$(Version);owner=itsamemario" should be possible, too.

Or just allow to directly use properties instead of the replacement tokens in a nuspec file. So

  <metadata>
    <id>$id$</id>
    <version>$version$</version>

Could be rewritten to

  <metadata>
    <id>$(id)</id>
    <version>$(Version)</version>

[tebeco]

With dotnet core and a csproj file I need to use

<PropertyGroup>
    <NuSpecProperties>version=$(Version);owner=itsamemario</NuSpecProperties>
</PropertyGroup>

Why not one of the existing:

• dotnet pack /p:Version=1.2.3-rc1
• dotnet pack /p:VersionPrefix=1.2.3 /p:VersionSuffix=rc1
• dotnet pack

  <Version>1.2.3-rc1</Version>

• dotnet pack

  <VersionPrefix>1.2.3</VersionPrefix>
  <VersionSuffix>rc1</VersionSuffix>

https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package-msbuild

[tebeco]

this message above is why I mentionned there's already some MSBuild integration in place with csproj and that something like nuproj and not calling the C# compiler would probably be really near to what already exists today

The fact that internally it generates a data model in shape A or B (and/or a nuspec) is irrelevant as a consumer.

• what's the consumer/user experience today ?
  => dotnet pack
• is nuspec ported to dotnet pack ?
  => no
• should we assume dotnet pack on csproj internally generate ANOTHER file format AND THEN another trasnfo for nupkg ?
  => I sincerly don't know.
  but that does not sound like a good assumption.
  The nuget client is already C# code from Nuget.Client, which is what's being (partially?) pulled into dotnet CLI.
• does dotnet pack already have code to read MsBuild logic and map that to existing data for packaging ?
  => yes, see previous message
• do we need a nuspec ?
  => no

What's needed is a way to "arbitrary pack" ... "stuff" like static content / raw file / etc ...
if dotnet CLI already leverage heavy lifting and MsBuild Stuff for csproj today.
I'm guessing reading the same PropertyGroup from the same MsBuild Engine with the same code would souns relativly possible.

The benefits of that would be to have that included in Visual Studio ... directly "as a project" for example
you would be able to run dotnet build and dotnet pack on that SLN ... IF YOU HAVE ONE
and it would properly continue to Generate and do Authoring with stuff like:
Directory.Build.props or OutputPackageFolder or Unified Version from your CI etc ...

and just like it's already working today, having an nuproj would have dotnet pack work on it just like you have nuget pack on nuspec

That's what my many post above are trying to point out.

moving back to nuspec again, would definitly make "legacy" works, but it's still legacy.
We'd loose the msbuild tooling integration with EnvVar / Props / CI / Scaffolding etc ...

The issue with nuspec is that it require dedicated tooling/toolset to automate fields change inside

I'm hinting at a solution that would somehow be in the middle of nuspec and csproj which ... even if my hope/expectation are low, I think it would answer many concerns here.
I also suspect that nuget team could also, with the help of the community write a tool like dotnet nuget convert and change a nuspec to a nuproj and call it a day

as you can see:
these 2 step should be what the nuproj would have to fix to try achieving what's asked in this issue

#4254 (comment)

and as many mentionned it, since it's about not calling C# SDK / ....
it probably would be what SDK and not Proj file are for:

<Project Sdk="SomethingSomething.Nuget">
</Project>

[Nirmal4G]

Correct me if I'm wrong but I think the csproj creates a nuspec file under the hood anyway. Eventually the nuspec file is copied to the nuget package and holds the metadata. So we still need it. — @Steinblock

@tebeco What he said!!!

[Nirmal4G]

Maybe you don't want to depend on NuSpec when you're building from a project file but that's our preference and not a requirement for the design of the package under the hood.

May be we can abstract it away using an MSBuild SDK like I did (e.g., NuGet.Packaging.Sdk) but that seems a long stretch of a request for the team! But one that, I definitely want it.

[pgolinski]

We have third party native dlls that we want to pack as nuget. Installing the nuget adds copying the dlls to output on build. I don't need csproj for that. I was sure I can pack a nuget from nuspec with dotnet pack. I was very much wrong

[wardboumans]

Guess this is still not possible?