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.