Moving from .NET framework to .Net core

The big news in the evolution of Microsoft .Net is the move towards a unified .Net platform that can support development for every kind of device and every kind of application. At the moment the .Net ecosystem is still somewhat fragmented – we have:

  • .Net Framework 4.8 for general application development (including older technologies such as Windows Forms and Windows Desktop Applications),
  • .Net Core also for general application development (not supporting the older technologies, but including a whole host of other improvements), and
  • Xamarin for cross-platform mobile development.

.Net 5 (due for release in 2020) will be the first unified version of .Net.

Here at IJYI, .Net Framework was originally our main development platform, so we have been following these changes with a great deal of interest. We are incrementally adopting the new versions of .Net Core as they come along, which means that we no longer create .Net Framework projects, and where feasible we have migrated existing framework projects to use .Net Core.

There are many interesting articles out there that give great high-level comparisons of .Net Framework and .Net Core:

In this post I am going to focus on the IJYI experience of moving to .Net Core and talk about some of our observations so far:

  • One of the main claims made for .Net Core is that it is fast, and we can back this up; after migrating IMP, our high-throughput messaging platform, to Core, we saw message processing time and messaging throughput consistently improve by over 100%. This alone is enough for us to justify the move to .Net Core.
  • IJYI works with a whole host of different customers, each with their own hosting requirements. This has meant that historically we have needed to deploy to both Windows and Linux, as well as Azure and AWS PAAS and IAAS. .Net Core is perfectly set up to allow us to seamlessly deploy code that works in all of these scenarios. In addition, adoption of .Net Core by the cloud providers is already better than it was for .Net Framework; for example, AWS Lambda didn’t allow deployment of .Net Framework applications, but it does allow .Net Core applications. As a company, this has removed barriers for us by opening up the range of customers that we can work with.
  • Containers and Microservices are huge topics in their own right, but worth mentioning here with regards to .Net Core. We are moving more and more towards container-based deployment because we have seen that it offers many benefits, such as the streamlining of our development and release pipelines. .Net Core works much better than .Net Framework with containers, as it is lightweight and modular (it only includes the .Net Core libraries that are actually being used), therefore container images are smaller. Because .Net Core is cross-platform, we also have the choice of Linux or Windows images. Within a micro services architecture, services are required to start and stop quickly and to have small footprints; the combination of container and .Net Core lends itself well to implementing microservices.
  • The .Net Core code base has been open source from its inception, unlike .Net Framework; this should mean that bugs and security vulnerabilities are addressed more quickly than they have been in previous, closed-source versions. This in turn gives us confidence that our applications are as reliable and secure as they can be. Being able to see the source means that we can gain an understanding of how the platform works, and additionally means that we can follow Microsoft’s best practice when writing our own code. We can even choose to make our own contributions to the future development of .Net.

At the time of writing we are eagerly awaiting .Net Core 3 and the performance improvements it promises. In a future post I will consider:

  • The .Net roadmap
  • The challenges ahead as the new .Net versions are released
  • How IJYI hopes to benefit

Ready to start delivering something amazing?

Related Blogs

About the author