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

Традиционное приложение ASP.NET в подкаталоге приложения MVC

Windows Server 2003, IIS6.

Мы пытаемся развернуть веб-приложение ASP.NET, не являющееся MVC, в качестве подкаталога приложения MVC.

Однако приложение ASP.NET в подкаталоге выдает сообщение «Не удалось загрузить файл или сборку» System.Web.Mvc, Version = 1.0.0.0, Culture = нейтральный, PublicKeyToken = 31bf3856ad364e35 или одной из его зависимостей. Система не может найти указанный файл. " что странно, потому что это не приложение MVC.

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

Таким образом, мы переместили суб-приложение в субдомен и добавили перенаправление для этого подкаталога в маршрутах родительского приложения.

Нужно больше информации:

  1. Дочернее (подпапка) веб-приложение ASP.NET работает в собственном приложении IIS или в родительском приложении IIS?

  2. Где System.Web.Mvc.dll развернут?

Если # 1 неверно (т.е. такое же приложение IIS), то требование для System.Web.Mvc наследуется от родителя web.config.

Я только что столкнулся с такой же ошибкой для другой сборки в очень похожей ситуации:

  • IIS 8.5
  • сайт, на котором запущено приложение ASP.NET MVC
  • виртуальное приложение под ним, называемое app, в нашем случае также приложение MVC

Однако в нашем случае виртуальное приложение не загрузилось, потому что Microsoft.Owin.Host.SystemWeb.dll версия 3.0.0.0 не удалось загрузить. У нас действительно была версия 3.0.1.0 сидя там, но даже с перенаправление сборки в web.config это не поможет. Это корневое приложение использовало версию 3.0.0.0.

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

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

Теперь это подразумевало запуск внутри виртуальной папки, назовем это w. Недостающей частью головоломки теперь была переписать правило чтобы сопоставить корень сайта с этой виртуальной папкой w. Я поместил это правило в новый web.config в пустой корневой папке сайта. Вот как это выглядит:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Rewrite / to /w" stopProcessing="true">
          <match url="^$" />
          <action type="Rewrite" url="/w" logRewrittenUrl="true" />
        </rule>
        <rule name="Rewrite rest to /w/rest" stopProcessing="true">
          <match url="^(/.*)$" />
          <action type="Rewrite" url="/w{R:0}" logRewrittenUrl="true" />
          <conditions>
            <add input="{REQUEST_URI}" pattern="(^w$|^w/)|(^app/)" negate="true" />
          </conditions>
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

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

Вот что у нас есть:

  • запросы на www.mydomain.com переписать на www.mydomain.com/w и впоследствии обрабатывается нашим первым виртуальным приложением w которое раньше было нашим корневым приложением
  • запросы на www.mydomain.com/app обрабатываются нашим виртуальным приложением app как и ожидалось

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