Experiences from upgrading to EPiServer CMS 6 R2

Upgrade to EPiServer CMS 6 R2, step by step

This probably goes without saying, but make sure you have a proper file and database backup before performing an upgrade. :) The following describes the experience I had during an upgrade from EPiServer CMS 6 R1 to EPiServer CMS 6 R2.

The website was…

• running EPiServer CMS 6 R1
• using ETF 1.1
• hosted under .NET 3.5 in IIS

Started EPiServer Deployment Center

First I started Deployment Center and selected Upgrade site with SQL Server database.

Next I selected a site I had running on IIS that I wanted to upgrade:

Note: This post is actually based on the upgrade of another site, not Public Templates. :)

Could not find a matching <site> node

As soon as I clicked Run I was faced with an exception saying:
”System.ApplicationException: The web.config file for this site does not appear to match the EPiServer schema - could not find a matching <site> node”

This was caused by us having removed the XML namespace from the <episerver> element when using XML config transformations for configuration files.

So, we simply re-inserted the xmlns attribute:

Access to the path [filepath] is denied

After having re-added the XML namespace I got a bit further, but then I ran into the following exception saying “Error – Access to the path ‘[filepath]’ is denied.”

This was because of our TFS source control which causes all non-checked out files to be read-only (doh!). So, I simply checked out the entire project (which I should have done in the first place) and re-ran the update.

Unrecognized configuration section system.web.extensions

After having checked out the entire project, thus making all files writable, I ran into an exception saying “Error – Unrecognized configuration section system.web.extensions [web.config file path]”.

Looking at the exception details I saw that it had something to do with the Upgrade XForm Names script.

Honestly, I’m not sure what caused the script to fail, but since the <system.web.extensions> element contained nothing more than some JSON serialization settings, I decided to comment it out for the update:

The weird thing was, after the update failed the site was no longer visible in Deployment Center. I had to check the Show All Sites option to be able to retry the update.

Update completed without confirmation

After commenting out the <system.web.extensions> element I was able to complete the update. However, for some reason Deployment Center wouldn’t give me any reassuring confirmation, it simply showed a full progress bar and then – nothing more. :)

Upgraded the site’s EPiServer assemblies

We didn’t use NuGet for this site (we haven’t gone over to using NuGet for EPiServer sites yet). Instead we keep a source-controlled “Libraries” folder where we store external assemblies and reference them from there (remember the bin folder should never be source-controlled). So, before re-compiling our site I copied the updated EPiServer CMS 6 R2 binaries from the bin folder to the site’s “Libraries” folder:

Updated assembly references

To ensure we’re referencing the correct EPiServer assembly versions (actually, whichever versions reside in our “Libraries” folder) we set the Specific Version property of the EPiServer references to False:

‘InitializableModuleAttribute’ is not an attribute class

After having upgraded the site’s EPiServer binaries I tried re-compiling the project. However, it failed with an error saying “'EPiServer.Framework.InitializableModuleAttribute' is not an attribute class” (and the same for ModuleDependencyAttribute):

It seemed this was because the original .NET System.ComponentModel.Composition assembly was referenced, instead of the version being shipped with EPiServer. I simply copied the version located in the EPiServer Framework install folder:

After that everything compiled just fine!

Cast exceptions when the EPiServer site starts up

Although the site compiled I ran into the following exception when trying to browse to the site:
Unable to cast object of type 'EPiServer.Core.PageData' to type 'TemplateFoundation.PageTypes.RssPageBase'

Clearly this exception was related to EPiServer Template Foundation, further evident in the stack trace:

Actually, this led me to a bug in ETF which has now been fixed. :) If your site uses ETF I recommend updating to the latest version before performing the upgrade.

TinyMCE not loading in Firefox or Chrome

Next I noted that TinyMCE wouldn’t load properly in Firefox or Chrome (worked fine in IE, though). It was just as if the TinyMCE initialization script wasn’t executed:

Using Fiddler I noticed two 404 exceptions relating to TinyMCE:

I recognized the names from the two TinyMCE plugins in ETF that allow editors to include script and iframe tags in the editor. As it turns out, TinyMCE plugins require a script file named after the plugin. When such a file doesn’t exist, it seems the 404 breaks the TinyMCE initialization.

So, I added an empty file handler to ETF which can be used to avoid these 404:s without having to add script files to the EPiServer TinyMCE folder:

<location path="util/editor/tinymce/plugins">
  <system.webServer>
    <handlers>
      <add name="AllowIframeElementPluginScriptFile" path="/util/editor/tinymce/plugins/AllowIframeElementPlugin/editor_plugin.js" verb="GET" type="TemplateFoundation.Handlers.EmptyFileHandler, TemplateFoundation" />
      <add name="AllowScriptElementPluginScriptFile" path="/util/editor/tinymce/plugins/AllowScriptElementPlugin/editor_plugin.js" verb="GET" type="TemplateFoundation.Handlers.EmptyFileHandler, TemplateFoundation" />
    </handlers>
  </system.webServer>
</location>

Now, after reloading, TinyMCE initializes properly: