Just as I was wrapping up for a new release and testing the new package with the brand new DNN 5 manifest, I noticed that IUpgradeable.UpgradeModule had not been called in DNN 5. I was puzzled as I had labelled the module as IUpgradeable in the manifest. One of the changes in the DNN 5 manifest is that you have to do this explicitly (it used to be determined by the installer through reflecting the business controller class):
But I thought that’d be the end of it. But no. It turns out you have to tell the installer that you want the upgrade method to be called explicitly (again) in the manifest just under the desktopModule element:
What this bit does is to tell DNN’s internal event processor that you’d like to call UpgradeModule after a restart. It is necessary to invoke the event processor (and this has been used for years) because the asp.net process recycles after the new module dlls have been copied to the bin folder. So any running process would be killed anyway. So now the framework starts again, sees a new queued event and does it. So why do this explicitly instead of implicitly like in the previous installer?
The clue is in the upgradeVersionsList. UpgradeModule has as only argument “version” as string. The idea is that the method is called when that version is being installed. But as DNN caters for multi upgrade scenarios (i.e. when you jump a couple of versions) there needs to be a way to call the method for all the versions in between (currently installed and new version). So how do you do that? In the old days the installer would fire UpgradeModule for every version nr it encountered in the list of SQL script files. This followed the same pattern as the Cleanup files (.txt). The downside to this approach was that if you wanted the installer to pass UpgradeModule (or to do cleanup) you had to add an SQL script file. You wouldn’t be the first to distribute your module with an empty script file. It was a less than perfect solution. I’d prefer not to roll out with empty files that are just stubs to provoke the installer to do something.
The DNN 5 approach is to decouple this. So now you tell it which version nrs to send to UpgradeModule (and obviously the installer will disregard those with a version lower or equal to the previously installed version). It means a little more housekeeping on my part which I’d hoped to avoid, but this is the price of progress folks.
My only criticism here is that there is quite a bit of redundancy here. It could just as well have been the one line of the upgradeVersionsList. All other bits are known and could have been left out. But I guess this approach opens the door to more features although I’m not quite sure what …
So that’s it. As far as I can tell the module now installs on DNN 4 and 5 in exactly the same way using 2 manifests.