.NET Core vs .NET Framework: How to Pick a .NET Runtime for an Application

Is .NET Core the next big thing? We’ve been toying with it for a while now, and we tend to think that it is. In fact, we predict that there will be a huge demand for developers skilled in this technology in 2018. But how does it differ from the .NET Framework, and what do you need to know to use them effectively? In this post, we’ll explain the main differences and offer some guidance on how to make the best use of each.

Historically, the .NET Framework has only worked on Windows devices. The Xamarin and Mono projects worked to bring .NET to mobile devices, macOS, and Linux. .NET Core provides a standard base library that can now be used across Windows, Linux, macOS, and mobile devices (via Xamarin).

There are four major components of .NET architecture:

• Common language specification (CLS) defines how objects are implemented so they work everywhere .NET works. CLS is a subset of Common Type System (CTS) — which sets a common way to describe all types.
• Framework class library (FCL) is a standard library that collects reusable classes, interfaces, and value types.
• Common language runtime (CLR) is the virtual machine that runs the framework and manages the execution of .NET programs.
• Tools such as Visual Studio to create standalone applications, interactive websites, web applications and web services.

Microsoft maintains both runtimes for building applications with .NET and they share many of the same APIs. This shared API is what is called the .NETStandard.

Image via Wikipedia

Developers use the .NET framework to create Windows desktop applications and server based applications. This includes ASP.NET web applications. .NET Core is used to create server applications that run on Windows, Linux, and Mac. It does not currently support creating desktop applications with a user interface. Developers can write applications and libraries in VB.NET, C#, and F# in both runtimes.

C# is an object-oriented language similar to other C-styled languages. The learning curve should not be a problem for developers already working with C and similar languages.

F# is a cross-platform language that also uses object oriented programming.

Visual Basic is available in the .NET Framework with limited .NET Core support with .NET Core 2.0.

Developers Should Use .NET Core When…

A cross-platform and open-source framework, it can be used to develop applications on any platform. Often it is used for cloud applications or refactoring large enterprise applications into microservices.

Screenshot via Microsoft.com

So when should you use it? When…

• There are cross-platform needs. Use it when the application needs to run across multiple platforms such as Windows, Linux, and macOS. Those operating systems are supported as development workstations (and the list of supported operating systemsis growing):
  • Visual Studio can be used on Windows with a new limited version on the macOS.
  • Visual Studio Code can be used on Windows, Linux, and macOS.
  • The command line can be used on all supported platforms.
• Microservices are being used. Microservices, a form of service-oriented architecture, are software applications comprised of small, modular business services. Each service can run a unique process, be deployed independently and be created in different programming applications. .NET Core allows a mix of technologies, is lightweight and can be minimized for each microservice. It is scalable as new microservices are added.
• When Docker containers are being used. Containers and microservices architecture often are used together. Because it is lightweight and modular, .NET Core works very well with containers. Server apps can be deployed cross-platform to Docker containers. .NET Framework can be used for containers, but the image size is larger.
• If you have high performance and scalable system needs. Microsoft recommends running .NET Core with ASP.NET Core for the best performance and scale. This becomes important when hundreds of microservices could be used. A lower number of servers and virtual machines should be needed. The efficiency and scalability gained could translate to a better user experience in addition to cost savings.
• If you are running multiple .NET versions side-by-side. To install applications with dependencies on different versions of frameworks in .NET, developers need to use .NET Core. Multiple services can be run on the same server with different versions of .NET.
• If you want command line interface (CLI) control. Some developers prefer working in lightweight editors and command line control. .NET Core has a CLI for all supported platforms. It requires minimal installation on production machines. And there still is the opportunity to switch to an IDE such as Visual Studio IDE.

When Not to Use .NET Core

One issue is that it does not have some .NET features or support all libraries and extensions. There are a few situations in which it may not (currently) be the best option, although, with continued development, it will likely be workable for most use cases eventually. Consider the following scenarios:

