Stay updated

Road test of .Net 5 innovations
Welcome .NET 5
Wednesday, December 09, 2020

For about three months I joined the Blexin team and I was lucky enough to participate in a project in the startup phase. The Customer asks us to rewrite a WPF application created to work offline using data synchronization mechanisms with a Web version and then access the data in real time.

The request came in conjunction with the release of . NET 5 and we decided to deepen the innovations introduced on the field in this project, which I thought could be useful to those who are thinking of a similar migration.

Let’s see together the main news that Microsoft presented on November 10th at the . NET Conference and how the framework is evolving.

Microsoft has always had the idea of making it possible to write reusable code (libraries) on multiple platforms (Web, Mobile, Desktop, Iot, Cloud and so on) and despite . NET 5 is a decisive step in that direction, the current roadmap tells us that it will be . NET 6 to complete the process.

The history of the last 20 years is scattered with not always successful attempts (read: Silverlight) of convergence between heterogeneous environments. Let’s review these attempts together because we must learn from history and mistakes.

In December 2006, the surprise for all Windows Form developers at the announcement of the beta version of Silverlight was great: a plugin to be installed on the browser that allowed to “run” code C# within the browser itself.

Various versions have been released over time, increasing the functionality and the percentage of code that, potentially, you could share. I experimented with a couple of projects with version 3.0 in 2010, and I have to say that there were all the premises for a good result, with lots of advanced graphics editors and native MVVM pattern. Unfortunately, the dependence on an external plugin was not welcomed by the market that did not capture its potential. Today Silverlight has arrived at version 5, and the support will end in October 2021.

Then arrived Xamarin, an application of the Mono framework, the porting of . NET Framework to Linux, Android, Mac OS, and IOS. I remember my joy when, during the Build conference in 2016, there was the announcement of the acquisition of Xamarin by Microsoft and availability, starting with Visual Studio 2017, of the whole Xamarin package for cross-platform development for IOS, Android, and Universal Windows Platform mobile operating systems. Consider that at the time, Microsoft still considered itself a competitor for Mobile operating systems and had just released Windows 10 Mobile. The mechanism that introduced Xamarin to share the code between the various environments was twofold: Shared Project and Portable Class Library. The difference between the two implementations consisted in the knowledge of the deployment environment and its primitives: in the Shared Project, it was possible to invoke exclusive methods of the reference platform, while in the Portable Class Library, there was a subset of primitives, common to all platforms.

The Portable Class Library was the seed that gave life to the project. Net Standard: a common feature contract to which the various implementations of the framework (.net Framework 4.x, .Net Core, Mono) are subscribed. When compiling, the appropriate implementation is referenced for the environment you are compiling for.

A great job has been dedicated to coreFx and Mono runtimes, introducing support for Windows Arm64 and beyond. Aware of the importance of containerization, a significant commitment of Microsoft in this direction has led to the reduction of the size of the docker images.

With the arrival of .NET 5, the libraries now have an implementation of all the functionalities on each runtime, while the UI App unification project of having a single project that is “typed” for the deploy, as with libraries, is postponed to next year. For those wishing to start taking a look, here you will find the link to the MAUI project repository.

But let’s see how all these innovations help us in the job and in the refactoring that we are facing.

Let’s start with data storage: Entity Framework in both full framework and Core version is supported in . NET 5. This means that even slightly outdated libraries are reusable, even if we didn’t mean to do their refactoring, and they are written using Entity Framework 6.x. But EF Core 5, with the total rewriting of the entire engine, has a significant impact on performance, which cannot be overlooked in the choice.

Among the most important innovations introduced there are surely the many-to-many mapping of the tables (at last!) and the support to the logging configurable with the Logto method present in the class Dbcontextoptionsbuilder.

The framework . NET 5 supports all the new features introduced by the C# 9 and F# 5 languages. For details, if you missed it, I recommend the article by Francesco.

For the services world, the most significant innovations introduced in ASP.NET Core 5 are the support to HTTP/2 and GRPC, which fill the gap left by the absence of WCF, which leaves us permanently.

As for the world’s front-end Web server-side, the support for record types in Razor and native support for Swagger are certainly the most interesting aspects. The use of records in model binding certainly has a positive impact on memory and therefore also on performance, while those like me who find in Swagger an indispensable tool find this library natively in their projects.

The absolute protagonist of this release is definitely Blazor, which reaches its maturity with the novelties introduced by . NET 5 (here you can find an introductory guide by our CEO/CTO Michele Aponte), with increased performance, reduction of the payload of the first access and a series of features such as:

  • Inputfile, Inputradio and Inputradiogroup Native Components;
  • CSS Isolation, which allows you to integrate third-party components by simply using nuget without having to add additional references within the project;
  • JS Isolation, to isolate Javascript modules;
  • Improved debugging experience, both in visual studio and in visual studio code;
  • Browser update after changes; this feature is not supported if debugging is enabled;
  • Virtualize component, which is responsible for rendering items in a list of objects only if they are visible within the visible area of the page.

Some significant innovations have also been introduced in the Command Language Interface (CLI) of . NET Core. The watch option has also been extended for testing, providing a “Matrix Style” experience of live Tests. For each change of code on the test project or on the projects on which it depends the build and all the tests will then be executed.

A goal of the . NET Core project is to have the possibility not to install additional software on the target servers. For this reason, the single file publishing function has been introduced, where all the dependencies of the BCL necessary for the project are incorporated.

Let’s see together the possibilities that this option makes available to us.

dotnet publish -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true /p:PublishTrimmed=true
  • PublishSingleFile produces an executable containing all the project resources (images, resources, etc.), in addition to the .exe file (in this case, we are compiling for windows), there are also the BCL DLLs necessary for the executable. This means that we can copy the output folder to the target machine and we can run it without worrying about having to install the runtime.
  • IncludeNativeLibrariesForSelfExtract the BCL DLLs necessary for the executable are incorporated into the .exe file itself.
  • PublishTrimmed is a slimming cure for BCL DLLs: during the build phase, the compiler takes only the methods called by our code; obviously, if our project uses reflection, it is not recommended the use of this parameter as the compiler cannot identify the methods dynamically called.

What there’s not and will not be

In . NET 5 as well as in . NET Core 3.1 there will be no ASP.NET Web Form, Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF). In some cases, we have an alternative, such as Blazor and grpc, while there are open-source projects, not officially supported by Microsoft, both WF (CoreWF) and WCF (CoreWCF).


The news. NET 5 introduced with all the connected frameworks (ASP.NET, Entity Framework, Blazor) and C# 9, can make the developer’s work easier and faster, with new possibilities to explore. The work on performance places the ecosystem among the most performing on the market, and in a world that goes from a few large machines to many small units that collaborate, this aspect certainly has a fundamental role.

I hope I have at least intrigued you to give a chance to this new release: if you are considering to migrate your projects, I would say that this a good moment to do it!

See you in the next article