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

Как сделать так, чтобы CMS и существующие приложения asp.net мирно сосуществовали в IIS?

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

Поскольку CMS будет находиться в корне веб-сайта, я предполагаю, что запускать наши существующие страницы и веб-приложения под Umbraco - плохая идея (из-за того, что он выполняет перезапись URL и наследует настройки web.config и т. Д.). сделать так, чтобы все мирно сосуществовало как при переходе на CMS, так и после завершения?

Моя единственная идея до сих пор заключалась в том, чтобы настроить CMS и приложения как отдельные веб-сайты, а затем использовать какой-то переписывающий URL / обратный прокси-сервер, чтобы все разрешалось правильно:

Я сталкивался с этой ситуацией несколько раз, и если вы не собираетесь настраивать разные поддомены, например

  • sub1.example.com (umbraco)
  • www.example.com
  • www.example.com/dept1

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

Перезапись URL-адреса не является такой проблемой, если вы добавляете имя корневой папки каждого дочернего приложения в каталоги umbracoreservedurls /.

Я знаю, что это боль - к сожалению, сейчас Umbraco работает именно так.

Я повторяю комментарии Нила, но отвечу как ответ, чтобы лучше отформатировать свой ответ.

Вот вам правило URL Rewrite 2.0:

RewriteCond  Host:  (www\.)?domain\.com
RewriteRule  (?!/domain)(.*)   /domain$2 [I]

Поместите свой сайт в папку с именем / domain. Очевидно, вы можете изменить URL-адрес и папку.

Это гарантирует, что все, что связано с / domain, не перенаправляет, но все остальное делает. Это позволяет перенаправлениям asp.net и другим вещам, о которых URL Rewrite не знает, по-прежнему работать.