У меня проблема с установкой веб-приложения в IIS 7.5. Я использую стандартную сборку установщика веб-приложений с VS2010, но когда я устанавливаю приложение, я хочу, чтобы оно размещалось в корне сайта (а не внутри виртуальной папки). Вот небольшая схема установки:
Каждое из приложений имеет собственный пул приложений. Статическая папка использует основной пул приложений, который используется по умолчанию для всего сайта.
Если я запустил установщик и оставлю поле виртуального каталога пустым, все будет работать нормально. Проблема в том, что каким-то образом все мои другие приложения перемещаются в пул приложений по умолчанию и в конечном итоге ломаются, потому что разрешения относительно ограничены.
Кто-нибудь знает способ обойти это? Я не хочу, чтобы пользователи вводили .../static/...
в URL-адресе сайта, поэтому простая установка в виртуальный каталог "обычным" способом не сработает.
Спасибо,
- Дэн
После долгих исследований я думаю, что есть ошибка либо в установщике веб-приложения, либо в самом IIS. Поскольку я пока застрял с установщиками веб-приложений, вот как я это обошел:
C:\inetpub\wwwroot
(в любом случае это значение по умолчанию)static
быть таким же (/*)(.*)
{URL}
Не совпадает ^(/*)app1/(.*)
{URL}
Не совпадает ^(/*)app2/(.*)
/static/{R:2}
В моем случае мне не нужны были правила для исходящего трафика (т.е. мне не нужен был полный обратный прокси), потому что мои приложения возвращают действительные URL-адреса.
Преимущество этого решения в том, что оно полностью прозрачно для пользователя, и любые существующие ссылки, начинающиеся с / (т.е. ...a href="/images/file.jpg"...
) по-прежнему будет работать, потому что когда конечный пользователь запрашивает /images/file.jpg
URL-адрес будет внутренне переписан на /static/images/file.jpg
.
Основным недостатком является то, что я должен постоянно обновлять список шаблонов соответствия для всех пулов приложений. Но в моем случае это не имеет большого значения. На самом деле я мог бы автоматизировать внедрение новых строк шаблона в web.config
файл - но в моем случае это не имеет большого значения.
Еще одним недостатком является то, что пользователь мог видеть ссылки на /static/images/...
в исходном коде - но меня это особо не волнует.
Итак - надеюсь, это поможет кому-то в будущем.