Archive
Monthly
Go
|
|
DNN Blog
Jul
22
Posted by:
Joe Brinkman
7/22/2010 7:06 PM
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='Telerik.Web.UI']" namespaceprefix="ab" namespace="urn:schemas-microsoft-com:asm.v1" targetpath="/configuration/runtime/ab:assemblyBinding/ab:dependentAssembly[ab:assemblyIdentity/@name='Telerik.Web.UI']/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.
This blog post is cross-posted from my personal blog.
4 comment(s) so far...
Re: Where did Telerik go?
Should be a good use of the DNN wiki!
By Rod Weir on
7/23/2010 8:36 AM
|
Re: Where did Telerik go?
>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
Sorry Joe - thats not quite right - we actually include the package in Install/Module as well for all packages. In this way when dnn is installed the first time, the App knows the current version of the Telerik package so that if there is no change on Upgrade we don't need to install it.
By Charles Nurse on
7/23/2010 6:34 PM
|
Re: Where did Telerik go?
>> the power of this little known feature
One of the HUGE pain points in DNN is there are SO MANY little known features. I coded up my own token replace solution before I discovered there was one inside DNN - pure waste.
I could not get the builtin email sending stuff to work properly for me. I don't recall the details, but I wasted more time on trying to find/understand the code than it eventually took mer to write my own. More pure waste.
Many OSS projects have abysmal documentation, usually because the dev's lose interest before they get to the docs. DNN is unusual in that it is STILL being developed and is still GRATUITOUSLY hard to develop for.
By Richard Howells on
7/27/2010 6:20 AM
|
Re: Where did Telerik go?
Is it just me? I can't see the pasted in (I assume) config extracts.
By Richard Howells on
7/27/2010 6:21 AM
|
|