First, let’s talk about ASP.NET Core - the web framework of .NET Core. This is actually the part that has changed the most compared to the current version of Umbraco, that uses ASP.NET.
The good thing for Umbraco customers is that the most changed parts are actually handled by Umbraco. These changes are mainly the request pipeline, HttpContext, Configuration and the fact that MVC and WebApi are now combined into a single framework - MVC.
The benefit of using ASP.NET Core compared to ASP.NET is mainly new features and testability.
Luckily, ASP.NET Core is not completely different from what we already use. The key part: MVC - Models, Views and Controllers are highly recognisable.
What’s changed so far
So far, the changes made to the code base are mostly to make the internal libraries compatible with .NET Core.
Let’s start by taking a look at the architecture:
All assemblies are today .NET Framework 4.8. To move them into .NET Standard, we need to remove all third-party dependencies that are not compatible. The biggest issue here is the usage of ASP.NET (System.Web) is known in all of the Umbraco assemblies.
To avoid using ASP.NET directly in all of the Umbraco assemblies, we have introduced a series of abstractions, like IRequestCache, ICookieManager, ISessionManager, IHostingEnvironment, etc.
This method is generally used for all third party dependencies that are not compatible with .NET Standard.
The current status of the architecture is illustrated in the following diagram:
It is quite clear to see that we are currently between two chairs. We now have two executables - the existing one for .NET Framework and a new one for .NET Core. The .NET Core one is entirely new, and currently only returns “Hello world” for each request.
The most exciting part is that most of the libraries are actually compatible with .NET Core now. We still have some functionality left in Umbraco.Web that needs to be migrated, before we can start migrating the actual backoffice functionality, like Models, Controllers and Views.
Also, note that we have separated the Umbraco.Core assembly into two Umbraco.Core and Umbraco.Infrastructure. The difference is that Umbraco.Core cannot have any third-party dependencies, Umbraco.Infrastructure can.
We can’t completely avoid breaking changes, but we do whatever we can to avoid unnecessary breaking changes. By using this strategy, it makes it easier to migrate, and for ourselves, it becomes easier to merge features developed on Umbraco 8 into this version.
You can expect that most constructors of service, repositories and other non-model classes have changed. Even though this is a big breaking change, it should mainly be handled by the dependency injection container.
You also can expect a series of new interfaces that should be used instead of using static classes. So in the future, inject IIOHelper instead of using IOHelper, Inject IHostingEnvironment instead of using the static HostingEnvironment, and so forth.
The last area we expect to introduce breaking changes in is Configuration. The pattern used to get configuration has changed between ASP.NET and ASP.NET Core. Instead of transforming each configuration file, the new way of doing things is to read from multiple sources. E.g.
- Read from a general configuration file
- Read from an environment-specific configuration file
- Read from environment variables
We plan to align with ASP.NET Core as much as possible, and we, therefore, intend to use the new configuration pattern. This will also mean that configuration files in the future will be changed from XML to JSON.
Areas not changed
I know that database changes is a topic that many are worried about. I want to confirm that we don't expect to introduce more changes to the database structure, than what happens between minor versions.
Overall we expect the web API used by backoffice to remain as it is today.
The last part that we expect can be reused in general, are the views. Unless you have a lot of business logic in your views. In that case, you will most likely need to inject the dependencies.
Before we can talk about availability, it makes sense to start with some definitions:
- Backoffice is running on .NET Core
- Not a feature-complete backoffice
- Missing members integrations
- Missing NuGet packages
- Expect still undocumented breaking changes
- Backoffice and Website running on .NET Core
- Expect few, but documented breaking changes
- Package development is expected to begin
- HQ packages available
We expect to have Milestone 1 available in the second half of 2020, and we aim to reach milestone 2 in 2020. Milestone 3 is expected in the first half of 2021. Note that this is based on the current trajectory and can change depending on the amount of community involvement, findings etc.
We still don’t have any information about the final release.
Community involvement is really important for us on this project. Hence we have created a community team at the beginning of the year and they have already done stellar work both in terms of contributions and helping us validate and adjust the approach. You can read more about the team here.
In general, we are doing whatever we can to find tasks that make sense as up-for-grabs. But for the time being, most tasks have tight deadlines.
But we also need your involvement in other parts. Feedback is especially welcome on the request-for-comments we opened. Currently, we are discussing the installation process for Umbraco.
Finally, when we reach the milestones mentioned, we would love to have you try it out. If you find anything that does not work, please let us know by reporting it as an issue on GitHub.