• Windows Forms and WPF applications are not supported. You still have to use mono to make a .NET desktop application for macOS.
• ASP.NET WebForms don’t exist. Microsoft has plans to port them to ASP.NET Core.
• You need to create a WCF service. .NET Core does not currently support WCF. Instead, you would need to make a REST API with ASP.NET Core MVC.
• Missing 3rd party library support. .NET Core 2.0 provides a compatibility shim between .NET Framework and .NET Core. But, you may still have issues with compatibility if the class library uses any .NET Framework APIs that are not supported. Although, this will help bridge a lot of class libraries to .NET Core.
• Missing .NET Framework features. Some .NET Framework functionality is still missing in .NET Core. For example, Entity Framework Core is not the exact same as Entity Framework v6.
• You need to access Windows specific APIs. If your application needs to work with the Windows Registry, WMI, or other Windows specific APIs, it won’t work with .NET Core. It is designed to be more sandboxed away from the OS.
• Partial support for VB.NET and F#. Microsoft and the community continue to work on this but it isn’t 100% yet.
• SignalR is not supported. It is planned for .NET Core 2.1 and is coming soon.

Developers Should Use .NET Framework When…

.NET Framework is what is distributed with Windows. Generally, it is used to build desktop Windows apps and large-scale enterprise applications using .NET workflow and data connection tools.

It provides services that include:

• Memory management
• Type and memory safety
• Security
• Networking
• Application deployment
• Data structures
• APIs

It can be used with Docker and Windows Containers, and using it is most feasible when…

• It is already being used. Instead of migrating, extend the application. For example, developers can write a new web service in ASP.NET Core.
• You’re using third-party libraries or NuGet packages not available in .NET Core. While .NET Core is becoming more widely used, you’ll need to use the .NET Framework if you’re working with .NET Framework libraries that aren’t compatible. NuGet is the free and open source package manager for .NET and other Microsoft development platforms. The NuGet ecosystem includes client tools that provide the ability to produce and consume packages. It also has a central package repository for package authors and consumers. It is available as a Visual Studio extension.
• You’re using technologies not yet available in .NET Core.It does not support all .NET Framework technologies. These not-yet-available technologies include:
  • ASP.NET Web Forms applications (no plans to port).
  • ASP.NET Web Pages applications (plans to port).
  • ASP.NET SignalR server/client implementation (plans to port).
  • WCF services implementation (no plans to migrate, but it is being considered).
  • Workflow related services (no plans to port) including Windows Workflow Foundation (WF), Workflow Services (WCF + WF in a single service), and WCF Data Services (formerly known as “ADO.NET Data Services”).
  • Windows Presentation Foundation (WPF) and Windows Forms (no plans to port).
  • Visual Basic and F# (both to be supported in Visual Studio 2017).
• The platform does not support .NET Core. Again, not all Microsoft and third-party platforms support it, such as some of Azure’s services. Many plan on adding support eventually, however. You may encounter some issues even with supported services, which, as developers, you know comes with the territory. With .NET Core increasingly gaining traction, it’s becoming easier to find tutorials and workarounds for issues you may encounter. For instance, we encountered a 502.5 Process Failure when trying to start an Azure App Service and wrote up a post offering guidance for others who encounter the same issue.

When Not to Run .NET Framework

There are also a few situations in which you shouldn’t run the .NET Framework, including when:

• Multiple OS platforms are required.
• High performance and scalability are needed.
• If .NET Core works.
• Open source framework is required.

How to Port From .NET Framework to .NET Core

Follow these steps:

1. Analyze Third Party Dependencies

This involves more than just knowing what the third party dependencies are. There needs to be an understanding of how the app depends on those third party dependencies if they run on .NET Core, and what needs to be if they do not run.

NuGet packages are easy to check because it usually says on NuGet’s website plus the package has a set of folders for each platform. You can also look under Dependencies on the page for the package and look for a folder or entry with any of the following names:

netstandard1.0
netstandard1.1
netstandard1.2
netstandard1.3
netstandard1.4
netstandard1.5
netstandard1.6
netcoreapp1.0
portable-net45-win8
portable-win8-wpa8
portable-net451-win81
portable-net45-win8-wpa8-wpa81

