This is a series on the .Net Core 1.0 bits. Looking for .Net Core 2 Series?

• Getting Started
• What’s in the box
• Using Multiple Projects
• Testing
• NuGet <=(We are here)
• Multi-targeting
• Publishing Portable Applications
• Self-contained Applications

Let’s set aside Application packing for later, and focus our attention on NuGet.

Our Demo library

Again we will quickly whip up a library to use:

mkdir mynewpackage
cd mynewpackage
dotnet new -t Lib
dotnet restore
dotnet build

Some quick touch-ups to make it more interesting. Replace Library.cs with this again:

namespace mynewpackage
{
    public class Calculator
    {
        public int Add(int first, int second)
        {
            return first + second;
        }
    }
}

At least now our package contains something interesting.

Simple Packing

It isn’t very difficult to turn our library into a nupkg (pronounced NUP-KEG, of course).

dotnet pack

This leaves us with a directory structure like so:

mynewpackage  
|-- Library.cs
|-- project.json
|-- project.lock.json
+-- bin
     +-- Debug
          |-- mynewpackage.1.0.0.nupkg
          |-- mynewpackage.1.0.0.symbols.nupkg
          +-- netstandard1.6
               |-- mynewpackage.deps.json
               |-- mynewpackage.dll
               +-- mynewpackage.pdb

(Note that I have left out the obj folder), we can see two new files have been created under /bin/Debug: mynewpackage.1.0.0.nupkg and mynewpackage.1.0.0.symbols.nupkg.

These are the NuGet packages. Pretty easy huh? The version number comes from the project.json file:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable"
  },
  "dependencies": {},
  "frameworks": {
    "netstandard1.6": {
      "dependencies": {
        "NETStandard.Library": "1.6.0"
      }
    }
  }
}

But that was a Debug build. To produce a release build instead:

dotnet pack -c Release

Now we have some new files:

mynewpackage  
|-- Library.cs
|-- project.json
|-- project.lock.json
+-- bin
     +-- Debug
     |    |-- mynewpackage.1.0.0.nupkg
     |    |-- mynewpackage.1.0.0.symbols.nupkg
     |    +-- netstandard1.6
     |         |-- mynewpackage.deps.json
     |         |-- mynewpackage.dll
     |         +-- mynewpackage.pdb
     +-- Release
          |   mynewpackage.2.0.0.nupkg
          |   mynewpackage.2.0.0.symbols.nupkg
          +-- netstandard1.6
               |-- mynewpackage.deps.json
               |-- mynewpackage.dll
               |-- mynewpackage.pdb

We can see that we now have a Release folder (containing a netstandard1.6 folder, thanks to an automatic build before the pack) and in the Release folder, we again have mynewpackage.1.0.0.nupkg and mynewpackage.1.0.0.symbols.nupkg files.

Crack open a nupkg

What do these nupkg files look like on the inside? Using a tool like NuGet Package Explorer we can take a look. The Release version looks like this:

mynewpackage.1.0.0.nupkg
|-- mynewpackage.nuspec
+-- lib
     +-- netstandard1.6
          +-- mynewpackage.dll

Some things to observe. We only have a lib file for netstandard1.6 target profile. This means that our NuGet package only works with new .Net Core applications targeting NetStandard1.6 (and the upcoming 4.6.3).

Changing our attention to the contents of the nuspec file:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
    <metadata>
        <id>mynewpackage</id>
        <version>1.0.0</version>
        <authors>mynewpackage</authors>
        <owners>mynewpackage</owners>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>mynewpackage</description>
        <dependencies>
            <group targetFramework=".NETStandard1.6">
                <dependency id="NETStandard.Library" version="1.6.0" />
            </group>
        </dependencies>
    </metadata>
</package>

We didn’t override any properties in our project.json file. But we can see here that the project folder name mynewpackage is used to populate the package id, authors, owners and description. Play around for yourself at setting the correct properties in the project.json to produce your desired nupkg values.

We also see that under dependencies there is a targetFramework=".NETStandard1.6" group, with a dependency on NETStandard.Library version 1.6.0.

And the next time…

We can build packages to be used by new .Net Core applications. But we probably want to build libraries that can be used from our .Net 4.0, Windows Phone and UWP applications as well. Next up, we see how to extend our package to handle just these situations.