Что предлагается альтернатива часто нарушенному app_offline.htm взлому?

В довольно определенном сценарии размещение app_offline.htm в корне в порядке: вы делаете некоторые обновления, появляется сообщение при обновлении, и это. Идея заключается в том, что, как полагает Microsoft, прежде чем что-либо вызывается, IIS сначала проверяет, есть ли app_offline.htm, и если да, то отменяет все и отображает его.

Итак, так хорошо, но во многих ситуациях это не работает:

  • Когда у вас есть ошибка компиляции на странице ASPX, и пользователь напрямую связывается с ней.
  • Если у вас конфликтующие сборки
  • Если у вас есть ошибка синтаксического анализа в файле web.config
  • В процессе удаления/загрузки всего сайта.
  • Прямая ссылка на статическую HTML-страницу по-прежнему отображается как таковая
  • Неверные файлы, отказы доступа выдаются до того, как будет показано сообщение.

Возможно, существует больше сценариев, которые терпят неудачу. Я хочу сказать, что для любой серьезной работы по обновлению app_offline.htm не подходит. Я иногда создаю перенаправление в IIS, на другой сайт, но другой сайт может быть не всегда доступен, и он может запутать пользователей.

В идеале я хотел бы сохранить текущее местоположение в строке местоположения URL-адреса конечного пользователя, показать сообщение и автоматически обновлять страницу каждую минуту, чтобы увидеть, вернулся ли сайт, чтобы пользователь продолжается, когда он уходит, когда сайт возвращается. В то время как технически достаточно легко со статической страницей, она будет терпеть неудачу по вышеупомянутым причинам в минуту, когда будет выброшена ошибка.

Ответы

Ответ 1

Никто не упоминает web.config и перекомпиляцию, так что вот оно. Я столкнулся с этой проблемой. Я не согласен с человеком, который сказал, что он "не предназначен для использования prod": VS 2010 использует app_offline при развертывании, поэтому он запекается в коде.

Обходной путь (кредит принадлежит Kurt Schindler, сообщение в блоге здесь).

  • скопируйте app_offline.htm на свой сайт
  • создайте файл web.config, который выглядит так (см. ниже пронумерованный блок)
  • скопируйте файл web.config в удаленный каталог
  • скопируйте все файлы сайта, кроме вашего истинного web.config, до удаленного каталога
  • скопируйте настоящий web.config в удаленный каталог (который должен начинать перекомпилировать)

web.config:

<?xml version="1.0" encoding="utf-8" ?> 
<configuration>
  <system.web>
    <httpRuntime waitChangeNotification="300"
       maxWaitChangeNotification="300"/>
  </system.web>
  <system.webServer>
     <modules runAllManagedModulesForAllRequests="true"  />
  </system.webServer> 
</configuration>

Следствием этого является то, что вы не можете напрямую использовать развертывание приложений VS 2010, если вы беспокоитесь о том, что конечные пользователи не видят YSOD во время развертывания. Для этого вам понадобится использовать Nant или другое средство развертывания.

Ответ 2

Один из способов, с помощью которого я видел это на нескольких сайтах с очень высоким трафиком, - это иметь несколько папок в каталоге inetpub. Что-то вроде:

inetpub
     \ site2011-02-03 
     \ site2011-03-14

Если "site2011-02-03" - это существующий сайт, а "site2011-03-14" - тот, который был нажат сегодня. После того, как нажатие на новую папку будет завершено, вы измените сайт IIS, чтобы указать на новый каталог. В случае сбоя вы меняете IIS на более старую версию.

Совершенно откровенно, я никогда не сталкивался с ошибками, о которых вы говорите при использовании app_offline.htm. Он всегда правильно функционировал, чтобы занять сайт; даже для прямых ссылок на страницы. Я бы предположил, что у вас может быть что-то еще. и я использовал IIS 7 и 7.5 (2008 R2).

Обновление
Просто посмотрел наш конфиг. У нас есть app_offline.htm, отображаемый как верхний по умолчанию документ на наших серверах. Это может быть смягчающим фактором.

Ответ 3

Мне нравится идея использования веб-приложения "офлайн", когда ваше фактическое веб-приложение отключено. Вы должны установить символическую ссылку в своем веб-каталоге, чтобы указать на соответствующее приложение.

Ваша настройка может выглядеть следующим образом:

Web_Dir (это каталог, который IIS обслуживает www.yourdomain.com от)
WebApps

  • ActualWebApp
  • OfflineWebApp

Сценарий: ваше приложение онлайн
Web_Dir → ActualWebApp (Web_Dir связан с ActualWebApp)

Сценарий: ваше приложение отключено
Web_Dir → OfflineWebApp (Web_Dir связан с OfflineWebApp)

По сути, вы получаете два разных веб-приложения: фактическое веб-приложение и "автономное" веб-приложение. Это дает вам возможность перенаправлять пользователей на другой сайт, но поддерживает внешний вид вашего домена - потому что это!

Фактическое веб-приложение - настоящее веб-приложение. Это тот, который вы вносите изменения, и тот, который имеет ваш фактический контент.

Веб-приложение "offline" имеет очень мало контента. Возможно, он содержит только статическую страницу, указанную в вашем вопросе. Возможно, он имеет некоторую маршрутизацию для обработки любого запроса страницы, отображения автономного сообщения и перезагрузки каждую минуту.

Ваш веб-каталог IIS на самом деле является ссылкой на одно из этих двух веб-приложений. Как правило, он будет связан с вашим фактическим веб-приложением. Когда вы будете готовы начать (повторное) развертывание своего веб-приложения, вы меняете свой веб-каталог, вместо этого указываете на "офлайн". По завершении развертывания вы измените ссылку назад, чтобы снова указать на реальное веб-приложение.

Ответ 4

Я не думаю, что app_offline.htm был предназначен для использования в целях производства.

Моим решением было бы создать отдельное веб-приложение с модулем, который ловит все запросы и перенаправляет их на статическую страницу .htm с строкой запроса запрашиваемого сайта и некоторым javascript для повторения исходного запроса.

Когда вы будете готовы выполнять техническое обслуживание, настройте фиктивное приложение для обработки всех запросов в вашем домене. Используйте другой порт или временный домен, пока вы выполняете техническое обслуживание, чтобы вы могли протестировать. Как только вы закончите, переключите их обратно, и пользователи, которые решили подождать, должны быть перенаправлены на их первоначально запрошенную страницу.

Я делал только половину этого (переключая порты приложений, чтобы включить обновленный сайт), поэтому для получения желаемого пользовательского интерфейса могут быть другие шаги.

Надеюсь, что это поможет.

Ответ 5

В нашем случае app_offline.htm не работал, пока мы не прокомментировали раздел нашей страницы web.config. С его раскомментированием он перенаправляет на страницу ошибки, которую мы определили, а не app_offline.htm, как и ожидалось.

Ответ 6

Старый пост, я знаю, но я еще не видел этого:

  • Создайте новый сайт с помощью app_offline.htm.
  • Добавьте app_offline.html обновляемый сайт.
  • Удалить привязку с обновляемого сайта.
  • Добавить привязку к сайту appOffline.
  • Добавьте специальную привязку к целевому сайту (используя порт # или другой URL-адрес тщеславия, выполните фильтрацию ip или что-то еще, что вам нужно.)
  • Сделайте проверку на целевом сайте.
  • Восстановить привязку с appOffline до целевого сайта.