Big changes demand big changes

Spintr is getting close to finishing up the transitioning from .NET Framework 4.x to Microsoft’s new platform for software development. It’s been a huge amount of work that has taught us a whole lot that might be good to know about.

Microsoft started talking about a new version of .NET that was supposed to be faster, better, platform independent and with open source already in 2014. The version was called vNext as they hadn’t decided on how they wanted the versions. The first version was launched in 2016 and .NET Foundation has ever since continued to develop .NET Core.

At the start of this year, we decided the project was sufficiently mature and that we would take the next step forward to the new framework. We started with Microsoft’s preparing tool that analysed our code in order to give us an estimate of the job we had ahead of us. We’ve continued working with the transition simultaneously with the upgrading and integrating of Office 365 ever since. Here comes a description of some of the findings we did during this process that we think will be helpful for other developers and others in IT.

.NET Core is platform independent

As beforementioned, .NET Core is platform independent and can be built, tested and operated in macOS or Linux as well as Windows servers. The implications for .NET Foundation was that they had to rewrite a lot from the beginning, but it also meant they could get rid of old codes whose task had been to support actions that in some cases were as old as 15 years old.

New web server

Since .NET Core is platform independent, they had to make sure the web applications could be operated also without Microsoft IIS. A platform independent web server was built – one that didn’t have to be compatible with years old technology, and one that could be built to optimise the kind of work that the ASP .NET projects do. The new web server is called Kestrel, and it’s up to 20 times faster than IIS.

Better for developers

A lot has been rearranged in order to make .NET Core more developer friendly. Some parts, such as how you configurate logging and general settings has been changed in order to make it a lot easier. They’ve also made sure to make it easier for developers to write their own implementations in larger parts of the eco-system.

Big changes demand big changes

Because of all the changes that have been made, parts of existing codes can no longer be used – something that Spintr has had to experience and handle. System Drawing, the name area that handled code-interaction with pictures, has disappeared and a new voluntary project has emerged to take its place, and certain IO supports (Input/Output) have changed names, place and function.

Extras such as Json.NET has changed function and now forces a so called “camelCasing” to be the standard. The popular ORM-tool EntityFramework has in its .NET Core version changed how database-questions are generated, which means that you’ll have to review every question you’ve done via EntityFramework.

The old system with HttpModules and HttpHandlers have been changed and swapped with a new “middleware”-system similar to what you can find in other web-frameworks. They’re easier to work with, but they introduce new challenges as the sequence is now important. If for example you want to insert an ApplicationInsights-middleware, you have to make sure it’s the first middleware that’s driven, otherwise you might lose important information.

Continuous development

.NET Core and Microsoft are continuously working on making .NET Core faster, better and nicer for developers – and it shows. There’s always something new to read about for anyone who follows .NET Core and adjoining projects; from new benchmarks to new tools that help us developers build better applications for our customers.

Because the project is made in OpenSource, everyone can send in bugs, tips for improvements and any other suggestions. That way .NET can move faster forward than previously possible.

Future learnings

From our experiences during our journey with .NET Core, this is what I think is good to keep in mind should you consider the same journey:

  • Do an analytical test on your codes before start and decide how you’ll replace the ones no longer available- it’ll save you time in the long run.
  • Use the opportunity to swap the old with what’s new in .NET Core (such as logging).
  • Even though the project develops seemingly fine and all tests are good, you might run into problems when you hit production. Make sure to engage your QA-team and test thoroughly.

.NET Core and Spintr

As before mentioned, Spintr is just about to finish the transition to .NET Core, and we’ve seen great improvements in our internal tests. It’s pretty daunting because we’ve literally taken out the skeleton of the product, but we’ve been very thoroughly in testing and making sure the changes won’t change the behaviour of our product. We’re now aiming to launch the changes in the sky in April to our customers, and we hope they’ll experience an even faster and more reliable Spintr.