|Number of votes:||6|
As a few already have noticed, we have released pre-release packages of EPiServer CMS 8 in our Nuget feed. Given that EPiServer started to use a continous release process about a year ago and is now following semantic versioning, I want to explain a bit more what this actually means. First of all, if you have not already done so, I recommend reading Per Ivanssons article about the continous release process. A major version, according to semantic versioning, means "MAJOR version when you make incompatible API changes". Given that EPiServer has done weekly releases for around a year now, this means that there are not that many changes in EPiServer CMS 8 compared to earlier major versions (and even compared to EPiServer CMS 7.5). There are a few breaking changes but most of these will have no or little impact on most sites. There will be more blog posts and articles about what is new and what has changed in EPiServer CMS 8, but for this blog I'll focus on how a site with add-ons can be upgraded.
As we are focusing on how the add-on upgrade process works, I'll start by installing a new site with the Visual Studio extension. I'm seleting an Alloy MVC site without search to keep it simple. To mimic a site that's been upgraded to a recent version of EPiServer CMS 7.X, I will start with upgrading to the latest packages for EPiServer CMS 7, so I'm upgrading the packages to the latest stable versions which currently is EPiServer CMS 7.x since the 8.x packages are still pre-release. After I've updated the packages I compile the solution and run the "update-epidatabase" command in the package manager console to run the database upgrade scripts. Now the site is up and running with the latest EPiServer 7.x packages.
Since we are focusing on how the add-on process works in this blog, I'll install a few add-ons. As I hope all of you are aware of, we did some quite large improvements regarding how add-ons can be managed in the end of last year (http://world.episerver.com/articles/Items/2-important-improvements-for-managing-addons-in-episerver/). The biggest change was that we introduced support to install and manage add-ons as regular Nuget packages using Visual Studio. To enable this, we converted all add-ons to standard Nuget format. Depending on how you have installed your add-ons, there are two upgrade paths for your add-ons to EPiServer CMS. In this scenario, we'll test both by installing both some add-ons through the UI as well as some through Visual Studio and the EPiServer Nuget feed. I install the Tiny MCE spellchecker and Google Analytics add-ons through the UI and the EPiServer Social and EPiServer Language Manager add-on through Visual Studio. When I start the site I can see the diffrent add-ons and when I look into the modules/_protected folder of my web site I see the following:
Note: We do not recommend that you mix add-ons installed from Visual Studio with add-ons installed through the UI. You can control how add-ons should be managed through configuration that is described in the SDK.
Now we are ready to do the actual upgrade. Given that the EPiServer CMS 8 packages are currently still pre-release, we switch Visual Studio to include pre-release packages and upgrade all packages from the EPiServer Nuget feed.
As with the previous update, I have to compile and run the "update-epidatabase" command in the Package Manager Console. Now lets start the site and see what happens:
It seems like there has been a breaking change that affects at least one of the add-ons. Actually, this is a kind of special case related to pre-release packages. Social Reach was installed as a Nuget package and if we look at the package, it says that it support up to, but not including EPiServer.CMS.Core 8. A pre-release package is actually treated as a very high version of the previous major version and that's why we were able to upgrade the core packages even though we had add-ons installed that does not support EPiServer CMS 8.
Normally, if the add-ons had had newer versions in the EPiServer Nuget feed, these would have been updated when we did the update all. Currently this is not the case. However, there is a new Nuget feed that is actually used by the EPiServer add-on UI in EPiServer CMS 8 that already hold some EPiServer CMS 8 compatible versions of some of the add-ons. The main purpose of this feed is to have a dedicated feed for certified add-ons that the EPiServer UI can use. This also means that the default format of certified add-ons will be the regular Nuget format (the old format is still valid for some time forward if you have custom addons). All packages should also be available in the regular EPiServer Nuget feed at the time of release, but for now, lets add this feed to Visual Studio to be able to upgrade some of the packages (https://nugetaddons.episerver.com/feed/addons.svc/).
Now we can update the add-ons that we installed previously from this feed. As usuall, I recompile after adding the packages and then I start the site again. Woohoo, the site is up and running again:
Now we have the following situation:
But what if we installed Social Reach, or another add-on that are affected by a breaking change and needs to be upgraded, manually? Since these are not part of the Nuget dependency chain in Visual Studio they will not prevent an upgrade but instead, the site will crash after upgrade. There are two ways forward here.
Our understanding is that most developers wants to control the add-ons installed on a site as Nuget packages. This has several advantages, for instance:
Since we know that there are a lot of sites out there where add-ons have been installed through the UI (though they are still probably managed as resources in your source control), we wanted to provide a real easy way to replace existing manually installed add-ons with their Nuget equivivalents. The solution for this is a new powershell command that you can run in the Package Manager Console named "convert-epiaddons". Lets run this on our web site and see what happens:
It seems that the two add-ons that were manually installed were converted to Nuget add-ons. If we check the modules/_protected folder we can now see that the two add-ons are included in the project with the new format. If you compare with what was previously installed you can see that there are less files included compared to the previous manually installed version of the add-on. The reason for this is that add-ons delivered as Nuget packages normally have most of the add-on files placed inside a zip file (if you want to read more about this I recommend Henrik Nyströms blog post). Another thing to be aware of is that any configuration file inside the add-ons, for instance containing settings for the add-ons, are left intact and untouched so you don't have to redefine the settings.
So, what happens if you want to upgrade a site without having to convert the add-ons to Nuget dependencies? This is still possible and we have done some improvements to conver this scenario as well. Let's install another site with the Social Reach add-on installed through the UI and upgrade it to the latest pre-release and then start the site to see what happens:
Even though the site still crashes, we get a detailed error message along with a description on how to disable the add-ons that's failing. We follow this and replace the existing scanAssembly section (I noticed that there is an attribute, forceBinFolderScan="true", that's not part of the error message but from what I understand, we can ignore this). We start the site again and now it works. Under the updates section of the add-ons UI we can now see that there is an update for Social Reach so we update it and then revert the configuration changes back so that the Social Reach add-on should be loaded once again. Now the site is working again and the Social Reach module is loaded.
Some interesting details that I learned while testing some upgrades