Microsoft forks .NET and WHOMP! Here comes .NET Core app dev stack
Modular platform will be more agile - but devs fret over porting
Microsoft has revealed more details about .NET Core, "the foundation for all future .NET platforms".
In a detailed post, Microsoft’s program manager Immo Landwerth explains why the company is forking .NET in order to make sense of shipping .NET for multiple platforms, including Windows desktop, Windows Store (or “Metro”), Windows Phone, ASP.NET (the web application stack), and following last month’s announcement, Mac and Linux.
First released in 2002, the .NET Framework is based on a Common Language Runtime which executes code written in languages including C#, F# and Visual Basic. There are also extensive libraries and frameworks, including the Base Class Library (BCL) for standard types and functions, and frameworks such as ASP.NET and Windows Forms which are built on top.
The .NET Framework and C# language were a hit with developers, and Microsoft created different versions in order to target more platforms, such as embedded and mobile. These differences cause problems for developers when they need to write code for more than one platform.
The company made this worse by changing track from time to time. Silverlight, for example, seemed once to be the direction for mobile and cross-platform .NET, and is used in the first version of Windows Phone, but Windows Phone 8 and Windows 8 Store apps do not use Silverlight but a different and incompatible runtime.
Microsoft addressed this to some extent with Portable Class Libraries (PCL), which define a subset of the .NET Framework that works across all the platforms you specify. PCLs are a fudge though; the multiple incompatible libraries remain underneath, but the PCL wrappers prevent you from calling an API that will break compatibility.
At its Build developer conference earlier this year, the company introduced Universal Apps, touted as a way to build apps that work on Windows Phone as well as Windows 8. A Universal App is a project type that lets you share code, but you still write platform-specific code where necessary, so it's not quite the magic that it first appears to be.
Introducing .NET Core
Now there is .NET Core, which includes a new modular fork of the .NET Framework. .NET Core includes a unified BCL which is the same code for all platforms - Landwerth says that .NET Native, a project to compile Windows Store Apps as true native code, currently has its own implementation.
ASP.NET 5 (the forthcoming version), Windows Store apps, and the open source .NET code managed by the .NET Foundation all use .NET Core. Sharing code across platforms should be easier with .NET Core, since the libraries really are the same.
What may be more significant is that .NET Core introduces a new deployment model. The libraries are delivered as NuGet packages, this being the package manager used by Visual Studio to import .NET code into projects. The idea is that developers will import just those parts of .NET Core that they need for their project, and deploy them with the application.
Microsoft calls this app-local deployment. In contrast to the original .NET Framework, which is a system-wide set of libraries, every .NET Core application will ship with its own individual framework. This means that updates to .NET Core will not break existing applications, which further implies that it can be updated more rapidly. It also means that the .NET Framework no longer needs to be installed in the right version on the target system; it is all part of the application.
The downside of this approach is that with each NuGet package that forms part of .NET Core being updated individually and at different times, there is a risk of incompatibilities appearing. “Since you’ll be able to mix-and-match NuGet packages there can obviously be cases where certain combinations of components don’t play well together,” said Landwerth. In order to overcome this, Microsoft will ship “distributions” of .NET Core that are tested for compatibility. The plan is to ship a new distribution four times a year.
Another problem is how to update .NET libraries if security problems are found. “Critical security fixes must be deployed quickly and holistically in order to be effective. We are fully committed to making security fixes as we always have for .NET,” added Landwerth, though he does not state how this will work.
Presumably if version “n” of a specific NuGet package is found to be insecure, there will be a mechanism for seeking out these instances and updating them.