Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Where did Telerik go?


Ever since an updated version of Telerik assembly was shipped with DotNetNuke 5.4, people have continued to report that the Telerik assembly is missing from the \bin folder in the upgrade package.  Given the number of reports related to this issue, it is clear that there is a lack of available documentation for how DotNetNuke is packaged.  Some of these problems will be helped by the new wiki project that is being worked on by the Core Reference team.  The wiki will provide a place where we can document application behavior.  Since the wiki is not quite ready to open for public use, I’ll try to document what is going on with respect to Telerik in this post.

During the 5.3 release we originally intended to include an updated version of the Telerik controls. Our goal is to include new Telerik assemblies with each major release.  Since 5.3 was the first major release following the introduction of Telerik controls in 5.2 we had hoped to make the shift.  When we first created the 5.3 package, we found that attempting to upgrade from any of the 5.2.x packages resulted in a yellow screen when you first start the upgrade.  As a result we pushed the Telerik upgrade to 5.4 so we could better study the problem and find an appropriate solution.


When we first implemented Telerik in 5.2 we included an assembly binding entry in Web.config to ensure that any modules that used older versions of Telerik would automatically use the new telerik assembly.

  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
      <bindingRedirect oldVersion="2008.1.1.20-2010.4.2000.20" newVersion="2009.3.1104.35" />

The downside to having used an assembly binding is that the web.config becomes tightly bound to that specific version of the assembly.  If you change the assembly, you must update the assembly binding to reference the new version number.  Failure to update both the assembly and web.config at the same time will result in a yellow screen error.  This is the exact behavior we were seeing in our testing on 5.3.

The solution

When we started work on the 5.4 release we thought about how to make sure that we could update the web.config before we changed the assembly.  We new that if we just included the assembly in the \bin folder that it would cause the error so we had to keep the Telerik assembly out of the \bin folder during any upgrade scenarios.  Instead, we relied on the strength of our extensions capability.  One of the features we added a few years ago was the ability to automatically make changes to config files during an upgrade.  This feature was baked into the DotNetNuke manifest for DotNetNuke 5.0.  In addition DotNetNuke 5.0 gained the ability to recognize many different extension types – including a library extension.  By combining a library extension with a configuration component we are able to upgrade both the web.config and assembly in a single operation, thereby ensuring that we don’t get the yellow screen during the upgrade.

<pre class="brush: xml;"><component type="Config">
          <node collision="overwrite" key="path" action="update" path="/configuration/system.web/httpHandlers">
            <add type="Telerik.Web.UI.WebResource, Telerik.Web.UI" path="Telerik.Web.UI.WebResource.axd" validate="false" verb="*">
          <node collision="overwrite" key="name" action="update" path="/configuration/system.webServer/handlers">
            <add name="Telerik.Web.UI.WebResource" type="Telerik.Web.UI.WebResource, Telerik.Web.UI" path="Telerik.Web.UI.WebResource.axd" verb="*">
          <node collision="overwrite" key="name" action="update" path="/configuration/system.webServer/modules">
            <add name="RadUploadModule" type="Telerik.Web.UI.RadUploadHttpModule, Telerik.Web.UI" precondition="managedHandler">
          <node collision="overwrite" key="name" action="update" path="/configuration/system.web/httpModules">
            <add name="RadUploadModule" type="Telerik.Web.UI.RadUploadHttpModule, Telerik.Web.UI">
          <node collision="overwrite" key="path" action="update" path="/configuration/system.web/httpHandlers">
            <add type="Telerik.Web.UI.ChartHttpHandler, Telerik.Web.UI, Culture=neutral, PublicKeyToken=121fae78165ba3d4" path="ChartImage.axd" validate="true" verb="*">
          <node collision="overwrite" key="name" action="update" path="/configuration/system.webServer/handlers">
            <add name="Telerik.Web.UI.ChartHttpHandler" type="Telerik.Web.UI.ChartHttpHandler, Telerik.Web.UI, Culture=neutral, PublicKeyToken=121fae78165ba3d4" path="ChartImage.axd" verb="*">
          <node collision="save" action="update" path="/configuration/runtime/ab:assemblyBinding/ab:dependentAssembly[ab:[email protected]=&#39;Telerik.Web.UI&#39;]" namespaceprefix="ab" namespace="urn:schemas-microsoft-com:asm.v1" targetpath="/configuration/runtime/ab:assemblyBinding/ab:dependentAssembly[ab:[email protected]=&#39;Telerik.Web.UI&#39;]/ab:bindingRedirect">
            <bindingredirect newversion="2010.02.0713.35" oldversion="2008.0.0.0-2020.0.0.0">

This new Telerik library extension was packaged and included in the upgrade package in the Install\Modules folder.   Our build server automatically creates this package on every release and includes it in the DotNetNuke upgrade package, while leaving it out of the Install, Source and StarterKit packages since those packages don’t need to support upgrades.

Once the wiki is up and running I’ll work on adding some documentation around how to use the config component with the XML Merge API.  This is a very powerful feature that has certainly helped us with many different upgrade scenarios for DotNetNuke and this is just another example of the power of this little known feature.

This blog post is cross-posted from my personal blog.


Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (269)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?