.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!
.NET Framework vs .NET Core
By Lukáš Grolig
.NET Framework vs .NET Core
- 327