I have not yet figured out whether I’m blessed or cursed to be involved in maintaining an extensive DotNetNuke site. I’ve had a year to develop an opinion of DNN, which is a framework that I really wanted to like.
During that year I’ve been sidetracked with other responsibilities for the same client, such as developing an automated billing system and doing some sysadmin tasks, but I’ve finally had some significant time to get cozy with the DNN architecture.
The site began as a generic ASP.NET 1.1 site, then the developer discovered DNN 2, and bolted that onto the legacy parts of the app. Before long this was upgraded to 3.0.13, and currently, I’m in the throes of moving it to DNN 3.3.7 — with the plan being to get that stable and then switch to ASP.NET 2.0 and finally whatever flavor of DNN 4.x is then current.
You may notice that is that this is an awful lot of re-tooling in the course of just a couple of years. Today I was looking for answers to some upgrade questions (little is published about upgrading, and what is published is mostly about major DNN version upgrades). I stumbled across the web site of a DNN plug-in module vendor. The info I’m about to quote is in the Google cache — the current live site tones it down considerably, so I won’t provide a link or identify the vendor. However, I have to say, it’s a pretty revealing rant and validates some of the growing suspicions I’ve developed about DNN.
The vendor was addressing a FAQ regarding why they don’t participate in the DNN certification program for module vendors:
… very simply, DNN changes too frequently. Core API changes have occurred in the last 3 to 4 years to versions 2.0, 2.1, 3.0, 3.3 – that is essentially 4 significant API layer changes in less than 4 years time – with the prospect of another major API change forthcoming [he’s referring to DNN 4.x, which is now out and itself has had some significant minor updates since] …
These types of certifications are useful with regards to long-term solid API foundations, such as Windows 32 Bit API, [the] .NET platform, Java and other technologies where the core API does not change on a whim. This is not the case with DotNetNuke. In essence, a DotNetNuke certification does not guarantee that the module that you purchase will work past the next release of DNN – or that the module developer will maintain versions for your current version of DNN if you choose not to upgrade.
I don’t know how to define “too frequently” or whether it’s even the real problem here … the real problem is far too many breaking changes. The core developers are not afraid to change interfaces or namespaces. Sometimes the results are annoying (you get eight zillion “deprecated method call” warnings, but the code still works because the old signature is mapped to the new one). In other cases, things just break because they’re in the wrong place. Matters are exacerbated if you have custom code that calls into the framework.
Maybe this is unavoidable, but a portal engine that supports third party plugins and encourages users to create their own modules, probably needs to be more commited to stability than they are. I know this is making me and the other person working on this system kind of crazy. It’s also costing the client too much buckolas too early in the game I think. Probably a good solid person month or more of labor to move from a 3.0.x to a 3.3.x release seems a bit much. Granted some of it may be learning curve — of the original developers, and of me doing the upgrade. But that’s pretty normal turnover on any project these days.
DNN has other warts too — its documentation is lacking in many important ways, for example. It’s infinitely easier to find answers about the .NET framework even if you confine yourself to Microsoft resources, than it is to Google up answers about DNN. One of the problems, aside from thin docs, is … there it is again … if you do get an answer it’s probably not for the version of DNN you’re currently struggling with. It will be a three year old post about DNN2, or a brand new one about DNN4, or it will not tell you whether or not version issues are relevant. And that’s just the core technology, not the many add-ons out there.
I have yet to decide whether this is “Good Enough” or “The Best We Can Do” or “More Touble Than It’s Worth”. One of these days I’ll settle it in my mind, and post again about it.
