Все мои сайты Asp.Net используют отдельную систему конфигурации, управляемую файлами XML, которая отвечает за создание огромного количества объектов, используемых на сайтах; фактически серия uber-контейнеров IOC может использоваться для решения любых задач - от контроллеров для сайтов MVC до служб данных и объектов конфигурации для внутреннего кода.
XML создает группу динамических методов, которые затем скрываются за фабричным интерфейсом. После загрузки и сборки эти методы не будут перестроены до тех пор, пока домен приложения не будет перезагружен.
Таким образом, наименьшее изменение в одном из файлов может оказать глубокое влияние на функциональность веб-сайта, и поэтому обновления часто можно развернуть как простое изменение конфигурации. Файлы могут появляться в корневом каталоге веб-сайта и в любой дочерней папке в нем, но не в обычных папках Asp.Net (App_LocalResources и т. Д.).
Но поскольку файлы не используют расширение, которое Asp.Net/IIS распознает как «важное» (скажем, расширение .configfoo
), если я изменю одно из них, мне придется вручную обеспечить домен приложения перезапустите на сервере:
a) Коснитесь web.config, чтобы принудительно перезапустить AppDomain; или
b) Перекомпилируйте двоичные файлы
Что я хотел бы сделать, так это как-то сказать Asp.Net/IIS включить эти файлы в свой мониторинг и рассматривать их как как важные как файлы .config и файлы .dll в корзине папки; запуск перезапуска домена приложения при изменении любого из них.
ОБНОВЛЕНИЕ в ответ на ответ Артема
Я пытался поместить файлы либо в bin\
, либо в App_LocalResources
, например, и действительно, перезапуск AppDomain - это хорошая новость, но ... мне не нравится развертывание bin\
потому что единственный способ легко обновить файл в процессе разработки - это сделать сборку (если вы не копируете / вставляете вручную), и это также не соответствует концепции того, что эти файлы являются содержимым - то, чем они на самом деле являются и нуждаются следует рассматривать как с точки зрения развертывания.
Точно так же решение App_LocalResources
(и др.) Великолепно, но не является естественным с точки зрения разработчика - это файл конфигурации, и поэтому его можно размещать в том же месте, что и другие файлы конфигурации (есть также небольшое дело, что VS, похоже, не видит мой шаблон элемента, который я сделал, если я добавляю в эту папку из-за его контекстно-зависимого диалога добавления нового элемента).
Наконец, это не решает проблему других папок произвольной формы, которые могут быть в проекте, которые могут содержать файлы .configfoo
наряду с файлами aspx / ascx / master / .config и т. Д. Если только я не заставлю все эти папки помещаться внутри одна из папок Asp.Net, конечно, но никто не ожидает найти страницу внутри App_LocalResources
!
END Update
Неудача - я помню, что пару лет назад я видел немного кода, где использовался FileSystemWatcher
, который вызвал AppDomain.Unload
внутри самого сайта в соответствии с его собственными правилами на основе файлов. Я думаю, что предпочтительный метод сейчас будет использовать System.Web.Hosting.HostingEnvironment.InitiateShutdown
.
Это будет мое последнее средство, так как я не решаюсь катиться самостоятельно, когда я уже знаю, что то, что я хочу, уже выполняется для некоторых других расширений.
Так возможно ли добавить другие файлы зависимостей к наблюдаемым? Или мне придется самому катиться?
Любой совет, как всегда, высоко ценится