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

Question

У нас есть устаревший сайт с поддержкой ASP.net, работающий на сервере IIS, сайт был разработан центральной командой и используется несколькими клиентами. Однако у каждого клиента есть своя собственная копия aspx-файлов сайта и файл web.config. Это вызывает проблемы, так как изменения, сделанные добросовестными инженерами поддержки в копии исходных файлов ASPX, не складываются обратно в центральный источник, поэтому наша база кода расходится. Наша текущая структура папок выглядит примерно так: OurApp / Source aspx & default web.config
Customer1 / Source aspx & web.config
Customer2 / Source aspx & web.config
Customer3 / Source aspx & web.config
Customer4 / Source aspx & web.config
...

Это то, что я хотел бы изменить, чтобы каждый клиент имел только настроенный файл web.config, а все клиенты имели общий набор исходных файлов. Так что-то вроде: OurApp / Source aspx & default web.config
Customer1 / web.config
Customer2 / web.config
Customer3 / web.config
Customer4 / web.config
...

Итак, мой вопрос, как мне это настроить? Я новичок в ASP.net и IIS, так как обычно дома использую php и apache, но здесь мы используем ASP.net и ISS.

---

Используется система контроля версий, и я намерен переподготовить инженеров службы поддержки, но есть ли способ избежать создания нескольких копий исходных файлов aspx? Я ненавижу такого рода дублирование!

Answer 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 и Other. Когда к Свойству обращаются или устанавливают, используйте условие (домен запроса или что-то еще, что однозначно идентифицирует Клиента), чтобы решить, какой использовать.

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

Answer 2

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

Держать сайты отдельно - это действительно хорошо. Хотя это выглядит как «дублирование», на самом деле это не так. Это разделение . Внесение изменений в производственный код вашими инженерами службы поддержки не должно поощряться.

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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

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

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

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

Дайте мне знать, если я что-то упустил!

Answer 8

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