While doing a major update from CMS 4.62 to CMS 6 R2 I have encountered several of issues, the rest of the interesting challenges you can read about in these posts:
- Shortcut and external link property in EPiServer
- Upgrade an EPiServer CMS 4.61 to 6 is not without bumps
Other important posts to read before this, since it is highly relevant. is the post by Ted about his experiences of doing a similar upgrade. This is particularly interesting if you are running ETF on the site that you are trying to upgrade. In short the the scripts of TinyMCE was not loaded correctly.
What was the issue?
I had completed the upgrade and from a visitors point of view everything seemed to be working. I logged in as an editor and started to browse through pages to check all properties. My first glance made me thing that everything seemed to be okay, but after a closer look I saw that there was no editor for relevant properties.
For example the MainBody, looked like this:
As you can see this has loaded the legacy control, which is actually a control without editor functionality. What I wanted was the new TinyMCE control. From experience and together with my colleague Thomas we started to check the settings.
So we switched to admin-mode and started to look at the standard page to get some clues. We found that the standard page was configured to use this for the MainBody property:
This actually means that the LegacyControl will e run or the “EPiSErver CMS 5 editor”. You could switch the control here to the TinyMCE, but first how do you force the whole site to use the TinyMCE control?
Specific settings of the editors in EPiServer
It is also possible to configure specific settings on both the old control and the the new TinyMCE control. While in the admin-mode go to:
Then scroll down to the XHTML-property:
Now you should be able to see these settings:
Now onto how to remove the legacy control.
How to remove the Legacy Control of XHtml properties in EPiServer
Start with the web.config and look for a tag called: episerver.baseLibrary.
This tag normally contains two classFactories. One of which is to control the Legacy control for the editor.
If you want to get rid of this option of using the legacy, just remove the two <register> tags and you are set to go.
Once this is done, restart the site and browse to the page where you know a xhtml-property exists. When I did this we got an LoaderException all over the screen, see below.
LoaderException – System.Reflection.ReflectionTypeLoadException
This could be caused by many things, but what caught our attention was these three rows:
System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) +0
EPiServer.Data.Dynamic.TypeResolver.ResolveType(Object sender, ResolveEventArgs args) +99
A small note about this: If you get this and you have downloaded files from the Internet, they might be blocked. Then you normally get the Unable to load one or more of the requested types. This can be done by right-clicking on the file, selecting “Advanced” on the General tab. If this is the case select “Unblock”.
Another issue that can cause this is if you have gotten a .zip file from a Mac-machine, then make sure you check that the file is not “encrypted”. It should show up as green in Windows Explorer. Just follow the same procedure as above to unencrypt.
We got the feeling that this have to be related to settings or the loaded system-files. So we proceded our hunt for what was causing this error.
- First we made sure that the loaded EPiServer files were correct and of the right version.
- Made sure that the assembly bindings matched the loaded files (can be found in web.config)
- Made sure that if the site is supposed to run on .Net 4 that the settings matched this. Can be found under the node system.codedom in web.config. Look for the value CompilerVersion.
None of this seemed to give any result for us. Although all of these settings are good to go through, so do them any way!
This was the solution that we found
With some help of JohanO at EPiServer that EPiServers DynamicDataStore contains a TypeResolver that as default tries to resolve types on load. What it does is trying to load “old” types into “new” types (versions). Normally when doing an upgrade you have a legacy of old types, custom properties for example. On upgrade these old properties are put into an assembly called AutogeneratedCustomProperty.dll . This could definitely be one of the factors that is causing this error.
This why one of the rows mentioned above is so interesting or frustrating, you choose: System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) since it is not telling any thing. So to find out what type that is actually causing the error, as Johan suggests, use WinDBG.
Although to get going and get the site up and running again, you can tell the TypeResolver to not run as default. Go back to the web.config and look for the node: <episerver.dataStore>. On the subnode dataStore add the attribute: autoResolveTypes=”false”.
After that you are probably good to go.
Thanks Thomas for good teamwork in finding this solution!