Net Data Design, LLC Blog

Perhaps I was a little quick in singing praises about the way DotNetNuke (DNN) is handling releases. I posted a blog not long ago about this subject, and at the time it seemed true, but not so fast my friend.

In the last two or three releases there have been some major issues, one that directly effects me is a missing method from the DataProvider in 5.4.3. What’s makes it slightly more strange is a very similar issue was found in the previous release (5.4.2). Two other “showstopper” issues that also appeared in recent builds are DNN -12501 and DNN-12412.

In DNN 5.4.0 a change to the PageBase class in DNN has caused aspx pages to break in 3rd party modules. Meaning scripts wouldn’t run, RSS and some AJAX callbacks where broken. The problem was fixed, but a game of Jenga has begun.

When it was first announced the rigid release times sounded like a good idea. Every quarter there is a minor release, every Month a bugfix release. The dates for these releases cannot be missed. And to the Core Teams credit, they haven’t missed a date yet. That said, perhaps DNN needs to find a way to detect breaking issues before RTM, beta has always been an expensive way to do so, but one that DNN seems to avoid.

Of course, you’re going to get the people who press a beta into production, but the beta releases would certain produce a better production build to the DNN community.

So, what do I mean by new look? Well, the powers-that-be have moved DotNetNuke (DNN) to an open repository. Since it’s inception from the iBuySpy days the repository has been closed.  I should note that the project has always released a “source” version of the application to the public, and for the first few years this system worked for a majority of the DNN community.

Times change however, and DotNetNuke Corporation is adapting to these changes. For instance the Issue Tracking has been reworked, and the new “Just like Clockwork” release dates. The later replacing the “When it’s Ready” policy. I was never a big fan of this policy but I do understand that a project that relied on a largely volunteer staff, this was a best fit model for DNN. Again, times change.

A few personal observations from someone (me) who has used, developed to and profited from DNN since version 1.5, the iBuySpy fork:

1. I have noticed that the quality of releases since DNN incorporated has risen greatly. There seems to be more attention paid to details and the QA/Testing group appears to have things well in hand.
2. The security of a DNN build has always been handled well, but the newer releases have been outstanding with no critical issues in well over a year. Kudos go to Cathal Connolly for an outstanding effort.

If you haven’t installed and tested this rich development platform, or perhaps you have in the past and lost favor; you need to check-it out. You’ll find a robust community and user-groups world-wide. Give it a shot.

While the newest DotNetNuke release (5.2.1) is primarily a stabilization release, it does pack a much needed new caching provider that allows the application to run much better under load with improved performance. There have been a few cases, from what I can see, with some minor upgrade issues but as a whole this is a worthwhile upgrade.

The major highlights are:

• Fixed issue where banners were not properly rotated according to the specified views/clicks.
• Fixed issue where upgrades could fail if the the user account did not have permission to update objects in some db schemas.
• Fixed issue where list values were visible outside of the Portal where they were created.
• Fixed issue where caching providers were not rendering unicode characters properly.
• Fixed issue with missing Telerik assembly in the source package.
• Fixed issue where Ajax HostSetting was not properly set on upgrade from 4.x installations.
• Fixed issues where upgrades would fail with a unique index violation.
• Fixed issue with the Starter Kit which was missing HTML module files.
• Fixed issue where page templates were not working correctly.
• Fixed default settings for the module and output caching providers.
• Fixed issue which prevented Blog module from working after some upgrades to 5.x.
• Fixed issue when creating a new module in the Module Definition Wizard if the .ascx extension was not specified.
• Fixed issue where localization was not working if the application virtual directory name was also part of the module name.
• Fixed issue where the FriendlyName for Schedule Items was not being saved.
• Fixed issue where GetUserCountByPortal was making excessive database calls instead of using cached values.
• Added binding redirect setting in web.config to prevent versioning issues with Telerik assembly.

Providers:

• FileModuleCachingProvider 05.02.01
• MemoryModuleCachingProvider 05.02.01
• SchedulingProvider 05.02.01