If the dependencies are not NuGet packages, the ApiPort tool can check the portability of the dependency.

New with .NET Core 2.0, a compatibility shim can make it possible to reference .NET Framework packages that have not been switched to use .NET Standard. Be sure to thoroughly test these packages as they may still have issues if they use unsupported APIs.

2. Target the .NET Standard Library

The .NET Standard library is intended to be available on all .NET runtimes, so targeting the .NET Standard library is the best way to build a cross-platform class library.

There are multiple versions to consider that are available to varying degrees across eight platforms. If a project targets a lower version, it cannot reference a project that targets a higher version. Pick the lowest possible .NET Standard version to use across all projects. Below is a chart with each .NET Standard version that shows the specific areas they run on:

Screenshot via Microsoft.com

3. Retarget Projects

All the projects to be ported need to be targeted to .NET Framework 4.6.2. This will ensure API alternatives for .NET Framework specific targets can be used for non-supported APIs.

This is done easily in Visual Studio with a “Target Framework” command and recompiling the projects.

4. Port Tests Code

Porting code to .NET Core is a significant change; testing is strongly encouraged. Use a suitable testing framework such as:

• xUnit
• NUnit
• MSTest

With tools like xUnit, it’s possible to use templates and edit them to write .NET Core tests. Here’s an example of an edited .csproj file:

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>

<ItemGroup>
<PackageReference Include="xunit" Version="2.3.0-beta2-build3683" />
<DotNetCliToolReference Include="dotnet-xunit" Version="2.3.0-beta2-build3683" />
</ItemGroup>

</Project>

5. Execute the Porting Plan

The best way to port the code depends on how the framework is structured. But breaking the code base into steps and layers should work well.

1. Identify the “base” of the library. This base could be the data models or classes and methods that everything else needs to use.
2. Copy the base into a new .NET Core project.
3. Make any changes needed to compile the code.
4. Copy another layer of code and repeat.

Then There Is Xamarin

Xamarin may sound like a new prescription medication, but Xamarin is a platform for developing apps that run on iOS, Android, or Windows Phone devices.

Xamarin is written in C# and included in all editions of Visual Studio.

Microsoft promises that Xamarin is the best way to create a user interface (UI) and optimize performance in apps in multiple platforms. This is important during an era when apps need to run on at least iOS and Android devices.

Xamarin shares code across platforms and uses a single technology stack to decrease time to market and engineering costs. But user interface intensive apps may need more platform-specific coding. The amount of code sharing and savings then decreases.

More .NET Platforms on .NET Standards

In addition to .NET Framework, .NET Core and Xamarin, .NET Standards also supports the following platforms:

• Mono — An open-source .NET created before Xamarin and Microsoft collaborated. It is based on the ECMA standards for C# and the Common Language Infrastructure. In addition to C#, developers can use VB 8, Java, Python, Ruby, Eiffel, F#, and Oxygene.
• Universal Windows Platform — Software platform created by Microsoft to help develop apps that run on Windows 10, Windows 10 Mobile, Xbox One, IoT and Hololens devices. Developers can use C++, C#, VB.NET, and XAML.
• Windows — versions 8.0 and 8.1 are supported.
• Windows Phone — Windows Phone was primarily developed for the consumer market and replaced by Windows 10 Mobile in 2015.
• Windows Phone Silverlight — The deprecated application framework was designed to run internet applications and compete with Adobe Flash.

All these platforms will implement .NET Standards — a common set of APIs that replaces portable class libraries (PCLs). This ensures code sharing across desktop applications, mobile apps and games, and cloud services.

Additional Resources and Tutorials

For more information, including helpful tutorials, visit the following resources:

• .NET Core Roadmap (GitHub)
• .NET Framework Guide (Microsoft)
• .NET Core Guide (Microsoft)
• Microservice Architecture – A Quick Guide (JavaCodeGeeks.com)
• How We Use Cake to Build .NET Core Apps and Version Assemblies (Stackify)
• How to Create .NET Core Windows Services with Visual Studio 2017 (Stackify)
• ASP.NET Core Authentication Tutorial (Auth0)