VirtualPathProvider не работает в IIS 7.5 - PullRequest
Новая
       25

VirtualPathProvider не работает в IIS 7.5

2 голосов
/ 17 ноября 2011

Я работал над проектом, который имеет общие функциональные возможности, в частности, я хотел поделиться мастер-файлом и связанными изображениями / js / etc. С этой целью главная страница и ее зависимые файлы упакованы в «глобальную» DLL, которая используется всеми «подпроектами». Все это отлично работало в разработке, но развертывание принесло сюрприз, который, кажется, застал многих врасплох: VirtualPathProvider не работает при предварительной компиляции.

Теперь благодаря этому сообщению в блоге, содержащему обходной путь Я смог дать еще одну попытку заставить его работать. К сожалению, это все еще не.

Я решил избавиться от своей Global.asax реализации и выбрал AppInitialize подход в блоге: 

public static class AppStart
{
    public static void AppInitialize()
    {
        HostingEnvironment hostingEnvironmentInstance = (HostingEnvironment)typeof(HostingEnvironment).InvokeMember("_theHostingEnvironment", BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField, null, null, null);
        MethodInfo mi = typeof(HostingEnvironment).GetMethod("RegisterVirtualPathProviderInternal", BindingFlags.NonPublic | BindingFlags.Static);
        mi.Invoke(hostingEnvironmentInstance, new object[] { new MasterPageProvider() });
    }
}

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

Интересным аспектом всей этой ситуации является то, что при производстве не возникает ошибок, связанных с невозможностью найти главную страницу. Для меня это означает, что поставщик работает, но по какой-то причине остальные ресурсы (js / css / etc) не извлекаются из сборки должным образом.

Итак, мой вопрос сводится к следующему: каковы причины того, что это решение будет прекрасно работать при разработке, но не при работе на IIS 7.5?

ОБНОВЛЕНИЕ 11/20/2011

Попробовал предложение Дэвида Эббо и, к сожалению, безрезультатно. Мой веб-конфиг теперь выглядит примерно так: 

<configuration>
    <connectionStrings>
        <clear />
        <!-- ... -->
    </connectionStrings>
    <system.web>
        <pages>
            <controls>
                <!-- ... -->
            </controls>
        </pages>
        <compilation debug="true" targetFramework="4.0" />
        <webServices>
            <protocols>
                <add name="HttpGet"/>
                <add name="HttpPost"/>
            </protocols>
        </webServices>
    </system.web>
    <system.webServer>
        <modules runAllManagedModulesForAllRequests="true" />
    </system.webServer>
</configuration>

ОБНОВЛЕНИЕ 11/21/2011

Просто чтобы подтвердить мое подозрение, что VirtualPathProvider действительно работал, я закомментировал третью строку (mi.Invoke(....) и повторно развернул сайт. Как я и подозревал, теперь он ломается из-за невозможности найти файл MasterPage. Эта проблема, по-видимому, связана только со статическими файлами, доставляемыми через VPP.

Ответы [ 3 ]

3 голосов
/ 22 ноября 2011

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

<system.webServer>
    <handlers>
        <add name="Images" path="*.png" verb="GET,HEAD,POST" type="System.Web.StaticFileHandler" modules="ManagedPipelineHandler" resourceType="Unspecified" />
        <add name="Stylesheets" path="*.css" verb="GET,HEAD,POST" type="System.Web.StaticFileHandler" modules="ManagedPipelineHandler" resourceType="Unspecified" />
     </handlers>
 </system.webServer>
2 голосов
/ 22 ноября 2011

Взгляните на этот пост .В нем объясняется, как получить статические файлы через поставщика виртуальных путей в IIS 7. Я считаю, что это решит вашу проблему.

2 голосов
/ 20 ноября 2011

Возможно, проблема в том, что запросы на статические файлы не проходят через ASP.NET по умолчанию в IIS.

Попробуйте, поможет ли включение runAllManagedModulesForAllRequests в web.config. например, 

<modules runAllManagedModulesForAllRequests="true" />
...