Upgrading Jobs Module
Hello,
I put the Jobs module in a test website and it works perfectly.
I understood that a DocumentLibrary is created at the Module's installation.
I added several fields to the module : extra fields in the form resulting into extra fields in the library.
When Jobs.dll is compiled, I just drop it in the /bin directory and do no further action.
I get an error when i submit the form, because the extra fields I added aren't in the document library (so the Item.SetValue() on that field fails).
To make things work, I need to :
- Delete the library
- uninstall the job
- reinstall the job (that creates the library, with the fields I added)
Is there a simpler way to do this? Maybe using the "Upgrade" method?
If I'm correct, then, what triggers the "Upgrade" method? is it just dropping a DLL with a different version number?
Could I get a sample on how to use the upgrade method and what actions triggers it?
Thank you
F.
I don't have a solution, but I do have the same question. Can the Upgrade method be used to make changes to a custom module? If not, what kinds of operations are appropriate for the Upgrade method?
Hi,
The purpose of the Upgrade method is, let's say that you have some custom logic in Install. Later you release a new version of your module, and in the new version you add more custom logic. In this case, the Upgrade method should hold the new custom logic in order to introduce it to the module when upgrading. The Upgrade method is triggered right after the upgrade of the database scheme. In this method you can do anything you usually do in Install.
Here is an example of how the Upgrade method can be used,
/// <summary>/// Upgrades this module from the specified version./// </summary>/// <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>public override void Upgrade(SiteInitializer initializer, Version upgradeFrom) if (upgradeFrom.Build < 1100) var suppress = initializer.PageManager.Provider.SuppressSecurityChecks; initializer.PageManager.Provider.SuppressSecurityChecks = true; var groupPage = initializer.PageManager.GetPageNode(ContentModule.ContentPageGroupId); if (groupPage != null) groupPage.Title = Res.Get(ResourceClassId, "PageGroupNodeTitle"); groupPage.UrlName = Res.Get(ResourceClassId, "PageGroupNodeTitle"); groupPage.Description = Res.Get(ResourceClassId, "PageGroupNodeDescription"); var landingPage = initializer.PageManager.GetPageNode(ContentModule.HomePageId); if (landingPage != null) landingPage.UrlName = Res.Get<PageResources>().ContentBlocksUrlName; landingPage.Page.HtmlTitle = Res.Get<PageResources>().ContentBlocksHtmlTitle; landingPage.Description = Res.Get<PageResources>().ContentBlocksDescription; initializer.PageManager.Provider.SuppressSecurityChecks = suppress; Thank you for your help.
With this new information, i think i know what to do.
F.
how does the Upgrade method gets called? at which stage.
Hello,
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.
Hi Slavo,
While I can see this working if the module is in an assembly seperate from the web application, how does the "upgrade if the version number changes" work if the module is in the same assembly as the sitefinity web site? I'm having problem with OpenAccess not updating mapping changes. In my case the module is in the same project as the SF site.
--Steve
Hi,
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:
[assembly: AssemblyVersion("1.0.0.0")][assembly: AssemblyVersion("1.0.*")]Hi Slavo,
I get that, but the assembly vesion matches the release version numbering. So what happens if I change the AssemblyVersion property to auto-increment? Will it break how the SF Project Manager determines whether an upgrade is newer that my (auto-incremented) installed version?
--Steve
Hi,
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.