.NET Main Workloads

The full .NET Framework and .NET Core live independently from one another, but ever since the beginning, they have been the building blocks of one or many workloads that sit on top of one of these technologies. Two of the major workloads are ASP.NET Core 1.0 and Universal Windows Platform apps. Let’s briefly dive into the details of each one of them.

Universal Windows Platform apps

The year 2015 will be remembered by the Microsoft developer as the year of innovation. In fact, in 2015, Microsoft came out on the market with its new operating system, Windows 10. Windows 10 represents the first operating system that was able to unify, through a common platform, the ideologically distinct worlds of desktop, tablet, and mobile apps, as well as apps for IoT and holographic devices. None of this could’ve been possible without the incredible investment in the idea of the ecosystem that Microsoft has kept, and is still doing in these recent years. The Universal Windows Platform could be seen not only as a set of APIs, but also as a journey that started with Windows Phone 7 and continued with Windows 8.1 and Windows Phone 8.1 until now.

The Universal Windows Platform relates to .NET Core, since it uses it as its runtime, with .NET Native as its default toolchain.

The Universal Windows Platform is a set of APIs that is common and consistent across every device in the Windows family. This unique set of APIs is what allows developers to compile a single binary of their app (given the proper distinction based on the processor’s architecture) to run on every Windows 10 device. The UWP is the result of the expansion and componentization of the already existing Windows Runtime, inherited from Windows 8. A set of APIs, or more generally, a logic subset of APIs dedicated to a specific task, is called a contract.

Splitting the UWP in a series of contracts represents a big step forward in the way we developers approach to the platform. In fact, a contract represents a warranty on how the operating system exposes that particular functionality. This mechanism is also a powerful way for Microsoft to distribute incremental updates to the platform without breaking the support for a previous version of the runtime. Leveraging this mechanism, Microsoft can also distribute updates and patches to its operating system at a faster pace. What’s important to remember here is that we build apps against the Universal Windows Platform, not Windows 10 itself. The Universal Platform is independent from Windows. This, in my opinion, is the true essence of this “Windows as a service” story.

ASP.NET Core 1.0

ASP.NET Core 1.0 is a single framework that runs on top of either .NET Core 1.0 or on the full .NET Framework. ASP.NET Core is the first workload that has adopted .NET Core. A key value of ASP.NET Core is that you can run different applications on the same machine that target different versions of the runtime, having the two apps completely isolated from one another. Since ASP.NET Core is modular, you get the benefit of a smaller memory footprint of your app, as well as some important performance benefits that can be perceived even if you are targeting the full .NET Framework.

Here is a high-level vision of how you can run an ASP:NET Core app:

Figure 18: ASP.NET Core 1.0 high-level stack

When you run your ASP.NET Core application on top of the .NET Core 1.0 framework, you get an end-to-end stack optimized for server-cloud workloads, which means a high throughput and a very small footprint in memory. You also get side-by-side execution of the .NET Core framework version related to your application, no matter what other versions of .NET might be installed in the same server or machine. And since .NET Core is cross-platform, these benefits apply even on Mac and Linux. On the other hand, when you run your ASP.NET Core application on top of the full .NET Framework, you’ll get the highest level of compatibility with existing .NET libraries and less restrictions than you get when running on top of .NET Core.