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.

Background

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.

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

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">
  <config>
    <configfile>web.config</configfile>
    <install>
      <configuration>
        <nodes>
          <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="*">
          </add></node>
          <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="*">
          </add></node>
          <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">
          </add></node>
          <node collision="overwrite" key="name" action="update" path="/configuration/system.web/httpModules">
            <add name="RadUploadModule" type="Telerik.Web.UI.RadUploadHttpModule, Telerik.Web.UI">
          </add></node>
          <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="*">
          </add></node>
          <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="*">
          </add></node>
          <node collision="save" action="update" path="/configuration/runtime/ab:assemblyBinding/ab:dependentAssembly[ab:assemblyIdentity/@name=&#39;Telerik.Web.UI&#39;]" namespaceprefix="ab" namespace="urn:schemas-microsoft-com:asm.v1" targetpath="/configuration/runtime/ab:assemblyBinding/ab:dependentAssembly[ab:assemblyIdentity/@name=&#39;Telerik.Web.UI&#39;]/ab:bindingRedirect">
            <bindingredirect newversion="2010.02.0713.35" oldversion="2008.0.0.0-2020.0.0.0">
          </bindingredirect></node>
        </nodes>
      </configuration>
    </install>
    <uninstall>
      <configuration>
        <nodes>
      </nodes></configuration>
    </uninstall>
  </config>
</component></pre>

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.