Skip to content

.net core 2.0 migration

.NET Standard and .NET Core have been on my mind for a long time now – years really, but the reality is while I’ve been using the technology quite a bit, I’ve not jumped in with both feet. In fact, to date, I have yet to build anything ‘real’ for customers beyond a few sample applications.

For me personally, .NET Standard 2.0 and .NET Core 2.0 with their much bigger base library foot print and the real possibility of porting the majority of existing library code over to .NET Core really has been a deciding factor for me to start moving some of my existing full framework libraries that I’ve been using for as long as I have been using .NET to .NET Core 2.0. Being able to bring some of the tools I use to be productive over to .NET Core is actually pretty important factor to overcoming my reluctance to move into .NET Core. Nobody wants to rewrite code they already have just to get back to square one, but with .NET Core 2.0 it really looks like most code will migrate pretty easily.

This isn’t just important to me personally, but I think this is a vital requirement for moving much of the support libraries that exist for .NET into .NET Core and providing the full featured eco-system that we’ve come to expect from .NET applications. Currently, with .NET Core 1.x it’s been hit or miss feature wise to feel confident you can actually make it through a project without getting stuck with some missing core feature you can’t easily find and have to build from scratch. My feeling is that .NET Core 2.0 will change all that by making it possible for most libraries to be ported with minimal effort.

In this post, I will describe migrating an existing full framework library to .NET Core 2.0. The porting process was even easier than I expected, although the tooling required a bit of patience to get on with.

What you need to follow along: