Skip to content

Converting a Library to NetStandard

Sponsor: Using RabbitMQ or Azure Service Bus in your .NET systems? Well, you could just use their SDKs and roll your own serialization, routing, outbox, retries, and telemetry. I mean, seriously, how hard could it be?

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


I have a tiny library that I wanted to convert to .NET Standard Library.  After all was said and done, I figured it might be useful to even point out some minor things I had to deal with along the way.  So here’s a mini guide on converting a library to netstandard.

.csproj conversion

First was I was going to convert the older csproj to the new style used for NetStandard and NetCoreApp. You have few different options here:
  1. Create a new NetStandard Library project and copy all the files over.
  2. Rewrite the existing csproj file
  3. Use a conversion tool (CsprojToVs2017)
I decided to go with option #2 and keep my existing project but just rewrite the csproj file.  If you are interested in all the gory details of how to do so, I suggest reading Nate McMaster’s psot: Old csproj to new csproj: Visual Studio 2017 upgrade guide. My new csproj ended up pretty lean and there are only two things I was concerned with.

Package References

All your package references are now in the csproj and no longer in the packages.config.  Which is glorious.  This means just looking at your existing packages.config and adding the relevant <PackageReference> to your csproj.

AssemblyInfo

All the assembly info is now also in the .csproj instead of being in a Properties/AssemblyInfo.cs file.  This is easily translated over as well.

Slim .csproj

The end result is a much smaller csproj file.  Prior the file was 126 lines, and now after conversion is 18.

xUnit Tests

I could not get the Visual Studio Test Runner or by calling dotnet test to recognize the tests that are inside a netstandard library.  Because of this I changed my test project to be a netcoreapp1.1, which then worked.

NuSpec

If you are building a NuGet package, the files to be included in your nuspec file will likely have to change since the output of your assemblies will be prefixed with the TargetFramework.  In my case this now resulted in the assemblies being outputted to: bin\Release\netstandard1.6\Nancy.Gzip.dll

AppVeyor

There were a couple of changes I need to make in AppVeyor as well.  First I needed to change my build worker image to Visual Studio 2017.  This can be found in Settings > Environment, if you’re using the UI. As of this post, since I converted my test project to .NET Core, the tests were no longer running.  This is a known issue. Current workaround is to change your Tests to be executed by a script rather than auto discovered.  This way you can execute dotnet test

Your Experience

That was my end to end experience of converting a small library to the new NetStandard.   If you have migrated any of your libraries, what other pain points or tips can you share? I’d love to hear them in the comments or on twitter.