I want my DotNetNuke modules to work under as many versions as possible while avoiding assembly binding redirection

4
votes

I am developing DotNetNuke modules and naturally want them compiled before installing or distributing them. In the past I've simply referenced a specific version of DotNetNuke.dll by browsing to the /BIN folder of a local DotNetNuke installation.

This reference allowed me to use the DNN base classes and create my own set of classes upon those. I also use various helper methods throughout the DNN namespaces/classes that I require. (i.e. Make derived classes from their PortalModuleBase, ModuleSettingsBase and use their Localization classes which replace those provided by Microsoft's ASP.NET implementation.)

I've been able to get away with this approach making that direct DLL reference (Copy Local = True, Specific Version = False) because until now I've been installing these modules onto client websites that I maintain. As such, I've kept them on at least the version of DotNetNuke I've been developing on - or newer. Most recently, I was referencing 6.1.3.108 in development.

NOTE: This automatically copies in the following associated DLLs into the /BIN directory of my modules:

  • DotNetNuke.dll
  • DotNetNuke.Instrumentation.dll
  • dotnetnuke.log4net.dll
  • DotNetNuke.Services.Syndication.dll
  • DotNetNuke.Web.Client.dll
  • DotNetNuke.WebControls.dll
  • DotNetNuke.WebUtility.dll

Installing this onto a DotNetNuke site of a NEWER version worked fine, which isn't a bad start.

What I've been wondering though, is if there is a non-hackish way of making my modules insensitive to the minor, build or revision levels of the DLL?

I realize that it makes it my responsibility to ensure the product (if developed on a "mid range" version) still works on slightly earlier as well as newer versions of the product. That said, I feel I can do thorough testing across those builds. To me this is preferential to having to run the OLDEST major build in development.

Put another way, I'd rather not develop with references to 6.0.0.0 just so it works on 6.x.x.x without extra effort. I'll only do that if someone doesn't have a brilliant way for me to make referencing say, 6.1.3.108 working on slightly earlier or later versions. (Naturally I'm okay with having to make a different module for major version changes, such as 5.x.x.x or 7.x.x.x.)

Thanks in advance!

2
assembliesdotnetnukeversioningdotnetnuke-module

2 Answers

5
votes

Instead of referencing the assemblies in the bin folder, keep a copy of DotNetNuke.dll (and any other references) with your source code, and reference it there. Put the oldest supported version there, but develop on a newer site. Set Copy Local=False on the reference so you don't overwrite the newer version, and you should be fine.

In this way, we're able to reference DNN 4.5.3 while developing a module that runs on DNN 6.1.x. I've been using this method for years without any significant problems (except when I occasionally forget to turn off Copy Local and my DNN site mysteriously blows up).

2
votes

In regards to determining the version of DNN in a class you've subclassed from a DNN one.

Here's what I would do, assuming YourClass inherits from DNNClass, but because you have referenced an earlier version of a property, 'NewProp' doesn't exist. Here's how to do it:

public class YourClass : DNNClass
{    
    public string NewPropSubstitute
    {
       get {

           string newPropVal = "your default if earlier DNN";
           System.Reflection.PropertyInfo pi = this.GetType().GetProperty("NewProp");
           if (pi != null)
               newPropVal = (string)pi.GetValue(this, null);
           return newPropVal;
       }
    }
}

That's a made-from-memory guess so it might not compile, but you get the idea. You don't necessarily have to get the DNN Version if you want - just try and get the property through reflection - if it's there, implicitly you've got the right version.

Of course this method assumes you can substitute in a value for a later-DNN property (or method) if the DNN version doesn't support it. But that all depends on what you're trying to do.

If you do want to find the DNN Version (version safe and always correct) you can use the code for that which is embedded in my version-safe jQuery inclusion code, linked from this blog post: Using jQuery in DotNetNuke 5 and 6