#c# #asp.net #iis #iis-7
#c# #asp.net #iis #iis-7
Вопрос:
У меня есть два веб-сайта в IIS, такие как
http://domainA.com
http://domainB.com
Я хотел бы использовать один и тот же код для этих веб-сайтов, но разные файлы web.config. Возможно ли это? Я храню строки подключения к базе данных и т.д. В файлах web.config, весь остальной код в приложениях одинаковый.
Я пробовал несколько разных подходов к созданию структуры папок, например
-Root
- Domain A
- web.config for domain A
- Code
- Virtual Directory to Source Code
- Domain B
- web.config for domain B
- Code
- Virtual Directory to Source Code
- Source Code
Затем я укажу веб-сайту для домена A на «Root / Domain A», а домену B — на «Root / Domain B», но проблема в том, что доступ к коду должен быть на один уровень ниже, например
http://domainA.com/Code/
http://domainB.com/Code/
Есть идеи?
Комментарии:
1. Почему вы не хотите просто опубликовать веб-сайт в двух местах?
2. Сегодня у меня всего два веб-сайта, но я думаю, что в будущем их будет больше. Важно, чтобы веб-сайты всегда работали и имели последнюю версию кода, поэтому я хочу максимально упростить процесс развертывания.
Ответ №1:
Я буду основывать свой ответ на предположении, что вы пишете пользовательский код, а не используете готовое решение, такое как DNN или SharePoint.
Одно из решений, которое приходит на ум для сохранения общей базы кода, — это сохранить параметры конфигурации вашего веб-сайта в вашей базе данных вместо web.config. Вы можете поддерживать структуру своей базы данных достаточно динамичной, используя набор пар имя / значение. Вам, конечно, нужно будет учесть это при разработке вашего приложения и спланировать его в вашей базе данных. Это дает вам преимущество наличия только одной базы кода, а также единого web.config. Если вам необходимо поддерживать содержимое в отдельных базах данных для каждого сайта, информация о строке подключения к этим базам данных контента может быть одной из пар имя / значение в вашей базе данных конфигурации.
Вы даже можете сделать еще один шаг вперед, создав единый веб-сайт в IIS для всех доменов (если вы не будете использовать SSL, в этом случае отдельные сайты IIS были бы лучше). Вам нужно будет добавить заголовки host на веб-сайт, а затем искать заголовок host в вашем коде, чтобы определить, какие настройки использовать и какой контент обслуживать. Вы потеряете возможность создавать отдельные пулы приложений, поэтому вам следует проверить свои требования, если это приемлемый вариант для вашей ситуации.
На самом деле это модель, аналогичная тому, как работают DNN и SharePoint, но, безусловно, может быть реализована и в пользовательском приложении.
Комментарии:
1. Итак, позвольте мне посмотреть, правильно ли я вас понял, Роб … ваше предложение состоит в том, чтобы заново изобрести колесо (
This is actually a similar model to how both DNN and SharePoint work but can certainly be done in a custom application as well.) вместо того, чтобы учиться использовать существующую систему?2. Пожалуйста, обратите внимание на предположение, которое я сделал в своем первом предложении. Я не говорю заново изобретать колесо. Я говорю, что и DNN, и SharePoint используют модель, аналогичную той, что я предлагал (хотя их реализации отличаются). Требования к приложению могут полностью отличаться от тех, для которых предназначены DNN или SharePoint, и может не иметь смысла использовать один из них. Если одна из этих платформ соответствует потребностям, то наверняка вам следует использовать одну из них, но если у вас есть пользовательские функции, то я предлагаю модель, которая может сработать.
3. Заголовки хостов могут быть способом продвижения вперед. Я попробую и посмотрю, сработает ли это. Спасибо за комментарий.
4. @Cos: Я не хотел повышать голос за ваш комментарий.. Я пропустил кнопку рядом с ним. К сожалению, похоже, что нет способа отменить мой отзыв: (