In nearly all of my modules, I include the compatibleversions node in the manifest file for my modules. The reason I do this is simple. I want to prevent my module from being installed on DotNetNuke® sites that I do not want to support, or cannot support. Think about that for a moment…
One example for this might be that I am using a feature that is only supported in certain versions of DNN. A module that required SSL would be a great example of this. SSL has been native to DNN since version 4.05.04, but most people don’t know that. Heck, I would bet many module developers don’t know that. It’s for that reason that someone might want to include the compatibleversions in their DNN manifest. If the person installing their module on an earlier version of DNN, then the installer will tell them that they can’t.
Another reason that a module developer might want to use this feature is in the instance that they do not want the person installing the module to install it on a version of DNN that they do not want to support for any other reason. For example, I might not want someone to install a module on DNN 5.00.00 or 5.00.01 due to the number of bugs they had. After all, what module developer wants to troubleshoot issues on those DNN instances? ;)
The compatibleversions node uses regular expression to determine the DNN versions that the module is intended to support. The format of this feature is like so:
When I have wanted to support DNN 4.06.02 and above, I have traditionally used a regular expression like the following:
With DNN 5, I wanted to use the follow regular expression to support only DNN 5.01.00 and above:
For DNN 5.00.00 and above, you might use this:
Taking the last example, the compatibleversions node would look like this:
Beginning with DNN version 5.00.00, the compatibleversions has been ignored. The reason for this appears to be quite simple. It was only thought of to prevent non-existent backwards compatibility. Meaning, it was not intended to support some versions, skip a few, and then provide support again. Erik Van Ballegoij found and reported this issue in DNN 5.00.00 beta 4, but for the reason I just described, it was not fixed.
What does this mean to you? Well, if you’re using DNN 4, nothing. But if you’re using DNN 5, then your module will currently install on any version of DNN 5, no matter if you want it to or not. For example, I do not want to support DNN 5.00.00 or 5.00.01, but I cannot prevent the module from being installed on those versions. While the extensions installer will read the compatibleversions node, it clears the value immediately after reading it. So including it will not throw an error, but it will not do anything either.
Here are lines 175-183 of the ModuleInstaller.vb file in the DNN source:
'Load the Desktop Module from the manifest
DesktopModule = CBO.DeserializeObject(Of DesktopModuleInfo)(New StringReader(manifestNav.InnerXml))
DesktopModule.FriendlyName = Package.FriendlyName
DesktopModule.Description = Package.Description
DesktopModule.Version = FormatVersion(Package.Version)
DesktopModule.IsPremium = False
DesktopModule.IsAdmin = False
DesktopModule.CompatibleVersions = Null.NullString ' <-- SEE???
This presents an interesting and uninvited challenge to ISVs, in the form of support. Support is already an ugly word in the DNN ecosystem, as it usually represents the highest cost item to ISVs. With the compatibleversions node being ignored, I cannot prevent any calls or tickets for those unsupported DNN 5 sites. I of course could tell people with large red text that those versions are not supported, but we all know few people will read that message.
Right now, there is not a solution to this problem (except for the large red text). But I did report this as a new issue in DNN’s support site.
What do you think? Is this still a necessary feature? If so, please comment here. You could also place a comment on the DNN issue I created.