2012-02-16 2 views
1

Запуск IIS 6 с основным веб-сайтом с использованием .net 4. У меня есть много субсайтов под этим главным образом запущенным .net 4 и при просмотре им default.aspx автоматически загружается без проблем , Один из веб-сайтов, однако, работает .net 3.5 и default.aspx не будет загружаться сам по себе при просмотре на открытый URL: http://127.0.0.1/TestApp Однако, если я просматриваю файл напрямую, он отлично работает: http://127.0.0.1/TestApp/Default.aspx.Страница Default.aspx не загружается на IIS 6

Глядя на документы под веб-приложением .net 3.5, он показывает Default.aspx как «включенную страницу контента по умолчанию». Если я переключу приложение на .net 4.0, страница default.aspx загрузится автоматически. Я не могу сохранить этот параметр, потому что это скомпилированное веб-приложение и ошибки на некоторых страницах и не имеют доступа к обновлению кода.

Кто-нибудь видел эту проблему и знает, как ее решить? Любая помощь/идеи были бы замечательными!

Спасибо!

EDIT

Ошибка Page ресурс не может быть найден. Описание: HTTP 404. Ресурс, который вы ищете (или его зависимости), мог быть удален, изменилось его имя или временно недоступно. Просмотрите следующий URL-адрес и убедитесь, что оно написано правильно.

Запрошенный URL: /licensure/eurl.axd/ce90d150037c2545966c2948cd3e2e7e/


Информация о версии: Microsoft .NET Framework версии: 2.0.50727.3053; ASP.NET версии: 2.0.50727.3053

+0

Действительно ли 'Default.aspx' находится в верхней части списка документов по умолчанию? Кроме того, рекомендуется разместить это приложение в другом пуле приложений из ваших приложений .NET 4. Вы это сделали? –

+0

Да, это наверху, и у него есть собственный пул приложений. В приведенном ниже ответе была исправлена ​​проблема. – Clarke76

ответ

3

Вы можете увидеть на сайте: http://www.vanadiumtech.com/OurBlog/post/2011/08/12/Cause-of-eurlaxd.aspx

Представляется, что это связано с .NET 4 в extensionless URL.

Из приведенной выше связанной страницы страницы:

Рекомендуемые решения

Если отключить v4.0 ASP.NET extensionless URL функцию на IIS6, установив параметр DWORD в HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ ASP.NET \ 4.0.30319.0 \ EnableExtensionlessUrls = 0 и перезапустите IIS, тогда функция ASP.NET будет отключена, и вы не увидите «/eurl.axd/GUID» в своих URL-адресах, если только злоумышленник такие запросы к наш сервер.

Наша Фикс

В нашем случае решение пришло из HeliconTech, который является поставщиком нашего Rewrite модуля IIS

http://www.helicontech.com/forum/15029-ASPNET_40_MVC_and_ISAPI_Rewrite_3.html

Мы обнаружили, что eurl.axd в настоящее время добавляется, когда мы делали перенаправление . Eurl.axd был добавлен перед перенаправлением, поэтому isapi включает в себя его, как если бы он был правильной частью URL-адреса.

Например, мы перенаправляем www на не-www. Чтобы игнорировать eurl.axd part, мне пришлось изменить правило:

RewriteCond% {HTTPS} (on)? RewriteCond% {HTTP: Host}^www. (. +) $ [NC] RewriteCond% {REQUEST_URI} (. +)? (. ) RewriteRule^(eurl.axd/.) $ HTTP (% 1s?): //% 2/$ 1 [R = 301, L]

Если вы хотите пойти в другую сторону, и перенаправлять не-www на www, это легкое изменение:

RewriteCond% {HTTPS} (on)? RewriteCond% {HTTP: Host}^(! Www.) (. +) $ [NC] RewriteCond% {REQUEST_URI} (. +)? (. ) RewriteRule ^ (eurl.axd/.) $ HTTP (% 1s?): //www.%2/$1 [R = 301, L]

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

+0

Работал как шарм. Спасибо за быстрый ответ! – Clarke76

Смежные вопросы