.NET Core vs .NET Framework

presented by Lukas Grolig

JIT Compilation

The JIT compiler translates the MSIL code of an assembly to native code and uses the CPU architecture of the target machine to execute a .NET application.

It also stores the resulting native code so that it is accessible for subsequent calls.

If a code executing on a target machine calls a non-native method, the JIT compiler converts the MSIL of that method into native code.

JIT Compilation

NGen

does JIT after instalation or during deployment. Also called pre-JIT.

Econo

when runned only excecuted methods are JITed and after closing program everything is dropped.

Standard JIT

The compiler compiles only those methods called at run time.

After executing this method, compiled methods are stored in a memory cache.

Now further calls to compiled methods will execute the methods from the memory cache.

RyuJIT in Core

New JIT architeture partialy shared.

Targerts not only Intel architectures but also ARM.

Multiple code generation targets (instruction sets and operating systems),

Improved optimizations,

Better and more flexible code generation, and

Open, flexible, and robust design and implementation.

Difereneces from JIT32 and JIT64

RyuJIT in Core

Allowing .NET to have multiple compilations for the same method that can be hot-swapped at runtime. This separates the decision making so that we can pick a technique that is best for startup, pick a second technique that is best for steady-state and then deliver great performance on both.

Tiered Compilation

.NET Core receives with each version even more otimizations

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.html

and we have crossgen

JIT compilation

Most of .NET Core is using JIT compilation.

 JITs are well suited for long-running scenarios. They generate code that targets a specific machine configuration, including specific CPU instructions.

A JIT can also re-generate methods at runtime to achieve a highly-tuned version of the frequently used method.

AOT Compilation

MONO is using LLVM to do AOT compilation. The same is for Blazor Framework.

The goal of .NET 5 is to use AOT compilation in most cases but use JIT in cases where AOT performance is not great (= generics).

AOT provides fast startup, low footprint, and lower memory usage

.NET Standard

Common Intermediate Language (aka CIL)

  • Language integration (multiple languages generate nearly the same instructions.
  • Platform agnostic code

Common type system (aka CTS)

.NET Core Libs

The .NET Core Runtime (CoreCLR)

This is the base library for .NET Core. It includes the garbage collector, JIT compiler, base .NET types, and many of the low-level classes. The runtime provides the bridge between the .NET Core framework libraries (CoreFX) and the underlying operating systems.

The Framework Libraries (CoreFX)

This is the set of .NET Core foundational libraries and includes classes for collections, file systems, the console, XML, async, and many other base items. These libraries build on CoreCLR and provide the interface points for other frameworks into the runtime. 

.NET Framework

Has CLR and Base Class Library

Setting up project

In .NET Framework, the project was set up using Visual Studio and it's template. 

In .NET Core Microsoft inspired in JavaScript world and created .NET CLI. The you can completly control your project/solution setup.

.NET CLI

 
dotnet new -l
dotnet new console
dotnet build
dotnet run
dotnet watch

Adding package

 
dotnet add package <package name>

project file should now contain

<PackageReference Include="<package name>" Version="<package version>" />

Adding reference

 
dotnet add app/app.csproj reference lib1/lib1.csproj lib2/lib2.csproj

project file should now contain

<ItemGroup>
  <ProjectReference Include="app.csproj" />
  <ProjectReference Include="..\lib2\lib2.csproj" />
  <ProjectReference Include="..\lib1\lib1.csproj" />
</ItemGroup>

How some project file looks like

 
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
  </ItemGroup>
</Project>

Solution Structure

In .NET FW everything is solution-centric. Solution is in root folder and projects are directly in subfolders. 

When generated with Docker build there is additional folder for Docker.

Files had to be added to project file. This leads to conflicts in merges.

When .NET Core came the need to add files to project was dropped. Only references, dependencies and build configs remain. This leads to less conflicts.

Differences how to do folder structure

Since .NET Core is not solution-centric. You do your repo like in other languages by creating src folder.

Into src you put your projects. 

In root you have also solution file, docker file, build files and others.

This leads to much cleaner structure.

We have System.Runtime.Intrinsics

Only in Core we have this namespace. It can use directly specific CPU instructions for heavu workloads.

Does your CPU supports AVX or AES on hardware level? Yes? Fine, let's use it.

What version of .NET choose

Use .NET Core for your server application when:

  • You have cross-platform needs.
  • You are targeting microservices.
  • You are using Docker containers.
  • You need high-performance and scalable systems.
  • You need side-by-side .NET versions per application.
  • Windows, macOS, and Linux support .NET Core.

Use .NET Framework for your server application when:

  • Your app currently uses .NET Framework (recommendation is to extend instead of migrating).
  • Your app uses third-party .NET libraries or NuGet packages not available for .NET Core.
  • Your app uses .NET technologies that aren't available for .NET Core.
  • Your app uses a platform that doesn’t support .NET Core.

Now let's take a look on some libraries

ASP.NET MVC

Entity Framework

ASP.NET

IIS Web Server

SimpleInjector / AutoFac / Castle

ASP.NET Core

Entity Framework

ASP.NET Core

self-hosted / Kesterel

Dapper

ASP.NET Core

It is self-hosted. Hosted on one of best performing web servers (build into app)

https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune

 

Dependency injection build in.

 

Much diferent approach to setup and startup of application

Orchard CMS

Version on Core is more performant.

 

Runs on Linux and Mac.

 

Support not only full CMS but also decoupled CMS and headless CMS.

 

Supports GraphQL out of the box.

Windows Presentation Foundation

Well, it is dead.

 

As a replacement check UNO platform.

https://platform.uno

Jupyter Notebooks

This is a tool used by data scientists.

You can quickly build something there.

 

From .NET Core 3 you can have not only Python kernel but also C# and F#.

 

https://www.hanselman.com/blog/AnnouncingNETJupyterNotebooks.aspx

ElectronNET

.NET Core only. The way how to build destop app using ASP.NET Core.

Blazor

Future how to build apps. Build on WASM. 

Now we have also Blazor Bindings for Xamarin. 

That's it!

Made with Slides.com