Big changes are coming to the .NET platform that affect your development wherever you use .NET. The direction helps you develop applications (Web, Azure, Phone, Desktop. Windows Store, Linux, MacOS, iOs and Android) easier. So if you are going horizontal and targeting more than one variation of Windows, then this is for you.
For developers and architects, it provides keys to a new way to looking at how your code should be written. The new .NET implements the kinds of features we face every day. And the solutions are evolving from vertical solutions where each problem was a subset of some other bigger problem. Rather it becomes a set of contracts, where dependencies are clearly defined, where the contract can be implemented in different ways to meet specific needs.
Migrating the .NET base is no small task. Yet, the Microsoft teams have taken on the challenge to make it easier to build applications across platforms — and not just Microsoft platforms.
The new direction includes:
- Merging APIs into contracts to allow the targeting of multiple verticals
- No longer have different versions of .NET Framework
- .NET Core is a modular development stack that is the foundation of all future .NET platforms
- Combine unified Base Class Library
- Open Sourcing more of .NET. You’ll get .NET via NuGet, with source on GitHub.
This post boils down what these changes mean to developers and architects. And what it means to your code today. I’ve selected key passages from Introducing .NET Core. But you will also want to dig more into the article and watch as features are rolled out.
Contracts for targeting multiple verticals
Today’s applications span devices. There almost always a back end that runs on the web server, and an administrative front end that uses the Windows desktop, and a set of mobile applications that are exposed to the consumer, available for multiple devices. And probably one or more web experiences depending on the user role. Thus, it’s critical to support developers in building components that can span all the .NET verticals.
When you wanted to program across multiple user experiences, you could use portable class libraries. The idea was to put your business logic into a common set of libraries that you could then use to target different user experiences.
The new thinking is to provide contracts is to provide a well factored API surface area. Contracts are assemblies that you compile against. A contact has a single responsibility to perform. They can version independently and adding API increase the version number.
Contracts are used to model across verticals. You select which contracts you use. This means that a vertical must support a contract either wholesale or not at all. In other words, they can’t subset the contents of a contract.
For architects and developers, you will approach your thinking about the API differences between verticals at the assembly level, as opposed to the individual API level. And it means that Microsoft provide a class library experience that can target multiple verticals, also known as portable class libraries.
Portable Class Libraries
One source code, one binary, multiple platforms. That’s the promise of portable class libraries. You can now consume & produce WinRT APIs.
- You can now create & design portable XAML user controls
- You can now easily convert a platform-specific class library into a portable class library by adding another platform:
Portable class libraries present the developer with the intersection of APIs that can be shared across all the selected targets. This allows producing a single binary that is guaranteed to run on all of the targets. Producing a single binary gives you the following benefits:
- You can easily redistribute the component to 3rd parties, outside your solution. This includes sharing the binary directly as well as sharing it via a package manager like NuGet. Either way, consumers just add a reference to it and are good to go. Thanks to the “C” in “CLR” it also doesn’t matter which programming language the library was written in.
- It’s the same component, on all platforms. This makes it super easy to reason about your components. It also streamlines testing quite a bit.
Good examples of libraries that take advantage of portable class libraries are JSON.NET and immutable collections.
.NET Core
.NET Core is a modular development stack that is the foundation of all future .NET platforms It’s already used by ASP.NET 5 and .NET Native.
.NET Core is essentially a fork of the NET Framework whose implementation is also optimized around factoring concerns. Even though the scenarios of .NET Native (touch based devices) and ASP.NET 5 (server side web development) are quite different, we were able to provide a unified Base Class Library (BCL).
This unified BCL is one of the newest pieces of .NET that Microsoft is making open source.
You can think of the .NET Core BCL is the same for both .NET Native and ASP.NET 5. The bottom contain the .NET runtime: one for CoreCLR and one used by ASP.NET 5. Most of BCL are pure MSIL assemblies, such as collections. They share the same implementations.
On top of BCL, there are app-model specific API, such as APIs specific to Windows client. ASP.NET adds APIs such as MVC that are for server-side development.
You can think of .NET Core as not specific to .NET Native or ASP.NET 5. The BCL and runtimes are general purpose and modular.
Get .NET Core from NuGet
The .NET Core platform will be delivered as a set of NuGet packages. .NET Core isn’t a single NuGet package. Instead it’s a set of packages. For the BCL layer, we’ll have a 1-to-1 relationship between assemblies and NuGet packages.
the NuGet package will have the same name as the assembly. For example, immutable collections will no longer be delivered in a NuGet package called Microsoft.Bcl.Immutable but instead be in a package called System.Collections.Immutable.
In addition, we’ve decided to use semantic versioning for our assembly versioning. The version number of the NuGet package will align with the assembly version.
NuGet allows us to deliver .NET Core in an agile fashion. So if we provide an upgrade to any of the NuGet packages, you can simply upgrade the corresponding NuGet reference.
The NuGet based delivery also turns the .NET Core platform into an app-local framework. The modular design of .NET Core ensures that each application only needs to deploy what it needs.
Although .NET Core is delivered as a set of NuGet packages it doesn’t mean that you have to download packages each time you need to create a project. Microsoft is committed to provide an offline installer for distributions and also include them with Visual Studio so that creating new projects will be as fast as today and not require internet connectivity in the development process.
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.
Open Source Libraries
The new .NET Core on source is hosted GitHub. A month ago, we already made samples available on GitHub.
Code changes are made immediately live. Also:
- Code reviews. We also want to have all code reviews the team is doing to be in the public as well, via GitHub’s pull request model.
- Design documents & discussions. We’ll also share design notes, specs, and implementation specific documentation. We’ll need to figure out exactly what format we’ll be using. At a minimum you can expect Markdown based documents, similar to Mad’s C# design notes. Another idea we had was recording our design meetings and share them on Channel 9. We need to figure out how we can do this on a somewhat regular cadence.
Building and running your own forks
In order to play with our bits or experiment with your own modifications you need to be able to build and run your own version of the libraries. We want to make this as easy as pie, so here it is:
- You clone our repo (
git clone https://github.com/dotnet/corefx) - You invoke
build.cmd
The build only requires Visual Studio 2013 (i.e. it doesn’t require “Dev14”). It will build all the libraries and run the unit tests.
One of the challenges we had in the past was around strong naming which prevented you from simply dropping a binary into an existing project. We’ve addressed this concern by providing a new way to strong name binaries, which we call open source signing. You can find more information in our developer’s guide.
.NET Foundation
The .NET Core project is under the stewardship of the .NET Foundation. Microsoft is working closely working with Miguel de Icaza from Xamarin/Mono in order to create a shared code base that can become a cross-platform implementation of .NET Core.
Today, only a subset of the libraries are available on GitHub:
Microsoft has committed to provide more of .NET through GitHub:
- More libraries. Consider the subset we have today a down-payment on what is to come. Our goal is to open source the entire .NET Core library stack by Build 2015.
- Building and running on non-Windows platforms. We currently only provide the ability to build and run on Windows. We intend to build a public working group between us and the Mono community once we have enough code out there.
Your Migration Path
The teams at Microsoft believe they found a good balance between laying the foundation for the future while maintaining great interoperability with the existing stacks:
- .NET Framework 4.6.
The .NET Framework is still the platform of choice for building rich desktop applications and .NET Core doesn’t change that.
For Visual Studio 2015 our goal is to make sure that .NET Core is a pure subset of the .NET Framework. In other words, there wouldn’t be any feature gaps. After Visual Studio 2015 is released our expectation is that .NET Core will version faster than the .NET Framework. This means that there will be points in time where a feature will only be available on the .NET Core based platforms.
- Mono.
With .NET Core we’re able to develop an entire .NET stack as a full open source project. Thus, having to maintain separate forks will no longer be necessary: together with the Mono community we’ll make .NET Core great for Windows, Linux and MacOSX. This also enables the Mono community to innovate on top of the leaner .NET Core stack as well as taking it to environments that Microsoft isn’t interested in.
- Windows Store & Windows Phone
Both the Windows Store 8.1 and Windows Phone 8.1 platforms are much smaller subsets of the .NET Framework. However, they are also a subset of .NET Core. This allows us to use .NET Core as the underlying implementation for both of these platforms moving forward. So if you’re developing for those platforms you are able to directly consume all innovations without having to wait for an updated framework.
Sharing Code between .NET Core and .NET platforms
Since .NET Core forms the foundation for all future .NET platforms code sharing with .NET Core based platforms has become friction free.
This raises the question how code sharing works with platforms that aren’t based on .NET Core, such as the .NET Framework. The answer is: it’s the same as today, you can continue to use portable class libraries and shared projects:
- Portable class libraries are great when your common code is platform-independent as well as for reusable libraries where the platform-specific code can be factored out.
- Shared projects are great when your common code has a few bits of platform-specific code, since you can adapt it with
#if.
For more details on how choose between the two, take a look at Sharing code across platforms.