Один сайт ASP.net с несколькими экземплярами и web.configs

Ответ 1

Если вы умерли на одном экземпляре приложения, вы можете выполнить то, что вы используете, используя настраиваемое ConfigurationSection в своем единственном web.config. Основные сведения см. В разделе

• http://haacked.com/archive/2007/03/12/custom-configuration-sections-in-3-easy-steps.aspx
• http://msdn.microsoft.com/en-us/library/2tw134k3.aspx

Пример XML может быть:

<YourCustomConfigSection>
   <Customers>
     <Customer Name="Customer1" SomeSetting="A" Another="1" />
     <Customer Name="Customer2" SomeSetting="B" Another="2" />
     <Customer Name="Customer3" SomeSetting="C" Another="3" />
   </Customers>
</YourCustomConfigSection>

Теперь в свойствах ConfigSection выведите Name, SomeSetting и другое. Когда свойство доступно или установлено, используйте условие (домен запроса или что-то еще, что однозначно идентифицирует Клиента), чтобы решить, что использовать.

При правильной реализации разработчикам приложений не нужно знать, что происходит за кулисами. Они просто используют CustomSettings.Settings.SomeSetting и не беспокоятся о том, какой клиент обращается к приложению.

Ответ 2

Я знаю, что это может показаться раздражающим, но дублирование на самом деле - хорошая вещь. Проблема здесь в вашем процессе, а не в том, как настроены системы.

Сохранение отдельных сайтов на самом деле хорошо. Хотя это похоже на "дублирование", на самом деле это не так. Это разделение. Внедрение изменений в производственном коде со стороны ваших инженеров поддержки должно быть активно обескуражено.

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

Чтобы ответить на ваш вопрос, ответ - нет, вы не можете этого сделать. Причина в том, что web.config не предназначен для хранения настроек уровня пользователя, который предназначен для хранения настроек экземпляра приложения. В вашем случае вам нужен экземпляр приложения для каждого пользователя, что означает отдельные файлы конфигурации.

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

Ответ 3

Используйте внешнее приложение управления версиями и продолжайте обновлять обновления по мере необходимости.

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

Ответ 4

Ну, вы можете попытаться использовать hardlinks: http://msdn.microsoft.com/en-us/library/aa365006.aspx ... вы просили об этом.

Другой вопрос, который может представлять интерес: Методы распределения пользовательских элементов управления ASP.NET в разных проектах

Ответ 5

В зависимости от того, что на самом деле находится в веб-конфигурации, и какие настройки отличаются от клиентов, вы можете выбрать одну веб-конфигурацию и сохранить другие параметры конфигурации для конкретного клиента в базе данных или в другом пользовательском XML файле. Пока конкретные настройки клиента в web.config не должны ничего делать с тем, как работает IIS, и вы просто используете его для хранения значений, то это решение может сработать для вас.

Ответ 6

Если я правильно понимаю, похоже, что у вас несколько развертываний (по одному для каждого клиента), где единственное отличие - это web.config, правильно?

Во-первых, хотя я не знаю вашей уникальной ситуации, я обычно призываю вас остаться с отдельными установками. Это обычно обеспечивает гораздо большую гибкость. В верхней части моей головы: у вас когда-нибудь будут настройки или разные клиенты, работающие с разными версиями? Ты уверен? Самый простой способ оставаться гибким здесь - это продолжать отдельные установки.

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

Тем не менее, скажем, вы хотите двигаться вперед с этим.

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

Это означает, что вы где-то храните строку подключения. Обычно это будет web.config... Так что это, по-видимому, нарушает наш план.

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

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

Сообщите мне, если я что-то упустил!

Ответ 7

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

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

Ответ 8

Я реализую это, когда мы говорим.

В основном web.config у меня есть 1 элемент для каждой установки. Он указывает мне на пользовательский файл конфигурации, который я создал для каждого клиента (и к пользовательской главной странице, css, изображениям и т.д.).

Используя WebConfigurationManager.OpenWebConfiguration, я открываю новые webconfigs в своих подкаталогах. Я определяю, какой из них следует использовать с помощью System.Web.HttpContext.Current.Request.Url.OriginalString и определения вызываемого мной uRL. Основываясь на этом URL-адресе, я знаю, какой web.config использовать.

С этой точки зрения клиенты все используют одну и ту же базу кода. У них также есть собственные базы данных.

Идея обновить 30-40 установок, когда мы делаем обновление, пугает меня смертью. Мы не хотим поддерживать 30-40 кодовых баз, поэтому не будет настройки за пределами главной страницы, css и изображений.

Я написал пользовательский класс lib, который знает, как переключиться на правильный webconfig, и прочитайте раздел, который я создал со всеми нашими настройками.

Единственная проблема, с которой я столкнулся сейчас, - это Cookie FormsAuthentication. Мне нужно также переключить это. К сожалению, свойство для имени доступно только для чтения