4
votes

I have a .NET Standard 2.0 project called ProjectName.Logging with a ProjectName.Logging.nuspec file.

This file file is referenced in the .csproj of my project

<PropertyGroup>
  <TargetFramework>netstandard2.0</TargetFramework>
  <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
  <NuspecFile>ProjectName.Logging.nuspec</NuspecFile>  
</PropertyGroup>

Here is my .nuspec

<?xml version="1.0"?>
<package >
    <metadata>
        <id>ProjectName.Logging</id>
        <version>1.2.1</version>
        <authors>Jérôme MEVEL</authors>
        <description>Just a logging component</description>
        <dependencies>
            <dependency id="Dapper" version="1.50.5" />
            <dependency id="Another.Project" version="1.1.1" />
            <dependency id="Microsoft.Extensions.DependencyInjection" version="2.1.1" />
            <dependency id="Microsoft.Extensions.Logging" version="2.1.1" />
            <dependency id="Microsoft.Extensions.Logging.Abstractions" version="2.1.1" />
            <dependency id="NLog" version="4.5.8" />
            <dependency id="NLog.Extensions.Logging" version="1.2.1" />
            <dependency id="NLog.Web.AspNetCore" version="4.6.0" />
            <dependency id="System.Data.SqlClient" version="4.5.1" />
        </dependencies>
    </metadata>
    <files>
        <file src="bin\Release\netstandard2.0\ProjectName.Logging.dll" target="lib/netstandard2.0/ESHCloud.Logging.dll" />
        <file src="ProjectName.Logging.targets" target="build/ProjectName.Logging.targets" />
        <file src="NLog/Nlog.config" target="content/Nlog.config" />
    </files>
</package>

As you can see I manually include the ProjectName.Logging.dll file and I even have to include Release because the usage of the MsBuild variable $(Configuration) doesn't work in my .nuspec file.

I pack the project by executing this command in my project's directory

dotnet pack --output C:/Nuget --force

and if I remove the <files> element from my .nuspec when I run the dotnet pack command, my generated Nuget package is completely empty.

On the other hand if I run the dotnet pack command without a .nuspec file, absolutely everything in my project is included in the Nuget package.

So what's the deal with the dotnet pack command? I don't understand what am I doing wrong.

How to include my project's DLL in the Nuget package without having to specify the configuration (Debug or Release)?

One last thing: I don't want to use the nuget pack command.

I played enough with Nuget on our VSTS servers (recently renamed Azure DevOps) and I don't have full control over these build servers (my manager has but he seems too busy to care about it).

So to sum up, nuget pack is not an option for me. I want to use dotnet pack along with a .nuspec file.

Thank you

1

1 Answers

4
votes

To add your DLL without specifying the configuration use a glob pattern:

<file src="runtimes\**" target="runtimes/"/>

If you use nuget.exe you could use a replacement token:

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

If you really need to use the nuspec file you're better off using nuget.exe. If you don't want to use nuget.exe drop the nuspec. I've done a fair amount of work with dotnet and nupkgs the last few weeks and mixing nuspec with project files is fiddly.

You can put the majority of the nupkg meta-data directly in the csproj:

<PropertyGroup>
  <PackageId>Subor.nng.NETCore</PackageId>
  <PackageVersion>0.0.2</PackageVersion>
  <Authors>Subor</Authors>
  ...
</PropertyGroup>

This is the recommended approach when using the dotnet CLI. Likewise for msbuild with the PackageReference format.

Here's an example of a project I've been working on. dotnet pack builds a package bin/Debug/ and dotnet pack --configuration Release builds this nuget.org package.

Everything in the project should not get copied into the nupkg. In Visual Studio check the Properties of the files and make sure everything isn't flagged as "Content", etc.. Also check the project files to see if files are getting added that shouldn't be. Look for (miss-)use of <PackagePath> and <IsPackable>.

Without knowing the particulars of your project, I'll mention trying some of the arguments to dotnet pack.