Migrating our CMS to .NET Core – Cofoundry 0.2 Released

Cofoundry | Thursday, February 22, 2018

It's been almost a year since our first preview release of Cofoundry, and although it's taken us a little while to get here, I'm pleased announce that we've completed our .NET Core migration. Today we've released Cofoundry 0.2, a release that targets .NET Standard 2.0 and runs on both .NET Core 2.0 and .NET Framework 4.6.1.

Notes on a .NET Core migration

We've been keenly watching the development of .NET Core closely since it's first announcement a few years back and knew immediately that it was something we wanted to embrace. There are many technical reasons why we wanted to be working with .NET Core, but cross-platform development really stood out as a big win to reduce the friction for our mac-based front-end developers.

However, migrating an application framework like ours to .NET Core is a significant undertaking. Cofoundry has broad scope, covering many aspects of developing a website either through the framework itself or via plugins.

Preparing for change

We felt a sensible approach was not to rush in and re-write everything, but to migrate in stages, refactoring our codebase first in preparation as details emerged on the new framework. Much of this happened during the initial work to open source Cofoundry and included tasks such as factoring out functionality that could differ between target platforms into plugin packages (e.g. mail, image resizing) and moving to async where it was possible to do so.

ASP.NET Core 1.1 running on the full .NET Framework

The next step was to migrate to ASP.NET Core 1.1 running on the full .NET Framework, which meant that we weren't under pressure to migrate all our dependencies at once. This was important because at the time some dependencies didn't have a clear alternative and some such as Entity Framework Core were not feature-complete enough to migrate to.

Even running on the full framework, the migration to ASP.NET Core has been the greatest challenge. The changes we had to adapt to are significant, especially under the covers where we've had to do significant work to enable our modular framework. Other areas such as application startup and view helpers have been more of an issue of how they should work rather than posing a major technical challenge.

.NET Standard 1.6

Once we were up and running on ASP.NET Core, the process of migrating to .NET Standard was more straightforward. The most troublesome part was migrating from EF6 to EF Core, which was still missing key features such as GroupBy translation and was generally a little buggy. We considered changing our ORM solution but in the end it was going to be quicker to work around the issues, and EF Core will undoubtedly improve over the next few releases.

.NET Standard 2.0

The final step has been to upgrade to .NET Standard 2.0 and ASP.NET Core 2.0. One of the more significant changes for us here were the breaking changes to authentication.

Additionally we've worked to update samples, write new documentation and update our CI builds to work with .NET Core.

What else is in the release

Given the significant changes in this release, we've decided to take the opportunity to make other breaking changes that might otherwise be difficult to do further down the line, these include:

Evaluating the terms we use and aligning them better with terms that the majority of other CMS products use e.g. "Page Module" is now "Page Block" and "Page Section" is now "Page Region".

Removing unnecessary dependencies such as AutoMapper, OData and Conditions to remove the potential for conflicts.

Renaming types to increase consistency across the framework

Inevitably there are many breaking changes in this release, but aside from the obvious differences in working with ASP.NET Core, development with Cofoundry is remarkably similar. We urge anyone looking to get started to try out the newly updated sample projects.

We're not expecting many people to have developed fully fledged sites using the 0.1 preview, but if you have, and are having trouble migrating, do get in touch and we'll help you out.

What's next

With such a large amount of infrastructural development behind us, we're keen to get back to feature development. We're yet to plan out exactly what will go into next release but you can check our GitHub milestones to get an idea of what might be included.

A little bit further down the line we're going to re-visit upgrading our admin panel framework. Currently this uses Angular 1.6 and has been developed with expensibility in mind, however it isn't as easy to develop with as we'd like and we're keen to improve the experience before we start documenting it and pushing it as a feature. We've already started experimenting with migrating to Angular 5 and it's likely that we'll continue down that road.