There are a number of things that change when you progress from developing a module just for yourself to developing modules for a wider audience. DNN has a ton of features to make life easier for you and to protect the user on the other side. This is vital because you have no idea where the module will be installed. Like the version of DNN your module will be running on, other extensions that have been installed or the selected theme. In this post I'll delve into some of the factors influencing the decision which DNN version to target with your extension.

As you all know, if you compile your module when referencing DNN 5 and you try to run this on DNN 4, .net will bomb. It won't even try to intelligently match your code to what is in the bin folder. Instead you'll get a big fat error and nothing will display. Not the greatest experience for your customer. This is why, in the module's manifest, you should mention what minimal version of DNN your module will work on. The installer will check this value and simply refuse to install the module if the current DNN is older. Back in the days before this addition to the manifest we (read: commercial module developers) it was not uncommon for customers to install our module on a too old DNN. Fixing a site broken in this way is only possible by hand and I've had to guide people through this over email. It's ugly.

The key takeaway here is: make sure you mention the minimum DNN version like this in your manifest

<dependencies>
    <dependency type="CoreVersion">08.00.00</dependency>
</dependencies>

Next is less of a technical issue and more of a people issue. Part and parcel of working in DNN means you have to deal with older DNN installations. There are several factors that contribute to the "people don't update"-issue. One is that as DNN matured, the necessity to upgrade decreased. Releases became pretty feature complete and stable by 2008 (DNN 6). Why take the risk of upgrading when the old system works just fine? Don't fix it if it ain't broken.

Now add to this the following trend. Many sites are created by SMB for SMB. Your average mom-and-pop-shop doesn't reserve a 4 figure budget per month for their website. Websites are commonly one-off projects that terminate and then the relationship between customer and supplier dissolves over time. Alternatively in larger companies it is also not uncommon that with IT staff turnover the not-business-critical intranet site that has been humming along doesn't have an "owner" any more. This trend has led to the existence of many "abandoned" DNN sites. Those sites where there the person who created it has no active involvement in it any more. Then one day someone else is asked to look at the site because there is some error or because they wish to change something.

The tricky thing here is that this new person who's taking on the responsibility of the site might not be a DNN expert. In fact, given the skillset of the average web developer, chances are they're new to DNN. They can easily be forgiven if they are reluctant to upgrade the core system as this can snowball and force a lot of other upgrades. And if you're new to DNN, this is not something to be taking lightly.

The point I'm trying to make is that there are a lot of older DNN sites out there that haven't been upgraded for a while and sometimes with good reason. So there is a large "spread" of DNN versions out there. This in turn puts pressure on us as developers to ensure our stuff works on older versions of DNN. I have received countless emails asking "does your latest version of DMX work on DNN x" where x is a version from years ago.

There are 3 criteria I use for the DNN version dependency of a module:

1. The DNN version needs to implement what I need (in a decent way). What does this mean? For all my modern modules I use the MVC module pattern and WebAPI calls. This was introduced in DNN 8. So for most of these modules I will take a dependency on DNN 8.

2. I presume a "reasonable" shelf life of 2 years for a version. After that I feel free bump the version dependency.

3. If possible I stick to major versions only. I.e. 6.0.0, 8.0.0, etc. This is because I feel it is confusing for customers to do exact version matching. Rather just stick to simple "it works on DNN 8 and higher".

Speaking with other big vendors, they confirm these approaches. And this sometimes pits us against the people creating the platform who want the community to adopt the latest version as fast as possible. So having us supporting older DNN versions allows customers to postpone upgrading (I have been asked in the past to move my dependency to a more recent version for this reason). We're kind of stuck between a rock and a hard place here. On many occasion I have had exchanges with customers where I'd urge them to upgrade because the version they are on has known vulnerabilities. And yet, in most cases, I'm told this is just not an option. They'd rather run the risk than upgrade. So my personal experience tells me that expecting customers to upgrade DNN is extremely hard.

I hope the above was informative. It comes from 15 years of experience selling my document management solution (DMX) in the DNN marketplace. There are no right or wrongs in picking your dependency, but if I've helped you make that decision than this blog post served its purpose.