Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Installing and upgrading modules in DNN, a developer's view

There's some misunderstanding on how DotNetNuke Modules are installed and which steps are executed during a module installation or upgrade.
I'll try to cover both scenarios on this post and I hope this helps to get a clearer idea of how this works.

Let's first take a look at what happens when a module is installed:

As you may know all the internal versioning of modules (and even the core itself) is built around the <version> node on the .dnn installer manifest and the sql scripts that are included in the installation zip.

When the module is installed DNN will run all sql scripts with a number lower or equal than the one specified in the <version> node. Finally the version in that node will be saved on the DesktopModules table. This will help the core on future upgrades so it can know what version is currently installed.

First thing to note here: A given xx.xx.xx.SqlDataProvider script will only be run once. So no matter how many times you reinstall the same module, each sql script will only run once. This is great because otherwise you will see lots of errors when (for example) trying to create a table that already exists.
This gives to another point: if you had some trouble with a module (for example you removed a stored procedure accidentally during development), repeating the same process again (without first deinstalling the module) will not produce the same result.
So don't expect that reinstalling the same version that's currently installed will solve that problem. Can solve others, but not problems with the database.

Another thing that happens when you install a module is that it fires the "UpgradeModule" method if the module implements the IUpgradeable interface.

Public Interface IUpgradeable
  Function UpgradeModule(ByVal Version As String) As String
End Interface

In fact this method will be called once after any sql script has been executed and it will be passed the version number of the current script. So you have to code your upgrade logic knowing that this method can be called multiple times. This is usually done testing for the Version parameter on a "select case" statement.
The method call will be routed through the EventQueue system after the web application is restarted. A minor difference with regards to how the sql scripts are executed exists though: even if there's no sql script on the module, this method will be called at least once. This is needed to be sure that at least the upgrade logic is executed, even if no sql script exists. So if you are installing a module whose final version will be 03.03.03, be sure that UpgradeModule will be called at least once with that version number.

Also notice that all UpgradeModule(..) calls will be made after all sql scripts have already run. This is true because they will be fired after the application is restarted and the end of the module installation process.
So again, be sure not to do something "strange" on your upgrade logic, assuming that the database has a special structure. For example query a given stored proc, you know in version 01.01.01 existed, because the code will be executed when all scripts for version 03.03.03 are already installed and maybe that stored proc. doesn't exist anymore.

On first time installations this is more or less all that's involved. Upgrading a module has a couple of differences worth noting.

What happens when a module is upgraded:

Execution of sql scripts is more or less the same: each file with a version number greater than the current version number stored on the DesktopModules table, and less or equal than the number included in the <version> node of the .dnn installer manifest will be run in order.

After each xx.xx.xx.SqlDataProvider script is run, the core will search for a corresponding "xx.xx.xx.txt" file on the upgrade package. This file can contain a list of files you want to remove from older versions of your module. You have to specify a file on any line using the relative path from the root of the DNN installation. For example:

So if this file is 03.03.03.txt, and there's a 03.03.03.SqlDataProvider file, it will be "executed" just after the sqlscript and before the UpgradeModule for this version.
This is also another point where you have to make attention: the delete file will only be processed if there's a related sql script.
Afterwards the application is restarted all the UpgradeModule(...) will be called for each sql script that has been run before. Again, UpgradeModule will be called at least once for the final version (the one in the <version> node) , even if no sql script exists.

I hope this brief explanation helps to understand how DNN processes modules during installation and successive upgrades.


Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (268)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?