Potential DNN 5.2 Upgrade Issues

After talking with a number of clients since last week, I thought it would be worthwhile to make a post here with a formal warning regarding upgrades to DotNetNuke 5.2. As announced at OpenForce US, DotNetNuke 5.2 contains the Telerik Controls for ASP.NET, which is a very good thing for DotNetNuke as a whole, however, it can cause massive problems for individuals that are already using the Telerik Controls as a site upgrade can end up rendering portions, or the entire site unusable, until DLL versions are restored. In this post I will give a bit of information regarding the scenarios that I have encountered and some guidance on how to protect yourself from upgrade issues.

Potential Issue Scenarios

Sites that might encounter issues with upgrades to DNN 5.2.x are site that have modules or skin objects that use the Telerik controls already. Not all sites will have issues, just sites that are using old, incompatible versions of the Telerik controls. Typically this would be a site that has been using the controls for a long time, potentially even in times before Telerik moved to a "single dll" deployment.

Depending on when/where the controls are used the impacts of a failed upgrade will vary. For example, if an older version was used for a menu component and it didn't support moving foward, the entire site could potentially error out, since the menu is on each and every page. Reverting to the default skin, would allow you to regain access. For the case of custom modules, 99% of the time, it would only be that custom or third party module that would error out, which is a smaller risk, but a bit harder to identify if you have a site that includes hundreds of Modules.

Identifying If You Are At Risk

The process of identifying if you might be at risk is actually quite easy. The fastest way is to simply look at your /bin folder of your DNN site, looking for DLL's that start with "Telerik" or "RadXXX" where XXX might be Menu or other similar module names. The latter example DLL name is from the older suite of Telerik controls, those are the ones that are going to pose the greatest risk, as the legacy RadMenu.dll cannot sit alongside the new Telerik combined dll, so a modification to the menu provider/skin might be necessary.

If you do not see any DLL's of that nature, you should be ok to upgrade without issue.

Mitigating Risk/Testing

If you find that you do have Telerik DLLs in your site, the only real way to find out if you will have a problem is to test the upgrade, but just be prepared that you might have a few issues that will come up along the way. If you are having specific issues, feel free to post questions to my forum as I'lll be glad to help.

After completing an upgrade, be sure to run through your site, at minimum hitting all modules at least once to ensure that you do not have errors prior to deploying an upgrade if you have existing Telerik Dll's in use.

Posted by Mitchel on Wednesday, December 02, 2009

Tags: DotNetNuke, DotNetNuke Administration, DNN Install/Upgrade

Comments

Comments from the following blog entry: Potential DNN 5.2 Upgrade Issues, located at: http://pimpthisblog.com/Potential-DNN-52-Upgrade-Issues

By PimpThisBlog.com on Wednesday, December 02, 2009 at 5:23 AM

Great Post Mitchel, I was wondering about this myself.

By Brad on Wednesday, December 02, 2009 at 8:29 AM

Thanks for this information. We use Telerik panel bar for our site navigation in our custom skin. If we use DNN 5.2 professional edition, are we able to put the Telerik component in our skin for no additional charge, or would we still need to pay a Telerik subscription on top of DNN pro?

By Nathan Smith on Thursday, December 03, 2009 at 2:46 AM

You also can have (for sure will have) a telerik DLL version mismatch which can be solved with the bindingRedirect in the web.config.
More info here: http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/190/threadid/341103/scope/posts/Default.aspx

By HoracioJ on Thursday, December 03, 2009 at 3:38 AM

@Nathan

From what I understand, you will get a full license for internal developers for development against DotNetNuke based on Shaun's post.

@HoracioJ

Very valid point, in most cases that will resolve the issues, but not 100% with some older components.

By mitchel.sellers@gmail.com on Thursday, December 03, 2009 at 9:35 AM

Comments from the following blog entry: Social comments and analytics for this post, located at: http://www.ubervu.com/conversations/www.mitchelsellers.com/blogs/articletype/articleview/articleid/325/potential-dnn-52-upgrade-issues.aspx

By uberVU - social comments on Thursday, December 03, 2009 at 1:42 PM

Mitchel,

Has this been fixed with the release of 5.2.1?

Cheers
Dave

By colby-dnn on Wednesday, January 06, 2010 at 4:37 AM

This is still something to be aware of with any version post 5.2.x

You need to be aware of it, regardless of what is done with DNN!

By mitchel.sellers@gmail.com on Wednesday, January 06, 2010 at 7:22 AM

Perfect, thanks so much.

Cheers

By colby-dnn on Thursday, January 07, 2010 at 5:13 PM

Don't forget that DNN 5.2 are not support SQL 2000. There are many people that still using it.

By erw13n on Monday, January 25, 2010 at 11:05 AM

The DNN 5.2.1 installation detects if Telerik RAD controls are already installed and inserts a bindingRedirect in the web.config.

Unfortunately in my experience it doesn't get it right. I needed to adjust it manually to handle my Q2 2008 version of RADControls.

More information here:

http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/203/postid/346665/scope/posts/Default.aspx#346665

http://www.telerik.com/community/forums/aspnet-ajax/radcontrols-in-dotnetnuke/clarification-on-using-prior-version-of-rad-controls-with-dnn-5-2.aspx#1068710

That fixed my problem for now, but I'm still not clear what happens if the DNN core or another module references RAD controls that are in the bundled version but not in my older version. An accident waiting to happen I suspect. Any ideas?