DotNetNuke Обновление Telerik Ошибка - PullRequest
Новая
       11

DotNetNuke Обновление Telerik Ошибка

3 голосов
/ 30 сентября 2011

Я пытаюсь обновиться с 05.05.00 до 05.06.03 и получаю Telerik-Install-Errors, которые не могу решить .. Кто-нибудь может помочь?

00: 00: 00.015 - Установка файла пакета Telerik_05.04.00_Install: Ошибка!00: 00: 01.466 - Установка файла пакета Telerik_05.05.00_Install: Ошибка!00: 00: 02.059 - Установка файла пакета Telerik_05.06.02_Install: Ошибка!00: 00: 02.683 - Установка файла пакета Telerik_05.06.03_Install: Ошибка!

Ответы [ 3 ]

6 голосов
/ 30 сентября 2011

Это довольно распространенная ошибка обновления, но ее легко исправить.

Сначала установите Telerik_05.06.03 вручную, чтобы получить правильную версию Telerik.Web.UI.dll, а затем переустановите ее с помощью установщика расширения вЧтобы избежать ошибок обновления в будущем.

Инструкции по ручной установке:

  1. Извлеките установочный пакет Telerik в удобное место.Пакет можно найти в:

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

  2. Скопируйте Telerik.Web.UI.dll впапка DNN / bin, заменив существующую версию

  3. Измените bindingRedirect в файле web.config, указав правильную версию (ниже)

  4. После того, как вы запустите сайт, перезапустите модуль, используя Настройки хоста - Расширения.

Я избежал этой ошибки, отключая сайт из общедоступного Интернета во время обновлений.и быть осторожным с правами доступа к файлам.Вы можете разрешить только локальный доступ, удалив другие привязки IP из IIS.Убедитесь, что 127.0.0.1 или localhost находятся в таблице DNN PortalAlias.Перед обновлением я обычно повторно применяю необходимые разрешения для папок DNN, на случай, если они изменились со времени последнего обновления.В зависимости от используемой версии IIS и конфигурации, Network Service или IIS AppPool\DefaultAppPool должны иметь права на чтение, запись и изменение.

  <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>

См. Также:

3 голосов
/ 30 сентября 2011

@ Мика бьет по ключевым вопросам в этом вопросе.Вот еще одно описание аналогичного решения.http://www.dotnetnuke.com/Resources/Forums/forumid/200/postid/413148/scope/posts.aspx#413148

Положительным моментом является то, что при разработке версии 6.0 мы, наконец, определили причину этой проблемы и создали ее решение.Мы никогда не должны видеть эту проблему в 6.x.Мне было бы очень интересно узнать, видите ли вы это в версии 6.x.

0 голосов
/ 20 апреля 2012

Просто сделал еще одно обновление DNN и обнаружил, что ВСЕ из вышеперечисленного НЕ помогло предотвратить проблему. Вот последний вариант рва для тех, кто нашел выше ответы не помогли:

  1. Сначала сделайте резервную копию всего, да.
  2. Держите копию вашего файла web.config под рукой, но переименуйте ее в нечто вроде original_web.config.
  3. Создайте копию файла release.config со своего старого сайта. (НЕ Берите один из копии обновления DNN.)
  4. Отредактируйте файл release.config и замените соединение с базой данных, включая унаследованную версию «настроек приложения», и сделайте так, чтобы они указывали на вашу базу данных. (Что вы подкрепили, я не могу этого подчеркнуть.)
  5. Измените значение в этом параметре '' на ложь, а не на истину.
  6. Скопируйте пакет обновления, на который вы нацелены сверху.
  7. Выполните все меры предосторожности, предложенные постом Мики выше. * Бонус: включите 32-битную поддержку и убедитесь, что вы находитесь в «классическом» режиме ЕСЛИ вы используете версию DotNetNuke, которая требовала этого. Не меняйся, если не уверен!
  8. Перейдите на сайт, обновитесь (успешно!).

СЕЙЧАС, ОЧЕНЬ важный шаг. Вам нужно будет пройтись по тестированию вашего сайта. Если вы обнаружите ошибки, возможно, в вашем файле original_web.config есть какая-то критическая вещь, которая сейчас ПРОПУСТИТСЯ от свежего web.config, который я помог вам создать (из release.config) выше.

Таким образом, вам нужно будет выполнить построчное сравнение (это требует опытного взгляда) и найти такие вещи, как отсутствующие ссылки на сборки, перенаправления привязки, обработчики, модули, настройки / ключи приложения и тому подобное. Чем больше вы это делаете, тем быстрее это происходит. (Если вы плохо разбираетесь в материалах web.config и не обладаете достаточным опытом IIS, этот шаг может оказаться ужасным - я не буду лгать.)

Тем не менее, хороший процент времени вряд ли что-то требуется от web.config. Когда чего-то не хватает, это часто просто очевидная ссылка или обработчик DLL.

Удачи!

...