Перемещение файла app.config в произвольный путь

Question

Можно ли переместить весь файл App.Config в произвольный путь?

Кажется немного странным, что файл конфигурации находится в той же папке, что и exe, с новым подходом Windows сохранения всех настроек программы в c: \ ProgramData и всех.

Дополнительное требование, которое у нас есть, - это программно указать, где найти файл app.config. Причиной этого является то, что мы порождаем разные экземпляры служб из одних и тех же файлов и хотели бы сохранить файл app.config каждого сервиса в папке настроек этого сервиса в папке c: \ ProgramData \\.

Answer 1

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

AppDomain.CurrentDomain.SetData ("APP_CONFIG_FILE", "path to config file")

Отлично работало для нас, когда у нас были проблемы с загрузкой app.config только из DLL ...

Answer 2

Каждый домен приложений имеет / может иметь свой собственный файл конфигурации. Домен приложений по умолчанию, созданный хостом CLR, использует programname.exe.config; если вы хотите предоставить свой собственный файл конфигурации, создайте отдельный домен приложений. Пример:

// get the name of the assembly
string exeAssembly = Assembly.GetEntryAssembly().FullName;

// setup - there you put the path to the config file
AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = System.Environment.CurrentDirectory;
setup.ConfigurationFile = "<path to your config file>";

// create the app domain
AppDomain appDomain = AppDomain.CreateDomain("My AppDomain", null, setup);

// create proxy used to call the startup method 
YourStartupClass proxy = (YourStartupClass)appDomain.CreateInstanceAndUnwrap(
       exeAssembly, typeof(YourStartupClass).FullName);

// call the startup method - something like alternative main()
proxy.StartupMethod();

// in the end, unload the domain
AppDomain.Unload(appDomain);

Надеюсь, это поможет.

Answer 3

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

• Определите app.config, как вы всегда делаете.
• Определите другой файл конфигурации, в котором вы хотите иметь фактический файл конфигурации
• Измените app.config, чтобы он ссылался на файл конфигурации

Во время выполнения настройки из файла конфигурации будут переопределять настройки в app.config (если есть). И все готово.

Пример app.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
    </startup>
  <appSettings file="..\Config\settings.config">
    <add key="port" value="1001"/>
  </appSettings>
</configuration>

Обратите внимание на file = ".. \ Config \ settings.config" . Вы совершенно свободно можете указать путь к месту, где вы хотите, чтобы ваши пользователи изменили настройки.

Пример файла фактической конфигурации

<?xml version="1.0" encoding="utf-8"?>
<appSettings>
  <add key="port" value="1234"/>
</appSettings>

Во время выполнения настройка port будет иметь значение 1234.

Подробнее см. msdn

Answer 4

Это сработало для меня .. (взято из http://msdn.microsoft.com/en-us/library/system.configuration.appsettingssection.aspx)

// open config
System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

// update appconfig file path
config.AppSettings.File = "C:\\dev\\App.config";

// Save the configuration file.
config.Save(ConfigurationSaveMode.Modified);

// Force a reload in memory of the changed section.
ConfigurationManager.RefreshSection("appSettings");

Тогда, когда вы звоните

NameValueCollection settings = System.Configuration.ConfigurationManager.AppSettings;

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

Надеюсь, что это может помочь кому-то, у кого такая же проблема!

Answer 5

Это древний вопрос, но я столкнулся с этой же проблемой и нашел хакерский обходной путь из нескольких минут в отражателе:

static public class ConfigHack {
    static public void OverrideAppConfig(string path) {
        ((AppDomainSetup)
            typeof(AppDomain)
                .GetField("_FusionStore", BindingFlags.NonPublic | BindingFlags.Instance)
                .GetValue(AppDomain.CurrentDomain))
        .ConfigurationFile = path;
    }

    static public void ResetConfigManager() {
        typeof(ConfigurationManager)
            .GetField("s_initState", BindingFlags.Static | BindingFlags.NonPublic)
            .SetValue(null, 0);
    }
}

Я использовал его только на .NET2, но он выглядит так же в 4 в отражателе. Конечно, я бы не рекомендовал отправлять это: P Я использую его только для быстрых внутренних вещей.

Answer 6

Извините, если я неправильно понял ваш запрос, но вы не можете использовать

ConfigurationManager.OpenExeConfiguration Method (String)

Исходя из изменений, возможно ли использовать

Свойство AppDomainSetup.ConfigurationFile

Answer 7

MSDN , вероятно, поможет ...

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

Answer 8

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

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