/// Upgrades this module from the specified version.
/// <param name="initializer">The Site Initializer. A helper class for installing Sitefinity modules.</param>
/// <param name="upgradeFrom">The version this module us upgrading from.</param>
Upgrade(SiteInitializer initializer, Version upgradeFrom)
(upgradeFrom.Build < 1100)
var suppress = initializer.PageManager.Provider.SuppressSecurityChecks;
var groupPage = initializer.PageManager.GetPageNode(ContentModule.ContentPageGroupId);
groupPage.Title = Res.Get(ResourceClassId,
groupPage.UrlName = Res.Get(ResourceClassId,
groupPage.Description = Res.Get(ResourceClassId,
var landingPage = initializer.PageManager.GetPageNode(ContentModule.HomePageId);
landingPage.UrlName = Res.Get<PageResources>().ContentBlocksUrlName;
landingPage.Page.HtmlTitle = Res.Get<PageResources>().ContentBlocksHtmlTitle;
landingPage.Description = Res.Get<PageResources>().ContentBlocksDescription;
initializer.PageManager.Provider.SuppressSecurityChecks = suppress;
The upgrade method for your module is called on application start, every time, when the current version of the module is different than the one in the database.
The actual unit which gets upgraded is not the module, but the data provider. Sitefinity keeps the current versions of all registered data providers for all modules in the DB. When you do an upgrade, you actually change the assemblies with new ones, which have a more recent version.
When the application is initialized, Sitefinity goes through all data providers, and compares the version in the DB with the current assembly version. If they differ, and the provider belongs to a custom module, your upgrade method gets called.
The upgrade method gets a System.Version argument. It contains information about the old version - major, minor and build number. Since you are the developer of the custom module, you know the current version already, so you have enough information to perform the needed changes to the persistent classes or database.
Sometimes, you don't need to do anything, as OpenAccess takes care automatically. Adding a new property to the persistent class is such a case. Other times, you need to manually change the schema (i.e. when changing a property type). It all depends on the changes in your model between the two versions.
You SF site is also built into an assembly, unless you've opened it as a web site (and not a web application project). The assembly has its own version, but by default the version does not change. Maybe this is the reason OpenAccess does not update the mappings.
You can control how the assembly version changes by editing the AssemblyInfo.cs file in your project (also available in the SF site web project). The default code looks like this:
It will not break anything. What the project manager does when you upgrade is replace the old Sitefinity DLLs with the new ones. It will not touch your assembly at all, only the Sitefinity assemblies. Moreover, the version of your module's assembly is not bound to the version of Sitefinity, they can have arbitrary versions, as long as the references can be resolved.
What CAN happen is that your module's references to Sitefinity assemblies can break. This will only happen if you've included a reference to the specific version, which we don't recommend.