Andy Butland

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Update 29th March, 2021, 18:15 - I've updated this article to discuss how to properly handle the NuGet distribution of content files, which was a problem I was having and discussed in the first publication of this post. Thanks to Bjarke and Warren for sorting me out! Installing the Package This post should be the last one, as - good news - the package works now in V9, and you can try it out if you like, by doing the following. Create an Umbraco project based on the alpha 4 template . Install Umbraco and check the back-office is up and running. Install the package - eit

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Dependency Registration and other Start-up Tasks At this point I've gone some package functionality that compiles and some unit tests that pass, but there's no way to actually run it yet and it won't work if somehow installed into an Umbraco V9 website. In order for that to happen I need to ensure that the services I've created, which are being constructor injected into various classes that need them, are registered with the IoC container. I've also got to make sure the package migration will run and some custom routes are in place for the controllers that the back-

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Package Distribution There are at least a couple of ways to distribute Umbraco packages. The original - and still supported in Umbraco V9 - is to create a package through the back-office, selecting the files, schema and content that you wish to include - and saving that into zip file packaged according to a custom format. This file can be uploaded to our.umbraco.com , from where it can be downloaded by other users for install on their projects, or discovered and installed via the back-office. The approach that's more common in the .NET space as a whole, is to distribute via NuGet

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Migrating Extension Methods The functionality of the Personalisation Groups package is exposed via some extension methods added to Umbraco's IPublishedElement and UmbracoHelper . For example, given a set of content elements drawn from child nodes, a multi-node tree picker or a nested content property, you can show just the ones relevant to the user using something like this: @foreach (var post in Model.Content.Children .Where(x => x.ShowToVisitor())) { <h2>@post.Name</h2> } Umbraco's rendering APIs haven't changed a great deal, so not much modifi

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Adding a Tests Project Having ported a reasonable amount of the functionality from the Personalisation Groups package over to a version for Umbraco V9 running on .NET Core, I've created a tests project and migrated over most of the existing unit tests. There wasn't too much required here that wasn't fixed with some find and replace. I created an NUnit test project, which aligns with what Umbraco use in the CMS core, but that isn't necessary and you can use what you prefer. I'd previously used MSTest which still available in .NET Core. The only changes needed wer

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Amends After Review I received some useful pointers on what I've done so far in this package migration from Bjarke Berg, who heads up the .NET Core transition project at Umbraco. All of which I've now applied. The general theme from all of them is that there are more places where I could lean on existing functionality of Umbraco to help out. Umbraco Dependency The first step taken after creating a new project for the package was to reference the Umbraco NuGet package from the nightlies feed. He pointed out that rather than referencing Umbraco.Cms.Core , it would be better

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Migrating Criteria Providers Within the package I'm looking to migrate to Umbraco V9 and .NET Core, Personalisation Groups , there are a number of Criteria classes, used as methods of identifying users for the purpose of personalising their website experience. These are things like day of week, time of day, presence of a querystring, a cookie value etc. Most of these rely on something external to the class in order to retrieve a value from the browsing context in order to match against what's configured in the CMS against the content, in order to decide whether there's a

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up File > New Project Having decided on a new repository for the migration of the Personalisaton Groups package to Umbraco V9 and .NET Core, I started with a brand new solution, containing a single project targetting .NET Standard 2.0. I picked this version mainly just to match the decison made by Umbraco themselves, when updating the class libraries that make up the code for the CMS itself. We can see if there's any reason to change it later. Adding Reference to Umbraco I then added the first external dependency - Umbraco itself. At the time of writing, the release intended fo

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up One Codebase or Two? The first decision I took on migrating Personalisation Groups to Umbraco V9 running on .NET Core was on whether to attempt to maintain a single code-base for the supported versions. A couple of years ago, I wrote an article for Skrift outlining the approach I took when V8 came out, which was to maintain versions for V7 and V8 in the same source code repository and in the same branch. In summary, the approach I took there was to extract, from what was then a V7 package, the common code that had no dependency on Umbraco at all. There turned out to be quite a bit o

Umbraco 9 on .NET Core As a member of the community team working on the transition of the Umbraco CMS to .NET Core, I've been involved in various stages of the development, from the reading the initial architecture plans through to supporting the release of the alpha versions. Now working for Umbraco, with a responsibility for the commercial packages Forms and Deploy, my attention is turning to the update of packages to work with the new version. Umbraco CMS offers a lot out of the box of course, but it really shines when augmented by the imagination and know-how of the community in the form of the many open-source and commercial packages available to extend the platform. As such it's in everyone's interest - HQ, community, package authors and solution implementors - that we can make it easy as possible to migrate packages and to support each other in doing so. Authors of new and existing packages will likely have a mix of experience with .NET Core itself. It's