Recently I have worked with multiple clients that have had "minimum version" issues with DotNetNuke modules.  They have a new module, or a new version of an already installed module and they install it on their site.  Just after installation they find out that the module doesn't work with their version of DNN.  Sometimes this isn't a major issue as long as it is only the module that doesn't work and it was a new module.  However most of the time it isn't the case, usually it happens to existing modules that include lots of data.  Since DotNetNuke doesn't offer a rollback function these types of issues can be critical to users of DNN.  Now the first argument that I always hear on this topic is that "people should be backing up their site before an install/update to anything".  I agree with this to a certain extent, but on the other hand these people expect that we as developers will make using our product a pain free situation.  This is where this article come into play, I'll discuss a few methods where developers, including myself need to step up and provide better quality services to the general DotNetNuke public.  I'll even include a step by step guide that will show developers how to accomplish what needs to be done.

I am going to discuss this issue in two separate parts, first I am going to discuss the current situation with module compatibility and the common practices employed by developers to mitigate the risks, then I will discuss the proper solution that will NEVER allow a module to affect a users site.

Current Situation

Currently in about 95% of the cases with modules that depend on a specific version of DNN the only method employed to ensure that the module is not installed on an improper DNN site is a note to the user on the overview or download page that says; "version xx.xx.xx is required for this module".  This is true for not only third party modules but also core DotNetNuke modules.  Yes, individuals using DotNetNuke should really know what version they are on and should employ safe practices when installing and upgrading, but you would think at a minimum that DotNetNuke core modules would be a bit more sophisticated.  Well maybe it is too complex to introduce a dependency to ensure that a module doesn't install, maybe there isn't a framework for handling this type of thing?

Well actually there is, I implemented a hard set version limit on my Expandable Text/HTML module in under 30 seconds.  With a simple change to my module's .dnn manifest file I was able to set a restriction that would abort the installation if it tried to install on a version less than the one specified in my configuration rule. 

So with it being this easy, why isn't it done?  Well my guess is that it isn't something that is readily documented, even though the config option is right there on the module definitions page.  That is why I wrote this article, I wanted to shed some light on this situation, and provide the information needed for developers to implement proper version dependencies in their modules.  If we can implement protection for our clients with such minimal effort, it wouldn't be right for us to knowlingly omit this important step.

How to Implement?

So now that we have discussed the issue I will show you what is needed to set a version dependency.  In a modules .dnn file a developer can add a <compatibleversions> tag inside the folder portion of the file, typically the best place is right after the <version> tag that identifies the current version of your module.  Inside this setting you simply place a regular expression value that will validate to true for any version that your module will work in.  For example my Expandable Text/HTML module works with DNN 04.06.00 and later, below is the code used for that module to set the dependency.

As you can see a very simple regular expression is employed to ensure that the proper versions will validate as true.  For those of you not familiar with RegularExpressions you can utilize my RegEx Tester utility here on this site to test your expressions to ensure they work for all proper DNN versions.  This simple step will prevent many hours of heartache for a client that installs a module that doesn't work on their version of DotNetNuke.

Conclusion

I hope that this article has served as an eye opening experience to DNN users and module developers as I know this recent discovery has been enlightening to me as I am now working to include this functionality in all of my modules.  Please share any feedback you have below!

Updated - 4/22/2008

This article was updated at approximately 7:40 AM 4/22/2008 to include a different Regular Expression text for validation. It was brought to my attention that the previous script would not validate successfully once Cambrian was released. The currently listed script will truly validate 4.6.0 or later. If you have any questions please let me know.