Несколько веб-сайтов, одна общая кодовая база и разные файлы конфигурации

Question

У меня есть два веб-сайта в 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 /Домен B ", но проблема в том, что код должен быть доступен на один уровень ниже, как

http://domainA.com/Code/
http://domainB.com/Code/

Есть идеи?

Answer 1

Я буду основывать свой ответ на предположении, что вы пишете собственный код, а не используете готовое решение, такое как DNN или SharePoint.

Одним из решений, которое приходит на ум для сохранения общей базы кода, является сохранение определенных настроек конфигурации вашего сайта в вашей базе данных вместо web.config. Вы можете поддерживать динамическую структуру базы данных, используя набор пар имя / значение. Вам, конечно, нужно учитывать это при разработке приложения и планировать его в своей базе данных. Это дает вам преимущество, заключающееся в том, что у вас есть только одна база кода и один файл web.config. Если вам нужно поддерживать контент в отдельных базах данных для каждого сайта, информация о строке подключения к этим базам данных контента может быть одной из пар имя / значение в вашей базе данных конфигурации.

Вы даже можете продвинуться на этот шаг вперед, имея единый веб-сайт в IIS для всех доменов (если только вы не будете использовать SSL, в этом случае отдельные сайты IIS будут лучше). Вам необходимо добавить заголовки узлов на веб-сайт, а затем найти заголовок узла в своем коде, чтобы определить, какие настройки использовать и какой контент обслуживать. Вы потеряете возможность создавать отдельные пулы приложений, поэтому вам следует проверить свои требования, если это целесообразный вариант для вашей ситуации.

На самом деле эта модель похожа на работу DNN и SharePoint, но, безусловно, может быть выполнена и в пользовательском приложении.