(UPDATE – Nov.2016) – Note that .NET 5 and ASP.NET Core 5 were temporal brandings while .NET Core was in beta. Its final branding was .NET Core 1.0 and ASP.NET Core 1.0 when released in June 2016, due to the big shift or “reset/modernization” in .NET Core compared to .NET 4.x.
—
Last week, on Nov. 12th at the Visual Studio Connect(); event, it was an epic day where we showed our end to end vision about .NET 2015 and VS 2015. You can watch the recorded event here.
For this post, I wanted to show my specific point of view about two areas within .NET 2015:
.NET Core 5
ASP.NET 5
Positioning .NET 2015
First of all, .NET 2015 is like a snapshot in the time of the different components and frameworks within .NET. When .NET was born and during quite a few years, the .NET Framework was a single big framework targeting all scenarios. But, nowadays, .NET is composed by different components, frameworks and even runtimes but at the same time those frameworks share many thing in common, like languages (C#, VB.NET and F#), compilers and the new .NET Compiler Platform (“Roslyn”), JITs, etc. For instance, you have a different API/Framework when developing a Windows Store application compared to when you develop a desktop application in WPF or a web application with ASP.NET frameworks (MVC, Web Forms, Web API, SignalR).
But, if there’s something I want to highlight in this post is the huge innovation we’re going to release in .NET for this new major release and because of that, as developers, we need something to tell me, “hey!, this snapshot/picture shows all the technologies/components released from Microsoft in 2015”. That is basically .NET 2015. At the end of the day, .NET 2015 is a set of .NET releases. The year denotes a single umbrella release that provides a cohesive experience and unifies the family of .NET technologies. It also helps us talk about all the releases that come out at the same time and work well together.
The following diagram that I created is the vision that we started with its ALPHA version in last May 2014 at TechEd NA 2014, but now updated to the specific .NET versions rather than .NET vNext:
You can see in there how depending on the application type you’d want to create (Client apps or Web applications and Services) you now have two choices:
– You can use the full .NET Framework that’s evolving and now is branded as .NET Framework 4.6
– You can use the smaller and scenario-specialized new framework called .NET Core 5.
A different point of view, more “framework-based” of the same technologies is this other diagram that I created after discussions with different product groups when we were defining the different names and versions for .NET 2015, where you can easily identify the frameworks.
You can also notice in that diagram how .NET Core will also be targeting cross-platform scenarios (Mac and Linux) thru ASP.NET 5.
In this post I am not going to focus on .NET 4.6 Framework because it is pretty much what most .NET developers are already familiar with (it is the next version after .NET Framework 4.5.2), but I want to focus on the new .NET Core 5 and ASP.NET 5 within it, most of all.
.NET Core 5
.NET Core 5 is a major new investment in the future of .NET and laying the foundation for decades to come. Still, it is in its early stage, and for some time you might still focus .NET Framework 4.6 depending on your application needs. But for many scenarios, specially in cloud/server scenarios, it will be the ideal framework, since .NET Core 5 and ASP.NET 5 have being designed from the ground-up as an optimized stack for server and cloud workloads.
.NET Core 5 is a completely open source stack and can run on multiple operating systems. In addition, not only are we contributing .NET Core 5 to the .NET Foundation but we will openly collaborate with the community and ensure that we continue our strong relationship with existing .NET open source communities, in particular the Mono community. Here are a set of announcement around open source and cross platform from Connect(); event:
- .NET Core 5 is open source on GitHub
- Microsoft will support .NET Core 5 on Windows, Linux and Mac.
- Microsoft has contributed .NET Core 5 to the .NET Foundation
- Renewed collaboration with the Mono Project
.NET Core is a modular implementation that can be used in a wide variety of verticals, scaling from the data center to touch based devices, is available as open source, and is supported by Microsoft on Windows, Linux and Mac OSX.
.NET Core is optimized around factoring concerns. Even though the scenarios of .NET Native (initially touch based devices) and ASP.NET 5 (server side web development) are quite different, Microsoft has been able to provide a unified Base Class Library (BCL).
So, this is a diagram summarizing .NET Core:
The API surface area for the .NET Core BCL is identical for both .NET Native as well ASP.NET 5. At the bottom of the BCL we have a very thin layer that is specific to the .NET runtime. We’ve 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. The majority of the BCL are pure MSIL assemblies that can be shared as-is.
On top of the BCL, there are app-model specific APIs. For instance, the .NET Native side provides APIs that are specific to Windows client development, such as WinRT interop. ASP.NET 5 adds APIs such as MVC that are specific to server- side web development.
.NET Core is not specific to either .NET Native nor ASP.NET 5 – the BCL and the runtimes are general purpose and designed to be modular. As such, it forms the foundation for all future .NET verticals, even additional to ASP.NET or Windows Store.
NuGet is mainstream in .NET Core
In contrast to the .NET Framework, the .NET Core platform is delivered as a set of NuGet packages thru NuGet.org.
In order to continue our effort of being modular and well factored we don’t just provide the entire .NET Core platform as a single NuGet package. Instead, it’s a set of fine grained NuGet packages. For the BCL layer, we’ll have a 1-to-1 relationship between assemblies and NuGet packages.
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. We’re also working on enabling smart sharing if multiple applications use the same framework bits. However, the goal is to ensure that each application is logically having its own framework so that upgrading doesn’t interfere with other applications running on the same machine.
.NET Core with NuGet deployment is Enterprise ready
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 will 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.
ASP.NET 5
ASP.NET 5 is now a single framework that runs on top of either .NET Core 5 runtime (Core-CLR) or the .NET Framework runtime (CLR).
ASP.NET 5 is the first workload that has adopted .NET Core. ASP.NET 5 runs on both the .NET Framework and .NET Core. A key value of ASP.NET 5 is that it can run on multiple versions of .NET Core 5 on the same machine. Website A and website B can run on two different versions of .NET Core on the same machine, or they can use the same version. It’s up to you. Due to its smaller footprint, there are also some performance benefits that are specific to .NET Core, however, most of the ASP.NET 5 performance benefits apply to both the .NET Framework and .NET Core.
The following image is a high level vision of how you can run your ASP.NET 5 application:
You can select the runtime you want to target in your ASP.NET 5 app right from Visual Studio 2015 Preview, in your ASP.NET project properties, like the following screenshot:
In this diagram you can see the full stack and how it is different depending on your choice. Basically, the CLR will be different, the available libraries will be different and even the low level integration into IIS or self-hosted options are also different. All in all, the .NET Core 5 stack will be much lighter, a with a much smaller memory footprint.
When you run your ASP.NET 5 application on top of the Core-CLR and therefore .NET Core 5 framework, you’ll get an end-to-end stack optimized for server/cloud workloads which means a high throughput, very small footprint in memory and one of the most important things, side-by-side execution of the .NET Core 5 framework version (KRE or K runtime environment) related to your application, no matter what other versions of .NET might be installed in the same server or machine. Additionally, and like mentioned, you could run that web application on a web service running on Mac or Linux.
On the other hand, when you run your ASP.NET 5 application on top of the regular CLR and therefore .NET Framework 4.6 you’ll get the highest level of compatibility with existing .NET libraries and less restrictions than what you get when running on top of .NET Core 5. As of today, November 2014, .NET Core 5 is still in an early stage (RTM will be released in 2015 H1 calendar year) so you might find unsupported scenarios or APIs when trying to run your web app on the Core-CLR (i.e. Entity Framework 7 is still a beta version, etc.), but still, it is possible, like we did with our MyShuttle.org web applications and services that we showcased at the Connect(); event on Nov. 12th 2014.
My personal advice? if you’re going to migrate an application, bet for ASP.NET 5 running on the regular CLR. But if you are going to start a proof of concept or even a new application from scratch, I’d go for ASP.NET 5 on Core-CLR, so all the constraints will be discovered and solved at the beginning of the project and it will be easier while growing the application. The sooner you move to Core-CLR and compile against the Core-CLR, the better. If you wait too long, you’ll get many compilation errors due to unsupported libraries or API for .NET Core 5. You could compare this to FxCop and code analysis warnings, the sooner you apply it, the better.. 😉
Benefits in ASP.NET 5
These are the main benefits of ASP.NET 5, no matter what framework/CLR you choose underneath:
• Unified ASP.NET 5 framework targeting MVC, Web API and SignalR, all of them in a single framework
• Seamless and “by default” integration with Microsoft Azure and Windows Server through simplified configuration. There won’t be different configuration for each environment, that’s why it is “Cloud-First driven”. We now have the config.json file where you create your settings and it is based, underneath, on environment variables. You’d put the database connection strings in that config.json, etc.
• Rich ecosystem of composable NuGet packages.
• End to end decoupled stack (ASP.NET and .NET) based on Dependency Injection provided out-of-the-box, so the same ASP.NET application could be running on different CLRs and even different platforms/OS.
Dependency Injection and IoC Containers in ASP.NET 5
• Built-in DI for configuring services/libraries
• Environment specific services can be configured through dependency injection
• You can still wire up your favorite IoC container
• Admins can locally patch an application without requiring the application to recompile, and with negligible downtime to the application.
• Applications are not locked into a patched version – newer versions of patched components can still be used
• Since Dependency Injection is applied end-to-end thru the .NET stack, that enables cross-platform to ASP.NET 5, like mentioned (Windows, Mac, Linux).
These are the main principles used to shaped the new runtime:
- The runtime should be as self-contained as possible. Until the runtime has walked the application dependency tree of your application it cannot know which of the Core CLR packages you want to use, so it cannot load any of them before that. Except for Roslyn, since the dependency resolver that uses Roslyn doesn’t actually load Roslyn until after the dependencies have been walked.
- Dependency Injection through the entire stack. DI is a core part of the Runtime, and all libraries we build on top of it.
How is ASP.NET 5 optimized for server workloads when based on .NET Core?
We’re adding a cloud-optimized (public cloud, private cloud, any cloud, or you can also say server-scale specialized) version optimized for server scenarios like low-memory and high-throughput.
These are the main benefits of ASP.NET 5 when running on top of .NET Core 5:
• Slim .NET stack optimized for cloud and server workloads based on:
– Small Core-CLR that only contains fundamental building blocks
– Support of true side by side execution of the framework (even self-contained per application), that allows breaking changes scenarios
– Enables best-of-breed performance and scalability with a high resource-efficient optimization
• Seamless and “by default” integration with Microsoft Azure and Windows Server through simplified configuration. There won’t be different configuration for each environment, that’s why it is “Cloud-First driven”. We now have the config.json file where you create your settings and it is based, underneath, on environment variables. You’d put the database connection strings in that config.json, etc.
• NuGet packages are the “unit of measure”. Libraries and even the Core-CLR and frameworks are now “all included” as NuGet packages! 🙂
If you take a look to C:\Users\[your user]\.kre\packages\KRE-CoreCLR-amd64.1.0.0-beta1 for instance, you have the .NET Core 5 framework in there just as a single NuGet package! A single 15MB file for the whole .NET Core 5 framework and runtime!:
You can explorer the KRE-CoreCLR framework NuGet package by using the NuGet package explorer, and see the mscorlib.dll or the different “k” libraries:
In the next diagram you can analyze the whole stack when running an ASP.NET 5 on the .NET Core 5 framework and Core CLR:
Currently, we’re using “Helios” as the plug between the ASP.NET application and IIS, but in the future we’ll also provide an ISS Native Module compatible with this new stack.
How will I be able to adopt ASP.NET 5 in my new applications even when my servers are running older versions of .NET Framework?
The goodness of ASP.NET 5 when running on .NET Core 5 is that you’ll be able to have business applications with certain sub-systems running on the established ASP.NET and System.Web and other newer sub-systems running on the new ASP.NET 5, all within the same server and IIS infrastructure or self-hosted in your own process.
Therefore, when running ASP.NET 5 on top of .NE Core 5, it will let you deploy your related version of .NET Core 5 on an app-by-app-basis. One app with new libraries can’t break an app “next door” with a different version. Different apps can even have their specific and different Core CLR version.
This is why it is a true side by side execution, when using ASP.NET 5, different applications can use different versions of the framework without affecting each other and each application runs against the framework it references and is deployed with (self-contained, like XCOPY). By using the side by side execution of ASP.NET 5, you decide when you adopt .NET updates on an app basis (as opposed to machine basis).
Cross-Platform development (Windows, Mac and Linux) with ASP.NET 5
Any organization who is building products running on the server will be able to develop ASP.NET 5 web apps or services using different operating systems (Windows, Linux or MAC OS X based on “Mono Project”).
The following is a simplified diagram of how ASP.NET 5 is cross-platform enabled thanks to its end-to-end use of dependency injection across the stack:
You can see below how I’m running an ASP.NET 5 MVC application on a Mac with ASP.NET 5 and Mono:
This is today (running ASP.NET 5 on top of Mono), but Microsoft is also going to release an official distribution of the .NET Core for Linux, as well as an official distribution of .NET Core for the Mac OS X, as well. This will enable you to build .NET server and cloud applications and run them on both Windows Server and Linux. It is going to enable every developer – regardless of what operating system they use to develop or target – to use .NET. And to do so on a fully open source runtime.
Another way to look at it: Traditionally, the .NET Framework had essentially two “forks”. One fork is provided by Microsoft and is Windows only. The other fork is Mono which you can use on Linux and Mac.
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 Microsoft will make .NET Core great for Windows, Linux and Mac OSX. 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.
Therefore, ASP.NET 5 is decoupled from the underneath platform thanks to its end-to end use of Dependency Injection across the whole stack, as I mentioned previously in this post.
Basically these are the important points about ASP.NET 5 and cross-platform:
- ASP.NET 5 will be available for Windows, Mac, and Linux. Mac and Linux support will come soon and it’s all going to happen in the open on GitHub at https://github.com/aspnet
- ASP.NET 5 will include a web server for Mac and Linux called Kestrel built on libuv. It’s similar to the one that comes with node, and you could front it with Nginx for production, for example.
Open Source
At the end of the day, you’ll be able to opt in or out of the cloud optimized framework for compatibility, or the libs you want to use, or even the tools!.
ASP.NET is modular and all about choice. your choice of operating system, your choice of framework, your choice of tools/Editor.
We are building .NET Core CLR for Windows, Mac and Linux and it will be both open source and it will be supported by Microsoft. It’ll all happen at https://github.com/dotnet
It is all about openness.
Check these posts if you want to know more about .NET and Open Source:
http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.aspx
http://blogs.msdn.com/b/dotnet/archive/2014/11/12/announcing-net-2015-preview-a-new-era-for-net.aspx
I want to end this post by saying that the deep and broad range of investments in .NET we are making bring one of the most exciting moments in time for the .NET ecosystem, as a development platform.
GOOD TIMES FOR .NET! 🙂
Related links:
0 comments