Единственный сайт ASP.net с Несколькими Экземплярами и web.configs

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

Это не действительно хорошая идея позволить Вашему живому сайту быть обновленным инженерами службы поддержки в режиме реального времени так или иначе.

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

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

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

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

Необходимо смотреть на изменение процесса для изменения, однажды развертываются везде. Это сделает все намного легче для Вас в конечном счете.

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

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

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

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

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

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

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

Использование WebConfigurationManager. OpenWebConfiguration, я открываю новый webconfigs в их подкаталогах. Я определяю который использовать при помощи Системы. Сеть. HttpContext. Текущий. Запрос. URL. OriginalString и определение URL, который позвонил мне. На основе того URL я знаю который web.config использовать.

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

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

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

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

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

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

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

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

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

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

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

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

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