Upgrading to CMS 6 R2 (or: Always ALWAYS do a test upgrade)

Many version upgrades of EPiServer have been of the “no recompile needed” type. Using assembly redirects your compiled application generally continues to work without problems. So you might get the idea to just upgrade the production site. Don’t.

Breaking changes

Well, I did. Upgraded the production site, that is. Not a real production site for a client though, I would never do that. Really. Don’t. This was just my private playground site and I thought “What the hell I want to try out Visitor Groups!”.

The few breaking changes generally introduced in CMS (after the EPiServer 4 to CMS 5 “purge” which was a good thing) are documented in the release notes or similar. But remember that these generally cover the vanilla use of the API, there could still be other changes impacting your specific solution. So always always test-upgrade a copy of the production environment and test it thoroughly before upgrading the production environment.

StructureMap

In the project in question I use StructureMap for dependency injection. I would guess most StructureMap users rely mostly on scanning using the “for IFoo use Foo” default convention and stick only the anomalies in explicit setup. And even if explicit cases are configured it’s mostly of the “for IFoo use DerivedFoo” type, not specific instances or constructors (the latter might even be considered wrong if there is no special need?).

In this case, a change that would generally not be breaking in the vanilla case would be when using DI (or at least StructureMap with this typical setup). StructureMap looks for the greediest constructor, which means that if a greedier/fatter constructor (that is, one that takes more parameters) is added in a new version of a dependency (EPiServer in this case) it will use that constructor instead. But what if that constructor takes an instance of a class/interface that StructureMap isn’t configured for? Boom!

And why thorough testing is so important in this case is that the “boom” won’t happen until an instance of the class with the new fatter constructor is requested. So you won’t see it on compile. You won’t see it while surfing the site (until you hit the point where it’s used). This particular error could have been caught by an automated test that just requested instances of the different classes/interfaces used, if that could be done without mocking the impacted classes because they use external resources etc.

Fixing my particular issue

Well, all of this was basically a very TLDR way of saying that if you use StructureMap and you inject instances of EPiServer.Core.IPageObjectRepository, and you use the EPiServer.DataAccess.DdsPageObjectRepository for this, it has had a constructor added in CMS 6 R2. The new constructor takes a EPiServer.Data.Dynamic.DynamicDataStoreFactory. So if you have no configuration for that, either add it (the parameterless constructor uses DynamicDataFactoryStore.Instance) or change your configuration to use the parameterless constructor:

For<EPiServer.Core.IPageObjectRepository>()
                .Use(() => new EPiServer.DataAccess.DdsPageObjectRepository());