Stackify is now BMC. Read theBlog

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

By: Stackify

| February 28, 2024

A while back we predicted that .NET Core would be the next big thing, offering developers many options in application development. Indeed, there is huge demand for developers skilled in this technology. But how does it differ from the .NET Framework, and what do you need to know to use them both effectively?

Today, we’ll contrast .NET Core vs. .NET Framework to help you choose which one to use for your next project. In this post, we’ll explain their key differences and how to make the best use of each. Let’s begin with a background on .NET.

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. Now, .NET Core provides a standard base library that’s usable 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
Visual Studio is used to create standalone applications, interactive websites, web applications and web services

.NET Core vs .NET Framework

Microsoft maintains both runtimes for building applications with .NET while sharing many of the same APIs. This shared API is called the .NET Standard.

Image via Wikipedia

Developers use the .NET Framework to create Windows desktop and server-based applications. This includes ASP.NET web applications. On the other hand, .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-style 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 .NET Framework with limited .NET Core support with .NET Core 2.0.

When to Use .NET Core

A cross-platform and open-source framework, .NET Core is best when developing applications on any platform. .NET Core is used for cloud applications or refactoring large enterprise applications into microservices.

A cross-platform and open-source framework, .NET Core screenshot

Screenshot via Microsoft.com

You should use .NET Core 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 systems is growing):
- Visual Studio is compatible on Windows with a new limited version on macOS
- Visual Studio Code can be used on Windows, Linux and macOS
- All supported platforms allow the use of the command line
Using Microservices. Microservices, a form of service-oriented architecture, are software applications consisting 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 scalable for each microservice
Working with Docker containers. Containers and microservices architecture are often used together. Because it is lightweight and modular, .NET Core works very well with containers. You can deploy cross-platform server apps to Docker containers. .NET Framework works with containers, but the image size is larger
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 using hundreds of microservices. In such a case, a lower number of servers and virtual machines is best. The efficiency and scalability gained should translate to a better user experience in addition to cost savings
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 are executable on the same server with different versions of .NET
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 and 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

.NET Core does not have some of the .NET features nor support for all libraries and extensions. As such, you may encounter a few situations in which .NET Core may not be the best option (though continued development will likely eliminate this drawback). 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 – Though Microsoft provides strategies for migrating ASP.NET Web Forms apps
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 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 (though 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’s not yet 100%

Developers Should Use .NET Framework When…

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

The .NET Framework provides services that include:

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

.NET Framework can be used with Docker and Windows Containers and 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 – Despite .NET Core’s popularity, you’ll need to use the .NET Framework when working with libraries that aren’t compatible with .NET Core. 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 – .NET Core 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)
The platform does not support .NET Core – Again, not all Microsoft and third-party platforms support it, such as some of Azure’s services. You may encounter some issues even with supported services, which 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. So, we published 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. These include when:

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

How to Port from .NET Framework to .NET Core

If and when you decide to migrate your .NET Framework to .NET Core, follow these steps (after a proper assessment, of course):

1. Analyze Third Party Dependencies

More than just knowing what the third-party dependencies are, you need to understand how the application functions with the third-party dependencies that run on .NET Core. You also need to be aware of what needs to be done if they do not run.

NuGet packages are easy to check plus the package has a set of folders for each platform. You can also look for a folder or entry on the Dependencies page 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.

Since .NET Core 2.0, a compatibility shim allows referencing .NET Framework packages that haven’t 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:

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. Here is how to do it:

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

Then There is Xamarin

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

Xamarin is written in C# and available 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 on multiple platforms. This is important today 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 replace portable class libraries (PCLs). This ensures code sharing across desktop applications, mobile apps, mobile games and cloud services.

It’s important to always have a good APM in place for your .NET application. Retrace is a great full lifecycle option that you can try for free.

You can also try Netreo’s free code profiler Prefix to write better code on your workstation. Prefix works with .NET, Java, PHP, Node.js, Ruby and Python.

Improve Your Code with Retrace APM

Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.