DotNetNuke Upgrade Telerik Error

I'm trying to upgrade from 05.05.00 to 05.06.03 and getting Telerik-Install-Errors which I can't solve.. Anyone can help?

00:00:00.015 - Installing Package File Telerik_05.04.00_Install: Error! 00:00:01.466 - Installing Package File Telerik_05.05.00_Install: Error! 00:00:02.059 - Installing Package File Telerik_05.06.02_Install: Error! 00:00:02.683 - In开发者_StackOverflowstalling Package File Telerik_05.06.03_Install: Error!

This is a fairly common upgrade error, but it is easy to fix.

First, install Telerik_05.06.03 manually to get the correct version of Telerik.Web.UI.dll , and then reinstall it with the extension installer in order to avoid the same upgrade errors in the future.

Manual install instructions:

1. Extract the Telerik install package to a convenient location. The package can be found in:

   DotNetNuke_Community_05.06.03_Upgrade\Install\Module\Telerik_05.06.03_Install.zip

2. Copy the Telerik.Web.UI.dll to the DNN /bin folder, replacing the existing version

3. Modify the bindingRedirect in the web.config to point to the correct version (below)

4. Once you get the site up and running, use Host Settings - Extensions to reinstall the module.

I have avoided this error by taking the site down from the public internet during upgrades, and by being careful with the file permissions. You can allow only localhost access by removing other IP bindings from IIS. Make sure that 127.0.0.1 or localhost is in the DNN's PortalAlias table. Prior to an upgrade I usually reapply the required permissions to the DNN folders, just in case they have changed since the last upgrade. Depending on the IIS version and configuration you are running, either Network Service or IIS AppPool\DefaultAppPool needs read, write and modify privileges.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin;bin\HttpModules;bin\Providers;bin\Modules;bin\Support;" />
      <dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="Telerik.Web.UI"
        publicKeyToken="121fae78165ba3d4" />
        <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0"
        newVersion="2011.1.519.35" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

See also:

• DotNetNuke Installation Guide
• Windows 7 /Windows 2008 R2 cross application pool isolation

@Mika hits the key points on this issue. Here is another description of a similar solution. http://www.dotnetnuke.com/Resources/Forums/forumid/200/postid/413148/scope/posts.aspx#413148

On a positive note, during the development of 6.0 I think we finally identified the cause of this issue and created a fix for it. We should never see this problem in 6.x. I would be very interested to know if you do see it in a 6.x release.

Just did another DNN upgrade and found ALL of the above to NOT help prevent the issue. Here is a last ditch option for those who find the above answers did not help:

1. Backup everything first, duh.
2. Keep a copy of your web.config file handy, but rename it to something like original_web.config.
3. Make a copy of the release.config from your OLD site copy. (Do NOT take one from the upgrade copy of DNN.)
4. Edit the release.config and replace your database connection, including the legacy 'app settings' version, and make them point to your database. (Which you backed up, I can't stress this enough.)
5. Change the value in this setting '' to false, not true.
6. Copy the upgrade package you are targeting over top.
7. Do all the precautions suggested by Mika's post above. * Bonus: Enable 32-bit support and ensure you are in 'Classic' mode IF you are running a version of DotNetNuke that required it. Don't change if you are unsure!
8. Browse to the site, upgrade (successfully!).

NOW, a VERY important step. You'll need to walk through your site testing things. If you find errors you probably had some critical thing in your original_web.config that is NOW MISSING from the fresh web.config I helped you to create (from release.config) above.

So you'll need to do a line-by-line comparison (this takes a seasoned eye) and find things like missing assembly references, binding redirections, handlers, modules, application settings/keys and the like. The more you do this, the faster it gets. (If you suck at understanding web.config stuff, and don't have a strong IIS background, this step has the potential to be horrible - I won't lie.)

That said, a good percentage of the time hardly anything is required from the web.config. When something is missing, it's often just an obvious DLL reference or handler.

Best of luck!