Open Sourcing .NET Core

Recently Microsoft’s announced that with the next version of .NET, it will “open source” most of the full server-side .NET core stack thereby manifesting .NET in a cross-platform way on Linux and the Mac OS X.  I say this is the biggest and most important announcement in the Microsoft developer ecosystem since the announcement of .NET itself over a decade ago. 

But, if you are like me and have an “engineer mentality”, you have been wondering how in the world they are going to pull it off without screwing the whole thing up.  Let’s face it.  Not every open source project succeeds.  In Fact I would guess that most fail.  There is huge risk in open sourcing .NET without a strategy, a tactical plan and execution.  If you read on I believe you’ll see they have all three.

.NET Core

In the grand scheme of things the next version of the .NET platform is currently called “.NET 2015”.  Within the .NET platform the current versions of the .NET Framework will live side by side with a new, modular implementation of .NET that can be used in a wide variety of solution scenarios that scale from the data center to touch based devices and everything in between.  This modular implementation will also be available as open source, and will be supported by Microsoft on Windows, Linux and Mac OSX.  This Modular implementation is called .NET Core.

To create .NET Core, Microsoft forked the NET Framework.  Even though .NET Native (ie: touch based devices) and ASP.NET 5 (server side web development) are quite different, Microsoft created a unified Base Class Library (BCL).   In terms of the surface area of the API for the .NET Core, BCL is identical for both .NET Native as well ASP.NET 5.  At the lowermost part of the BCL there is a very thin layer that is specific to the .NET runtime.  There are currently two implementations: one is specific to the .NET Native runtime and one that is specific to CoreCLR, which is used by ASP.NET 5. 

Which leads me to a point I made in my last column: If Microsoft is going through the pain to pull off everything needed for these two implementations, then why not just build the entire thing out including the client stack (thereby eliminating the need for Xamarin to do cross platform client development).

Anyways, most of the BCL is pure MSIL assemblies that can be shared as-is: the APIs don’t just look the same – they share the same implementation.

Living above the BCL are app-model specific APIs.  A couple of examples:

·       ASP.NET 5 adds APIs such as MVC that are specific to server- side web development.

·       The .NET Native side provides APIs that are specific to Windows client development, such as WinRT interop.

.NET Core is designed to be generic to either .NET Native or ASP.NET 5; the BCL and the runtimes are general purpose and designed to be modular.  Because they are designed this way it forms a modular foundation for all future .NET implementations.

“The .NET Core platform is a new .NET stack that is optimized for open source development and agile delivery on NuGet.” Says Immo Landwerth, program manager on the Base Class Libraries (BCL) team at Microsoft.   How times have changed.  What a great and positive step into the new future of .NET.  I know I have said this before, but what a great time it is to be a developer on the .NET platform.   And let’s face it: when they killed Silverlight and slapped that winRT thing in our face at the expense of .NET I wasn’t saying that; and neither were you.

For a deeper, more detailed dive into .NET Core and how Microsoft is going to pull this off I strongly suggest you read Immo Landwerth’s official blog post from December 4^th, 2014 on this very subject.   A “developer alias” email I read from Scott Varcoe so eloquently put it, “This should be required reading for every .NET software architect and developer.”