I’m writing this blog post about “.NET end-to-end” now that we just released the .NET Core Platform 1.0 RTM, so it’s clear “who is who” and “when to use what”. It’s a long post but I think it’s good to have available a single post about .NET end-to-end.
.NET is nowadays a development-platform running across many OS-platforms such as Windows, Linux, Mac and even iOS and Android through Xamarin which is also .NET.
In this blog post I’ll explain from a high level point of view WHAT are each of the frameworks in the .NET ecosystem, and what is probably more important for customers, WHEN to use each of the frameworks.
TOC links in this blog post
Because this is a very long post, I think a TOC with links is a good thing to have, so you can navigate directly to any topic/subject:
- What is .NET as a whole
- The .NET family of frameworks
- What is the .NET Framework? – The traditional .NET framework, maturity
- What is the Xamarin Platform? – .NET cross-platform mobile
- What is .NET Core? – Cross-platform, modular, modern, OSS
– ASP.NET Core – Part of .NET Core, but also runs on the .NET Framework CLR
– Universal Windows Platform and .NET Native
- Why .NET Core? – Innovation and foundation for the future
- Common pillars and skills shared across the .NET frameworks
– Building cross-platform libs – The .NET Standard Library & the .NET Platform Standard
- Stats: .NET Core vs. .NET Framework 4.x and other frameworks
- Business benefits from .NET Core
- When should I use .NET Core?
- When should I not use .NET Core?
- When should I still use .NET Framework 4.x?
- When should I not use .NET Framework 4.x?
- When should I use Xamarin?
- When should I not use Xamarin?
What is .NET as a whole
.NET is a general purpose development platform. It can be used for any kind of app type or workload where general purpose solutions are used. It has several key features that are attractive to many developers, as it combines high performance and richness with a unique, differentiated developer productivity.
Open source is also an important part of the .NET ecosystem, with multiple .NET implementations and many libraries available under OSI-approved licenses.
The .NET family of frameworks
As shown in the figure below, multiple implementations of .NET are available depending on the OS platform (Windows, Linux, MacOS, iOS, Android and Windows 10 UWP) and workload type (server/desktop/mobile), all of them based on open .NET Standards that specify the fundamentals of the platform.
Taking into account the internal frameworks, class libraries and common infrastructure, the following diagram is the current overall picture as of June 2016 (not taking into account the .NET Standard Library not shown below, which is explained later on in this post when covering the cross-platform libraries development.
(*) Note that ASP.NET Core is also supported when running on top of the traditional .NET Framework but you’d lose .NET Core Platform’s benefits (cross-platform, modular/lightweight, etc.) that I’ll explain further in this post.
Practically, .NET is a set of frameworks sharing common pillars but also with differences between frameworks.
This is the .NET Framework that people most know about today. The .NET Framework is Microsoft’s primary develop platform for Windows server and client developers. It is a very powerful and mature framework, with a huge class library (known as the .NET Framework Class Library) that supports a wide variety of applications and solutions on Windows.
The .NET Framework provides the highest level of compatibility for your existing applications and libraries.
It ships as part of the Windows operating system and thus is serviced through Windows Update when new versions become available or through optional standalone installers. However, it can also be installed with a standalone setup downloaded from here or with Visual Studio.
When shipping with Windows, Windows 8 ships with 4.5, Windows 8.1 ships with 4.5.1 and Windows 10 ships with 4.6. For servers, Windows Server 2012 ships with 4.5 and Windows Server 2012 R2 ships with 4.5.1.
From a historical point of view, since it was released in 2002, the .NET Framework has received broad support from developers who like its consistent programming model, easy to get started environment with Visual Studio, debugging and profiler tools plus direct support from Microsoft. It also makes application deployment and maintenance straightforward. Based on those reasons, .NET became very popular across the board.
There are multiple application stacks built on top of the .NET Framework that allow developers to build applications ranging from console applications, across rich client (WPF) applications to scalable web applications. This is a list of the traditional sub-frameworks coming as part of the .NET Framework, that I’m not going to explain as they are pretty much known in the community: Windows Forms, Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), ASP.NET up to v4.x, ASP.NET Web Forms, ASP.NET MVC, ASP.NET WebAPI, SignalR and a few other sub-frameworks.
While the code for the .NET Framework is available for reference it is not an active open source project.
The .NET Framework will continue to evolve mainly by shipping new updates when the next version of the Windows operating system ships and it remains the way to build applications targeting multiple versions of the Windows desktop from Windows 7 through Windows 10 and beyond.
What is the Xamarin Platform? – .NET cross-platform mobile
With the Xamarin Platform you can deliver native Android, iOS, MacOS and Windows apps, using existing .NET skills, teams, and code.
The Xamarin Platform is based on Mono. Mono is the original open source and cross-platform implementation of .NET, from the community Mono Project. It is now sponsored by Xamarin/Microsoft. Traditionally, Mono’s APIs have followed the progress of the .NET Framework, not .NET Core.
In addition to cross-platform mobile, apps created with Xamarin are native providing similar performance than the apps created with Objective-C/Swift/ for iOS or Java for Android.
Xamarin provides the following summarized features:
Native User Interfaces – Xamarin apps are built with standard, native user interface controls. Apps not only look the way the end user expects; they behave that way too.
Native API Access – Xamarin apps have access to the full spectrum of functionality exposed by the underlying platform and device, including platform-specific capabilities like iBeacons and Android Fragments.
Native Performance – Xamarin apps leverage platform-specific hardware acceleration, and are compiled for native performance. This can’t be achieved with solutions that interpret code at runtime.
Productivity – With Xamarin.Forms developers can use the same logic and UI targeting iOS, Android and Windows 10 UWP.
In the Xamarin’s diagram you can see how you can share client code (usually C# app logic like ViewModels, Models, Service Agents, etc.) across the platforms between Xamarin.iOS, Xamarin.Android and even Windows 10 UWP projects.
If using Xamarin.Forms you can also share the same UI Code (Xamarin XAML defining the pages/views) between the platforms.
Note: With Xamarin, you can also develop apps for Mac (MacOS), but that is not represented in the figure because the main purpose of Xamarin is “Cross-Platform Mobile”.
What is .NET Core? – Cross-platform, modular, modern, OSS
.NET Core is a new version of .NET which is a cross-platform, open source and modular .NET platform for creating modern web apps, microservices, libraries and console applications that run everywhere (Windows, Linux and MacOS).
Unlike the traditional .NET Framework, which is a single package installation, system-wide, and Windows-only runtime environment, .NET Core is about decoupling .NET from Windows, allowing it to run in non-Windows environments without having to install a giant 400mb set of binaries (versus just the footprint of the components you need from .NET Core) plus the ability to deploy the applications coming with the framework itself supporting side-by-side execution of different versions of the framework.
Basically, the .NET Core Platform is packaged and installed in a different way. Instead of being part of the operating system .NET Core is composed of NuGet packages and is either compiled directly into an application or put into a folder inside the application. This means applications can carry .NET Core with and thus are completely side by side on the machine.
.NET Core consists of a common language runtime, which in .NET Core is named CoreCLR. .NET Core also features an extensive class library. Rather than a single .NET Framework Class Library, however, .NET Core features CoreFX, a modular collection of libraries. This allows you to include just the libraries that your app needs without the overhead of including those that you don’t need.
Below you can see the application models currently supported by .NET Core.
The following topics are the main value-propositions of .NET Core:
Cross-platform – .NET Core currently supports three main operating systems: Linux, Windows and OS X. There are other OS ports in progress such as FreeBSD and Alpine. .NET Core libraries can run unmodified across supported OSes. The apps must be re-compiled per environment, given that apps use a native host. Users select the .NET Core supported environment that works best for their situation.
Open Source – .NET Core is available on GitHub, licensed with the MIT and Apache 2 licenses (licensing is per component). It also makes use of a significant set of open source industry dependencies (see release notes). Being OSS is critical for having a thriving community plus “a must” for many organizations where OSS is part of their development strategy.
Natural acquisition – .NET Core is distributed as a set of NuGet packages that developers can pick and choose from. The runtime and base framework can be acquired from NuGet and OS-specific package managers, such as APT, Homebrew and Yum. Docker images are available on docker hub. The higher-level framework libraries and the larger .NET library ecosystem are available on NuGet.
Modular framework – .NET Core is built with a modular design, enabling applications to include only the .NET Core libraries and dependencies that are needed. Each application makes its own .NET Core versioning choices, avoiding conflicts with shared components. This approach aligns with the trend of developing software using container technologies like Docker.
Smaller deployment footprint: Even when in v1.0 the size of .NET Core is a lot smaller than .NET Framework, note that the overall size of .NET Core doesn’t intend to be smaller than the .NET Framework over time, but since it is pay-for-play, most applications that utilize only parts of CoreFX will have a smaller deployment footprint.
Fast release cycles of .NET Core – .NET Core modular architecture plus its OSS nature provide a modern and much faster release cycles (even per NuGet package) compared to slow release cycles from larger monolithic frameworks. This approach allows a much faster innovation pace from Microsoft and the OSS .NET community than what was traditionally possible with the .NET Framework.
As mentioned, there are multiple application model stacks built on top of the .NET Core that allow developers to build applications ranging from console applications, across UWP Windows 10 apps (PC, tablet and phones) to scalable web applications and microservices with ASP.NET Core.
ASP.NET Core – Part of .NET Core, but also runs on the .NET Framework CLR
ASP.NET Core is new high performance and modular version of ASP.NET for Web developers for building high-performance web apps or microservices that are deployed to the cloud or run on-premises. It also has unified ASP.NET MVC and ASP.NET Web API into a single framework and following the same philosophy than .NET Core, it is open-source and was architected to provide an optimized modular framework.
ASP.NET Core apps can run on .NET Core or on the full .NET Framework. But only if running on top of .NET Core, the ASP.NET applications will be cross-platform (Mac and Linux in addition to Windows).
In the following diagram you can see ASP.NET from a different perspective, highlighting how your ASP.NET apps can run on top of .NET Core or the traditional .NET Framework.
However, ASP.NET Core should be considered part of .NET Core because it is part of the same new end-to-end architecture stack and the same stream of innovation. In fact, you install ASP.NET Core as part of .NET Core installation.
In addition to the .NET Core benefits mentioned before that only apply if you run ASP.NET Core on top of .NET Core, with ASP.NET Core you gain the following foundational improvements, in any case:
· A unified story for building web UI and web APIs (MVC and Web API are unified)
· Integration of modern client-side frameworks (JS, TypeScript, Angular.js, etc.) and development workflows
· A cloud-ready environment-based configuration system
· Built-in dependency injection
· New light-weight and modular HTTP request pipeline
· Ability to host on IIS or self-host in your own process
ASP.NET Core running on the traditional .NET Framework: As mentioned, it is important to highlight that if you run ASP.NET Core on top of the traditional .NET Framework, then you would gain access to many existing/legacy .NET Framework libraries (from the framework itself or from any third party) that don’t work for .NET Core, but on the other hand you would lose the mentioned .NET Core benefits (cross-platform and lightweight/modular framework) until you remove those dependencies to the .NET Framework and libraries in your application, in the future.
ASP.NET Core v1 is not meant as a replacement of ASP.NET in the .NET Framework. It is a version 1 product that allows ASP.NET customers have cross-platform applications with best in class performance and a smaller footprint because of the modular/streamline framework.
Universal Windows Platform and .NET Native
Windows 10 introduces the Universal Windows Platform (UWP), which further evolves the Windows Runtime model and brings it into the Windows 10 unified core. As part of the core, the UWP provides a common app platform available on every device that runs Windows 10 (Desktop, Tablet, Phone, Surface Hub, XBOX ONE, IoT device, and Hololens). The UWP provides a guaranteed core API layer across devices. This means you can create a single app package that can be installed onto a wide range of devices. And, with that single app package, the Windows Store provides a unified distribution channel to reach all the device types your app can run on.
Usually, apps that can run on Windows 10 on a desktop, tablet devices, and phones share more capabilities because of a more similar form-factor and APIs, but packages can also be shared across Surface Hub, XBOX ONE, IoT devices and Hololens.
UWP apps are compiled to native code for their target platforms through .NET Native. For more information, see Guide to Universal Windows Platform Apps (UWP).
.NET Native is an Ahead-of-Time (AOT) toolchain that compiles IL byte code to native machine code, so that when the code is executed, there is only “native” code running in the device. This means that the resulting binary is what the OS executes; there is no JIT-ing, no runtime compilation. This leads to better performance, as well as some security benefits.
Why .NET Core? – Innovation and foundation for the future
The .NET Framework was released in 2002, almost 15 years ago. Since then, millions of developers have used it to build and run great web and native apps, and over the years we have added and evolved many capabilities to it, evolving the same framework from .NET Framework 1.0 until .NET Framework 4.6. During this long evolution .NET has been providing a good compatibility with legacy versions.
However, the IT industry is undergoing constant change and competition so eventually, every product has to have a major innovation shift breaking with the past in order to fully modernize the technology and compete effectively in the longer term.
On one hand, the traditional .NET Framework 4.x is a very mature and rich framework, great for enterprise application development, but has several limitations which most of them cannot be changed without breaking with the past:
– Windows only support
– Large and monolithic framework that has to be installed in full, per machine.
– Slower release cycle due to its large surface with a monolithic nature.
– Large memory and drive footprint, limiting hardware/resources usage efficiency. Scalability could cost less with a modular framework with a pay-for-play approach like in .NET Core where most applications that utilize only parts of CoreFX will have a smaller deployment footprint.
– No side-by-side at application level, causing high friction and impact in production servers when new versions of the framework are released.
On the other hand, with .NET Core and thanks to a number of deep architectural changes that result in a much leaner and modular framework, you get a much better resource’s usage efficiency. Another fundamental goal in .NET Core is to have “.NET everywhere” by providing cross-platform support (Windows, Linux and MacOS). For further details, read the section about “What is .NET Core”.
In summary, the .NET Core Platform is that foundation for the future of .NET. In a single word, .NET Core means “innovation” and flexibility to adapt to many OS platforms and modern workloads, that is why Microsoft has created .NET Core.
Common pillars and skills shared across the .NET frameworks
Both .NET Framework and .NET Core are .NET and thus share they share many components. The Roslyn compiler which provides C# and VB.NET, the Just In Time which converts .NET IL code into native 32 bit or 64 bit instructions with support for SIMD, the garbage collector which frees up unused memory and the base class library frameworks. Whether you are building a .NET Framework or .NET Core applications they both use these same common components so you get the best of .NET. And you can easily build libraries which can be shared across both the .NET Framework and .NET Core.
Xamarin is also increasingly sharing more and more components from the .NET ecosystem. For instance, Xamarin uses C# and F# languages, the .NET Compiler Framework (Roslyn), many .NET features like LINQ, Generics, Lambdas and all the power and productivity coming from Visual Studio.
Here’s a bit more detailed explanation of some common pillars in .NET shared across the several .NET Frameworks.
Languages – As a developer, you can choose any programming language that supports .NET to create your application. Because .NET provides language independence and interoperability, you can interact with other .NET applications and components regardless of the language with which they were developed.+
Languages that allow you to develop applications for the .NET Platform adhere to the Common Language Infrastructure (CLI) specification.+
Microsoft languages that .NET supports include C#, F#, and Visual Basic. +
· C# is cross-platform, simple, powerful, type-safe, and object-oriented while retaining the expressiveness and elegance of C-style languages. Anyone familiar with C or Java will find few problems in adapting to C#.
· F# is a cross-platform, functional-first programming language that also supports traditional object-oriented and imperative programming.
· Visual Basic is an easy language to learn that you can use to build a variety of applications that run on .NET.
.NET also provides very powerful features like LINQ, Generics (Generic Types), Delegates and Lambdas, easy Async Programming, Native interoperability with the platforms (Windows, iOS and Android), etc. Most of them are shared across the languages and also shared across the frameworks (.NET Framework, .NET Core and Xamarin).
.NET Compiler Platform (Roslyn) – .NET Compiler Platform, better known by its codename “Roslyn”, is a set of open-source compilers and code analysis APIs for C# and Visual Basic .NET languages.
Roslyn provides rich code analysis APIs. It enables building code analysis tools with the same APIs that are used by Visual Studio.
Automatic memory management and GC – Garbage collection is a well-known of .NET features. Developers do not need to actively manage memory, although there are mechanisms to provide more information to the garbage collector (GC).
Framework Libraries – .NET has an expansive standard set of class libraries related to each .NET implementation (.NET Framework Class Library, CoreFx, Mono Class Library, etc.). For further information, check this info on the Framework Libraries in .NET.
Building cross-platform libraries – The .NET Standard Library and the .NET Platform Standard.
This new unification has been created in order to provide a more concrete guarantee of binary portability to future .NET-capable platforms with an easier-to-understand platform versioning plan.
Today, Portable Class Libraries (PCL) target an intersection of APIs depending on your platform selection when making the project. This gives you a specific surface area that guarantees you work on the chosen platforms. Those combinations are precomputed to give you the right set of surface area. When these portable libraries are packaged into NuGet, they are expressed with a static set of frameworks e.g. portable-net45+win8. While this describes the intent that you want to run on .NET Framework 4.5 and Windows 8.0, it is also restrictive, since new platforms can appear in the future that are perfectly capable of running those PCLs but are blocked due to the platforms that were selected when the project was created.
Here’s a diagram of the new cross-platform libraries development approach that is evolving from the PCL approach. Take a look at the “.NET Standard Library” area in the second half below.
The .NET Standard Library is a “blessed” set of core .NET APIs and versions that are prescribed to be used and supported together. This includes all of the APIs in the Platform Standard (Platform Agnostic Assemblies) plus additional libraries that are fundamental to .NET but built through the Platform Standard contracts.
The .NET Platform Standard version represents binary portability across platforms using a single moniker. They are an evolution of the existing Portable Class Library system. They are “open-ended” in that they aren’t tied down to a static list of monikers like portable-a+b+c is.
.NET Platform Standard versions are not too different to the PortableXXX profiles people use today which get represented in NuGet as portable-a+b+c (eg. Profile111). The key difference is that the single .NET Platform Standard moniker evolves and versions linearly, such that NuGet and other tools can infer compatibility, i.e. newer .NET Platform Standard versions are compatible with older ones.
Here’s another diagram focusing specifically on the .NET Standard Library and the .NET Platform Standard (contracts):
Take into account that this is about a “common denominator” for platforms APIs. The more platforms/frameworks you target, the less API surface you’ll have available. For instance, netstandard1.0 claims to support the most platforms, but fewest APIs. On the other hand, netstandard1.6 claims to support the fewest platforms (the most modern platforms), but with a larger number of more recent set of APIs available for those particular platforms/frameworks.
For example, netstandard1.6 supports only .NET Core 1.0 and .NET Framework 4.6.3 but with all the most recent set of APIs. On the other hand, netstandard1.0 supports the common denominator of .NET Core 1.0, .NET Framework 4.6.3, 4.6.2, 4.6.1, 4.6, 4.5.2, 4.5.1 and 4.5 plus UWP, WinForms, etc.
About practical usage, there is a simplifying way to think about it. You can ignore platforms and target the latest platform standard version (as of June 2016, it is v1.6). If after testing you realize that it doesn’t work all the platforms you want it to work, then start targeting older versions until you stop hitting something you need that isn’t supported (some missing API for example) and stop lowering your library’s platform standard version.
The .NET Platform Standard is based on the standard platform surface area. Microsoft can’t retroactively port all of the existing API from .NET Framework because many APIs are tight to specific versions of Windows and the traditional .NET Framework is not cross platform friendly and therefore some of the things just don’t make sense in all platforms. This .NET Standard Platform is the new cross platform friendly base surface area for current and future .NET platforms.
For further information about the .NET Platform Standard and a detailed list of framework versions supported by each version of the .NET Standard Library, check its GitHub page here.
Stats: .NET Core vs. .NET Framework 4.x and other frameworks
.NET Core supports building very high performance web applications, like websites and Web APIs microservices with ASP.NET Core.
ASP.NET Core running on CoreCLR is one of the fastest web frameworks. When published publicly, I’ll update this post here to show it is in the top 5 of the TechEmpower web benchmark beating out other popular web frameworks like Java Servlet, NodeJS, Ruby on Rails and PHP in raw performance.
In the meantime, you can also review the following performances and scalability tests below made with ASP.NET Core RELEASE CANDIDATE a few weeks ago by Ben Adams (3rd party).
Third party Benchmark Tests – 1.15 Million RPS – .NET Core
As published in the Internet here by Ben Adams (independent third party) in a performance benchmark done in February 2016, ASP.NET Core Release Candidate running on .NET Core achieved 1.15 Million RPS which represents a 2300% gain from ASP.NET 4.6 and almost the same difference compared to Node.js.
The third decimal place 0.05 Million (e.g. 50,000) is around the total number of requests per second that ASP.NET 4.6 could perform of the same type, on the same hardware – as shown in the below graph:
ASP.NET 4.6 and Node.Js are bottom left. You cannot even see it at the bottom.
You can see the rapid strides in performance the leaner, more agile and componentized stack has taken (blue Windows, orange Linux) in the last months of development.
ASP.NET Core and .NET Core come with the great advantage of only including the libraries and functions you explicitly want to use in your application rather than bringing in the entire framework. So you only “pay”, programmatically speaking, for what you use.
Create your own benchmarks easily – With the ASP.NET Performance Tests project (libraries, scripts and tools) available at GitHub (https://github.com/aspnet/Performance) you can easily create your own performance tests and benchmarks. If you do, I’d be glad to know your results! Ping me through Twitter at @CESARDELATORRE for that! 🙂
Business benefits from .NET Core
At a business level, the .NET Core is improving many areas which ultimately means a much lower TCO (Total Cost of Ownership) of your applications.
1. Best in class efficiency of resources’ usage. This is very important for the business. It means that you can do more with less. As shown in the “Stats section” in this document, with .NET Core you can run many more services and web applications in the same unit of hardware/servers or VMs in the cloud because .NET Core makes possible a high density of processes per hardware unit.
a. Especially in microservices architectures where you can have hundreds or thousands of microservices running, if those microservices are built with .NET Core you’d be able to run your system with a much lower number of servers/VMs, for instance, your Azure Service Fabric cluster of VMs could leverage a lot more horsepower or you could have less VMs and pay less. But even in a more traditional world of simple VMs, this is also true.
b. You can leverage this great performance when running processes especially when you have low latency accessing your data. If your bottleneck is a database server, you won’t be able to take advantage of it. But if you cache your data or even better use stateful services (like the ones in Azure Service Fabric) you’d be able to leverage this great performance from .NET Core.
c. This means less cost paying to your cloud provider or the same cost but being able to run many more services paying a similar amount.
2. Cero impact with no friction with new versions of .NET Core because of side-by-side. Easy side-by-side installation of different versions of .NET Core on the same machine without version collision eliminates risks and saves money from maintenance and IT operations point of view. Even when the traditional .NET Framework (4.x) always had great version compatibility, there were risks because when upgrading the .NET Framework in a machine due to the fact that a new app needed a new version of the framework, that could impact the rest of the apps in the same machine.
a. No having those risks anymore with .NET Core also means less cost in testing, development, maintenance and IT operations.
3. Lower costs and multi-vendor in an open cross-platform world – Application portability or your product can be costly if you need to migrate Windows applications/services to Linux or vice versa. With .NET Core and its multi-platform capabilities, you can either negotiate with an existing vendor (cloud/platform) or pick the vendor of your choice across platforms.
When should I use .NET Core?
The following are the most important reasons why you would care and want to use the .NET Core Platform:
1. Cross-Platform needs. Clearly, if your goal is to have an application (web/service) that should be able to run across platforms (Windows, Linux and MacOS), the best choice in the .NET ecosystem is to use .NET Core as its runtime (CoreCLR) and libraries are cross-platform. The other choice is to use the Mono Project.
Both choices are open source, but .NET Core is directly and officially supported by Microsoft and will have a heavy investment moving forward.
When using .NET Core across platforms, the best development experience exists on Windows with the Visual Studio IDE which supports many productivity features including project management, debugging, source control, refactoring, rich editing including Intellisense, testing and much more. But rich development is also supported using Visual Studio Code on Mac, Linux and Windows including intellisense and debugging. Even third party editors like Sublime, Emacs, VI and more work well and can get editor intellisense using the open source Omnisharp project.
2. Microservices – When you are building a microservices oriented system composed of multiple independent, dynamically scalable, stateful or stateless microservices, the great advantage that you have here is that you can use different technologies/frameworks/languages at a microservice level. That allows you to use the best approach and technology per micro areas in your system, so if you want to build very performant and scalable microservices, you should use .NET Core. Eventually, if you need to use any .NET Framework library that is not compatible with .NET Core, there’s no issue, you can build that microservice with the .NET Framework and in the future you might be able to substitute it with the .NET Core.
The infrastructure platform you could use are many. Ideally, for large and complex microservice systems, you should use Azure Service Fabric. But for stateless microservices you can also use other products like Azure App Service or Azure Functions.
Note that as of June 2016, not every technology within Azure supports the .NET Core, but .NET Core support in Azure will be increasing dramatically now that .NET Core is RTM released.
3. Best performant and scalable systems – When your system needs the best possible performance and scalability so you get the best responsiveness no matter how many users you have, then is where .NET Core and ASP.NET Core really shine. The more you can do with the same amount of infrastructure/hardware, the richer the experience you’ll have for your end users – at a lower cost.
The days of Moore’s law performance improvements for single CPUs does not apply anymore; yet you need to do more while your system is growing and need higher scalability and performance for everyday’ s more demanding users which are growing exponentially in numbers. You need to get more efficient, optimize everywhere, and scale better across clusters of machines, VMs and CPU cores, ultimately. It is not just a matter of user’s satisfaction; it can also make a huge difference in cost/TCO. This is why it is important to strive for performance and scalability.
As mentioned, if you can isolate small pieces of your system as microservices or any other loosely-coupled approach, it’ll be better as you’ll be able to not just evolve each small piece/microservice independently and have a better long-term agility and maintenance, but also you’ll be able to use any other technology at a microservice level if what you need to do is not compatible with .NET Core. And eventually you’d be able to refactor it and bring it to .NET Core when possible.
4. Command line style development for Mac, Linux or Windows. This approach is optional when using .NET Core. You can also use the full Visual Studio IDE, of course. But if you are a developer that wants to develop with lightweight editors and heavy use of command line, .NET Core is designed for CLI. It provides simple command line tools available on all supported platforms, enabling developers to build and test applications with a minimal installation on developer, lab or production machines. Editors like Visual Studio Code use the same command line tools for their development experiences. And IDE’s like Visual Studio use the same CLI tools but hide them behind a rich IDE experience. Developers can now choose the level they want to interact with the tool chain from CLI to editor to IDE.
5. Need side by side of .NET versions per application level. If you want to be able to install applications with dependencies on different versions of frameworks in .NET, you need to use .NET Core which provides 100% side-by side as explained previously in this document.
6. Windows 10 UWP .NET apps. UWP .NET apps use .NET Core underneath.
When should I not use .NET Core?
The latest and greatest is not always the best choice for all situations and contexts. In fact, there are still many scenarios where you should still not use .NET Core :
1. Current .NET Framework applications in production / Migrations – In most cases, you still don’t need to migrate your current .NET applications like ASP.NET apps to run on .NET Core. Not just because the cost of the migration and code rewriting would be significant but also because as of today (2016) you’ll find that many of the third libraries that you are executing from .NET Framework code cannot be used from an app running on .NET Core.
However, if you want to start taking advantage of the new capabilities provided by ASP.NET Core (see the value-props from ASP.NET Core explained earlier in this doc), you can still migrate to ASP.NET Core but running on the traditional CLR from the .NET Framework. That would allow you to reuse legacy third party .NET libraries not compatible with .NET Core while taking advantage of new web capabilities and approaches in ASP.NET Core.
2. New large monolithic applications – If you are developing a large enterprise application that cannot be loosely coupled and composed by isolated components or services (like with a microservice architecture approach) chances are that as soon as you need to consume libraries that are compatible only with the .NET Framework, if you are using the .NET Core runtime it’ll be a stopper as those components/libraries that you need cannot be run on the CoreCLR runtime and with a monolithic approach it is difficult to isolate components/services with a single responsibility that could be running on .NET Core.
Note that this doesn’t mean that with .NET Core you always have to use a microservices approach and cannot build traditional architecture models (like layered or N-Tier). You can perfectly do it. The issue here is with libraries’ compatibility and allowed references per project/assembly/service.
A feasible approach here would be to use ASP.NET Core but running it on top of the .NET Framework and the traditional CLR, so you can consume any .NET library from the framework or third party. In the future you could eliminate those dependencies so it’ll be possible to run as a pure .NET Core application. But this refactoring task with a monolithic architecture won’t be as easy as if it had a loosely coupled architecture.
3. Need full capabilities of higher level frameworks like Entity Framework 6.x, WCF and Windows Workflow Foundation. Even when .NET Core has several new libraries related (like EF Core or WCF for .NET Core) targeting part of those areas, yet in .NET Core 1.0 they don’t have all the functionality of their peers in the .NET Framework but are provided to make porting code easier for developers who need the capabilities provided by .NET Core.
Again, if you need libraries/functionality that is still not supported by .NET Core, the recommended approach is to create decoupled microservices using the full .NET Framework that eventually could be migrated to .NET Core so you get additional performance and scalability benefits for those microservices in the future.
4. Need sub-frameworks not supported by .NET Core. If you need to use sub-frameworks like WPF, WebForms, WinForms or other frameworks not supported by .NET Core, you still need to use the .NET Framework. See the “When should I still use .NET Framework 4.x?” section for more details.
Possible frameworks to be ported to .NET Core – For a full list, take a look at CoreFX issues marked as port-to-core. Please note that this list doesn’t represent a commitment from Microsoft to open source all these components or even bring them to .NET Core — they are simply capturing the desire from the community to do so. That being said, if you care about any of the components listed above, consider participating in the discussions on GitHub so that your voice can be heard. And if you think something is missing, file a new issue.
When should I still use .NET Framework 4.x?
The pick between the different frameworks should not be based on which has a better architecture but should be based on the strengths and weaknesses of the technologies and which system has better solution for the task at hand, for your particular context and application or subsystem or microservice type. The latest and greatest technologies usually have a more modern architecture, but that doesn’t mean that you should always pick the latest. There are many situations where a more mature platform is still a better choice until the new frameworks grow further and get more mature, or simply because certain legacy sub-frameworks are only supported by the .NET Framework.
In summary, you still might need to use the .NET Framework in a large variety of cases, as explained below:
1. ASP.NET Core running on the .NET Framework/CLR. Remember, if you need to consume traditional/legacy libraries based on the .NET Framework, you can still use ASP.NET Core with its own benefits (MVC+WebAPI unification, self-hosting, cloud-ready environment-based config system and built-in dependency injection) but running it on top of the .NET Framework (traditional CLR). In this case, you will lose the intrinsic .NET Core and CoreCLR benefits (cross-platform and modular/lightweight framework) until you eliminate those dependencies with legacy libraries, but you could do that in the future.
2. ASP.NET Web Forms applications. As of June 2016, ASP.NET Web Forms is only supported/provided by the full .NET Framework, so you cannot use ASP.NET Core / .NET Core for this scenario.
3. Visual Basic support. As of June 2016, Visual Basic is not supported by .NET Core and ASP.NET Core, although it is in the future roadmap.
4. ASP.NET Web Pages applications. As of June 2016, ASP.NET Web Pages is only supported/provided by the full .NET Framework, so you cannot use ASP.NET Core / .NET Core for this scenario. Although Web Pages is in the future roadmap.
5. ASP.NET SignalR server/client implementation. As of June 2016, ASP.NET SignalR (server and client implementation) is only supported as RTM by the full .NET Framework, so you still cannot use ASP.NET Core / .NET Core RTM for this scenario in production, yet. Although, SignalR’s implementation is in the ASP.NET roadmap and in preview state and being currently developed at https://github.com/aspnet/SignalR-Server (Server side) and https://github.com/aspnet/SignalR-Client-Net (Client Library) and will be RTM released in the near future.
6. Desktop apps including Windows 7 and Windows 8. If you want to build Desktop applications that run on Windows 7 through Windows 10, you need to use the .NET Framework.
a. WPF (Windows Presentation Foundation) applications. WPF is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
b. Windows Forms applications. WinForms is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
7. WCF services implementation. Even when there’s a WCF-Client library to consume WCF services from .NET Core, as of June 2016, WCF services/server implementation is only supported/provided by using the full .NET Framework, so you cannot use .NET Core for this scenario. Microsoft is considering this scenario for the future roadmap, but not confirmed, though.
8. WF (Windows Workflow Foundation) workflows implementation. WF service implementation is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
9. Workflow Services. Workflow Services (WCF+WF in a single service) is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
10. WCF Data Services (formerly known as “ADO.NET Data Services”). WCF Data Services is only supported/provided by the full .NET Framework, so you cannot use .NET Core for this scenario.
11. Azure’s products that still don’t support .NET Core. As of June 2016, there’s a number of Azure products still not supported by .NET Core, like Service Fabric Stateful Reliable Services, Service Fabric Reliable Actors, and quite a few products where their client SDK requires the full .NET Framework. However, now that the .NET Core RTM has been released (June 2016), most of the products in Azure will provide compatibility with .NET Core. In regards Azure products remote consumption even when the client SDK might still be not available for .NET Core, you can always use the REST API that most Azure products provide from .NET Core, as well.
12. Need to use third party .NET libraries or NuGet packages not available for .NET Core – Use ASP.NET Core running on the .NET Framework for this scenario, or just the .NET Framework. Some of the third party Nuget packages might not be available on .NET Core yet.
When should I not use .NET Framework 4.x?
1. When running across OS platforms is a requirement for your system or sub-system/microservice. Clearly, the .NET Framework is only supported by Windows. If you need to run on a different OS, you cannot use the .NET Framework but you should evaluate and choose between .NET Core or Mono.
2. In Bounded loosely-coupled services or web applications that require the best possible performance and scalability and can be implemented with .NET Core – This case is similar to “Microservices” and “Best performant and scalable systems” in the “When should I use .NET Core?” section of this document.
3. (Evaluate) Some long-term mission-critical and core-business subsystems/microservices. In this type of sub-systems or microservices that are strategic for the business and will be evolving for many years, you usually want to invest on technologies that will be getting the most investment and innovation from the vendor so that will improve your core system. Even when the .NET Framework will be evolving and getting investment from Microsoft, it’ll be at a slower pace than with .NET Core due to its own nature (The .NET Framework is older and not designed with a modular architecture that can be evolving at a much faster pace, autonomously per NuGet package). Therefore, you should evaluate sub-system per sub-system or microservice per microservice, and if possible, use .NET Core and ASP.NET Core. If it is not possible because of incompatibility issues with legacy libraries, then use ASP.NET Core running on the .NET Framework or simply use the .NET Framework, but try to evaluate first if .NET Core fits for your new sub-system or microservice level, so migrations in the future will cost less.
Note that we state “some subsystems/microservices” and not a whole mission-critical application, as with .NET Core 1.0 it is highly probable that some parts of your system cannot be implemented and you still need to use the .NET Framework for that particular subsystem/microservice.
In summary, do not use the .NET Framework if what you want to do can be perfectly done with .NET Core, like many front-end web sites or microservices.
4. When using an Opened Source Framework is a requirement for you. As mentioned before, while the code for the .NET Framework is available for reference it is not an active open source project.
When should I use Xamarin?
1. You are looking to create native mobile apps with the best possible UI and performance and targeting several OS platforms – If you want to get the best performance and beautiful UI (like when building a flagship app targeting consumer users) the way to go is “native”, where Xamarin os one of the choices as well as Objective-C/Swift and Java. But, if in addition to that you need to target at least two platforms (iOS and Android), then Xamarin is the best possible choice for a native plus cross-platform approach.
2. .NET/C#/F# skills are mainstream in your development team – If your development team has .NET skills, when developing mobile apps, you should choose Xamarin.
When should I not use Xamarin?
2. (Optional / To evaluate) – B2E apps with the same UI across platforms – This scenario is in reality something to evaluate as you can achieve it either with hybrid Cordova apps or with Xamarin.Forms since with both technologies you can create a single page/view that will be translated to the different OS platforms (iOS, Android and Windows).
This scenario, which requires exactly the same app’s UI across the OS platforms is something very typical from enterprise B2E (Business to Employees) apps where the organization wants an app with the same UI, layout and use workflow no matter if the app is running on iOS, Android or Windows, so it is easier to be supported by IT. In this scenario the important point is “to run the business” and specific/different look and feel per platform is not important or even undesirable.
Roadmap for .NET Core
The .NET Framework, .NET Core and Xamarin provide many options for building applications under the .NET ecosystem.
.NET Core offers some differences from .NET Framework such as ASP.NET Core, Native Console, UWP, Side by Side, No Impact Installation, Open Source, Cross Platform and CLI tooling. This is great innovation and a foundation for the future, available today! (.NET Core RTM is our since June 27th 2016).
.NET Framework, .NET Core and Xamarin are built on and share many underlying technologies.
In the future, Microsoft is invested in moving .NET forward and that includes.NET Framework, .NET Core and Xamarin.
.NET Core being released at the DEVNATION conference (June 27th 2016)
We’re serious about .NET and cross-platform so we chose to release .NET Core RTM at the DEVNATION conference, a very Linux focused event, precisely because .NET Core is cross-platform! 🙂
In fact, this is what RedHat folks said today about .NET, amazing, right?