.NET Standard Libraries and NuGet Package Wizard

A few days ago, Microsoft has released .NET Standard 2.0, which is the new dreams-come-true platform for libraries. Additionally, Portable Class Libraries (PCL) have since also been deprecated. Therefore, it’s about time to port my existing libraries.

.NET Standard 1.4 … for now!

As such, the latest possible version of .NET Standard that also supports UWP is v1.4. As this older version has the same platform compatibility (Linux, Mac and iOS and Android through Xamarin), I saw no harm in keeping the NFC library at the .NET Standard 1.4 for now.

A new library version based on .NET Standard 2.0 can be released later once the tooling is complete; even though that will most likely limit the use of that specific version to the Windows 10 Fall Creators Update. Which would mean that for maximum library compatibility, it’s better to stay at .NET Standard 1.4, or to include both versions into the same NuGet package. We’ll see.

Creating NuGet Packages through Visual Studio

Another convenient new feature of the latest Visual Studio version is that it now supports creating NuGet packages. Through a convenient visual editor interface, it’s now a lot easier for library authors to create the required
.nuspec files that define the library properties.

However, it wasn’t so easy after all. Several things are interesting and important to know:

Title / Product

So far, the
.nuspec files usually had a
<title> tag; I had that defined as:

1

<title>NFC/NDEF Library forProximity APIs</title>

This tag is not present in the editor. However, Visual Studio offers a
<Product> tag, so I put the text there instead.

When building the project, Visual Studio generates the
.nuspec file in the
/obj/ directory.

Looking into this file, it’s curious to see that the generated file neither has a
<title> , nor a
<product> tag. The name of the library simply isn’t present in the generated file; only the package ID is used. This issue has already been reported to the Visual Studio team and is being investigated.

The NuGet web site still shows the title on the package web page. However, within the NuGet Package Manager in Visual Studio, the title is gone:

The nuspec file documentation still lists that the
<title> is the human-readable name that’s also used within the Visual Studio NuGet Package Manager.

This situation isn’t ideal, as the package ID (currently “NdefLibrary”) can’t be changed easily. The package ID of my library doesn’t include the term “NFC”. As Visual Studio seems to ignore the package title, in the search other packages with a handful of downloads are ranked higher than the NdefLibrary:

I’m wondering if there is a way around this. For now, I’ve kept my manual
.nuspec file with the title, so that it’s shown at least on the NuGet website. I’ve also reported the issue to the Visual Studio Feedback tool.

Assembly Neutral Language

Another tricky thing is the Assembly Neutral Language. By default, the property is not set in the Visual Studio wizard. And you won’t notice that anything is missing for a long time: you can package the library, publish it to NuGet, reference it in a UWP app and test that app locally. Only when you try to package the app for submitting to the store, you will suddenly get the error message:

1

1>...\lib\netstandard1.4\NdefLibrary.dll:warning MSB3817:The assembly"...\lib\netstandard1.4\NdefLibrary.dll"does nothaveaNeutralResourcesLanguageAttribute on it.Tobe used inan app package,portable libraries must defineaNeutralResourcesLanguageAttribute on their main assembly(ie,the one containing code,notasatellite assembly).

That’s a bit of a surprise. The wizard interface of Visual Studio is a language drop down, so simply choose “English”. The value is saved in the
.csproj file, where it is then written as “en”.

Just make sure you always select the neutral language, so that you don’t run into issues much later on! See my Visual Studio feedback report for further details.

Symbol Packages

The third issue with the auto-generated nuget packages is that they only contain the final
.dll file, but not the
.pdb file that libraries should publish to the symbol server to make debugging easier for library users.

In the ideal case, the library package also includes the source code, so that developers that have issues can directly see what’s happening within the library.

The code in the
.nuspec file needs to be written manually in order to include these additional items – the auto-generated version by Visual Studio would only include the
.dll , nothing else.

Publishing the Package to NuGet Servers

Now that the NuGet package is created, you can finally publish the package to the NuGet servers.

The instructions for publishing a package including a symbol package for debugging are not fully up-to-date, however. The current NuGet versions always require specifying a source. They don’t default to the NuGet servers anymore.

In case you have two packages in the same directory – the normal one that goes to the NuGet server (NdefLibrary.4.1.0.nupkg), as well as the symbol package (NdefLibrary.4.1.0.symbols.nupkg), the tool will automatically find the symbol package and push that to the corresponding server without you having to specify that.