New team Members
Before we dive into the technical progress, I’m happy to welcome two new members to the Unicore team. James Jackson-South and Simone Chiaretta answered our call for applicants and have already made contributions to the project 🙌 You can read more about them, and new members to the other community teams in the The Community Teams Applications 2020/2021 blog post.
The Unicore team is now 6 members strong 💪
- Emma Garland
- Benjamin Carleski
- Andy Butland
- Steve Temple
- James Jackson-South
- Simone Chiaretta
- … and myself as the team steward
A couple of weeks ago we held a virtual introduction and workshop for all the community teams, which was very productive.
Now, let’s have a look at the progress of the Unicore project:
Dependency Injection abstractions
In Umbraco 8, we had our own abstractions for managing the Dependency Injection (DI) container. One of the benefits of the new web framework, ASP.NET Core, is the integrated DI feature. Microsoft ships some common abstractions directly in the framework. We have decided to align our usages of DI with the common abstraction from Microsoft.
There are many benefits of using these new abstractions for users of Umbraco. First of all, they are well known to .NET Core developers. They are simpler than our own abstractions. Lots of DI frameworks implement these abstractions and finally, many NuGet packages have extension methods on these abstractions to ease the setup of their packages.
Personally, I also love that fact that there is a bit less code to maintain in the Umbraco Codebase 🎉
As a simple example of this change look at the difference in how `NotificationsComposer` is implemented in Umbraco 8 vs Unicore:
Basically, you will in the future have access to the `IServiceCollection` in composers. On this interface there are lots of extension methods in different NuGet packages. E.g. ImageSharp.Web.
If you are interested in the discussion that led to this solution, please read this GitHub issue.
Background tasks
Another area of the codebase we have also aligned with .NET Core best practices is the Background tasks.
Background tasks are used for all sorts of things such as scheduled publishing, cleaning of the logs and other tasks. Microsoft now ships a common abstraction that we can implement for handling background tasks.
This abstraction is also a bit simpler than the one we have in Umbraco 8 and project Unicore is more aligned with standard conventions which should make it easier to maintain and, importantly, much easier to learn. Big high five you rock to Andy Butland 🙌
Website rendering
The Alpha release of project Unicore made it possible to use the backoffice (or most of it) but lacked the ability to render content (use razor templates). We are firmly on the path towards enabling website rendering again and we have already migrated a lot of things.
Some of the support classes that have been migrated are Umbraco’s custom view engines, enabling profiling and finding views/templates in custom Umbraco locations. Also, lots of extension methods have been migrated such as HtmlHelper class.
We have also managed to migrate the remaining controllers and views that are related to website rendering.
We are still missing the migration of the routing pipeline but once that is done you should be able to render content in an Umbraco site running on .NET Core. Once this is possible we expect to ship an Alpha 3 so you can get your hands on it and help us test it out. We’re targeting Mid-January for this release.
Other big areas remaining
We are not done with project Unicore when website rendering works. We still have a few big areas left that need to be migrated.
- Members
The first is Members that needs to be migrated from MembershipProviders into ASP.NET Core Identity. The work towards this has started, and Rock Solid Knowledge, spearheaded by Unicore team member Emma Garland, has offered to help us with this migrating as they did with the migration of Users from ASP.NET Identity to ASP.NET Core Identity. HIGH FIVE YOU ROCK 🙌 - Examine
Another area that still needs migration is Examine. Examine is already divided into two packages. Abstractions, which is done, and then a Lucene.Net implementation of Examine that needs to be updated to Lucene.NET 4.8 which is .NET Standard and therefore compatible with .NET Core. - Package support
The last big area missing is package support. The work has not started, but we are aware of a few challenges. First of all, ASP.NET Core requires us to divide between content root and webroot. So all files that need to be accessible from a browser need to be located separately from the rest of the content. Another challenge is our package installs from backoffice today forces Umbraco to restart. Restarts are not really a thing in .NET Core, so Umbraco needs to depend on the functionality from the web server (e.g. IIS) to boot an application on request.
Community contributions
During Hacktoberfest, we had some fantastic contributions to the Unicore project. Most of the DI changes happened and since then more clean up has been suggested regarding the internal use of Composers and suggestions for getting rid of all the static events in Umbraco. Huge thanks to James South, Paul Johnson and Lars-Erik Aabech for their contributions.
Another interesting contribution was made by Anthony Dang. He found an old TODO in the codebase and fixed it. Together with the fix, he added lots of unit tests to ensure the new implementation worked as expected. This is a perfect example of how to contribute if none of the open up-for-grabs tasks appeal to you. H5YR, Anthony!
Some other community contributions, which are just started or are still in progress are related to the file system abstractions and health checks. Maybe you have already seen a tweet about the work on a new file system abstraction? We aim for having a new abstraction that is simpler and not that closely related to physical filesystems. Regarding health checks we plan to remove the functionality to fix the issues programmatically due to technical challenges with the way configuration works in .NET Core. Instead, we point to documentation on how to resolve issues manually.
Summary
To summarize, things are going according to plan and we still expect to ship a beta at the end of Q1 2021. Lots of progress has been made since the last update, but not many too visible changes.
We don’t have an exact date yet, but we plan to ship an Alpha 3 in January when we can render the content on the website part of Umbraco as this is a tangible feature. We see this as a major milestone, and that’s the reason for adding an additional Alpha release. I will make sure to give an update here on the Umbraco blog once Alpha 3 is out.
The final thing to say is as always, a big thank you for all the involvement and contributions. HIGH FIVE YOU ROCK 🙌.