Мне интересно, есть ли событие, которое можно обработать, или метод, который можно переопределить, который происходит до того, как файл Web.config будет проанализирован и отслежен жизненным циклом приложения asp.net 3.5 / AppDomain.
Практическая причина этого заключается в том, что я хотел бы иметь возможность записывать файл Web.config из копии в базе данных, когда приложение запускается, в зависимости от среды развертывания. Причина этого в том, что у нас есть процесс развертывания приложений вручную и веб-ферма. Web.config изменения часто падают через трещины или не распространяются на все серверы веб-фермы из-за ручного процесса. К сожалению, в обозримом будущем мы остановимся на ручном развертывании. В таком случае было бы замечательно, если бы у приложения был способ получить свою веб-конфигурацию при первом запуске. Если бы я мог заставить это работать, то следующим логичным шагом было бы создание зависимости / уведомления SQL, чтобы вызвать выгрузку AppDomain при каждом изменении файла конфигурации в базах данных, чтобы новые изменения извлекались и записывались.
Пока что единственный способ, которым я понял, как это сделать, - это сделать что-то вроде нижеприведенного psuedocode, который имеет неприятный побочный эффект, вызывая два цикла загрузки приложения за попытку запуска. Кроме того, я почти уверен, что первый запрос, который приходит, если приложение бездействует, пойдет дымом из-за перезапуска.
// PSEUDOCODE
// In global.asax.cx
protected void Application_Start(object sender, EventArgs e)
{
bool loadConfigFileFromDB = GetConfigLoadOptionFromLoadOptionsConfigFile();
string webConfigPath = GetWebConfigPath();
if (loadConfigFileFromDB) // Most likely false in development so debugging works
{ // with a local web.config
if (File.Exists(webConfigPath)) // We are not starting up for the first time
{ // since app was deployed
if (File.GetCreationTime(webConfigPath) < DateTime.Now.AddMinutes(-1))
{
// Web config is more than a minute old, so chances are we
// aren't in an app restart after writing the config.
WriteWebConfigFromDatabase(); // This will cause a restart.
}
// else, web.config was probably just written and we are in a
// restart after writing the config. In this case, let the application continue on
}
else // First time starting up, so it's safe to assume we can write
{ // the config and restart.
WriteWebConfigFromDatabase(); // This will cause a restart.
}
}
}
Очевидно, что задача сборки или развертывания была бы лучшим способом справиться с заменой Web.config для каждой среды, но, к сожалению, я не в такой ситуации.
EDIT
Смысл этого состоит не в том, чтобы иметь динамические настройки во время работы приложения, а в том, чтобы помочь управлять различными файлами Web.config для среды (Stage / QA / Production). Например, в отдельном файле, отличном от Web.config, у нас будет параметр среды. После развертывания, когда приложение запустится, оно будет использовать параметры в этом файле (среду и строку подключения), чтобы вытащить и написать веб-конфигурацию для этой среды. Настройки не будут динамическими после запуска приложения.