Назад | Перейти на главную страницу

Установка на веб-сайт по умолчанию перемещает пулы приложений

У меня проблема с установкой веб-приложения в IIS 7.5. Я использую стандартную сборку установщика веб-приложений с VS2010, но когда я устанавливаю приложение, я хочу, чтобы оно размещалось в корне сайта (а не внутри виртуальной папки). Вот небольшая схема установки:

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

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

Кто-нибудь знает способ обойти это? Я не хочу, чтобы пользователи вводили .../static/... в URL-адресе сайта, поэтому простая установка в виртуальный каталог "обычным" способом не сработает.

Спасибо,

- Дэн

После долгих исследований я думаю, что есть ошибка либо в установщике веб-приложения, либо в самом IIS. Поскольку я пока застрял с установщиками веб-приложений, вот как я это обошел:

  1. Папка по умолчанию IIS перемещена в C:\inetpub\wwwroot (в любом случае это значение по умолчанию)
  2. Установите пулы приложений для всего сайта и static быть таким же
    1. IIS не позволит вам переписывать URL-адреса в пулах приложений. Если это вызывает беспокойство - вам придется настроить полноценный обратный прокси.
  3. Установлен плагин IIS URL Rewrite.
  4. Создано новое правило перезаписи URL с шаблоном соответствия (/*)(.*)
  5. В правило добавлены следующие условия (соответствие всем)
    1. Ввод {URL} Не совпадает ^(/*)app1/(.*)
    2. Ввод {URL} Не совпадает ^(/*)app2/(.*)
    3. ... По одному на каждое приложение ... (да, это больно)
  6. Установите действие Переписать на /static/{R:2}

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

Преимущество этого решения в том, что оно полностью прозрачно для пользователя, и любые существующие ссылки, начинающиеся с / (т.е. ...a href="/images/file.jpg"...) по-прежнему будет работать, потому что когда конечный пользователь запрашивает /images/file.jpg URL-адрес будет внутренне переписан на /static/images/file.jpg.

Основным недостатком является то, что я должен постоянно обновлять список шаблонов соответствия для всех пулов приложений. Но в моем случае это не имеет большого значения. На самом деле я мог бы автоматизировать внедрение новых строк шаблона в web.config файл - но в моем случае это не имеет большого значения.

Еще одним недостатком является то, что пользователь мог видеть ссылки на /static/images/... в исходном коде - но меня это особо не волнует.

Итак - надеюсь, это поможет кому-то в будущем.