Указание другого файла конфигурации для приложения .NET

Question

У меня есть ситуация, когда служба WCF запускает приложение .NET и перехватывает его вывод.Да, я знаю, что это некрасиво, но это отдельная проблема.У меня проблема в том, что мне нужно запустить дочерний процесс с другим файлом конфигурации, в зависимости от ввода в службу WCF.Я не могу изменить код на дочерний процесс, поэтому он не может динамически загружать файл конфигурации на основе аргумента.Я видел, что метод AppDomain предложил здесь , но, насколько мне известно, вы не получаете доступ к объекту Process таким образом, поэтому я не могу зафиксировать его вывод.

Итак, есть ли способ сделать это?Поддержание отдельных файлов конфигурации и копирование их в «основное» место во время выполнения является опцией, но может привести к ужасным условиям гонки.Есть идеи получше?Любой способ извлечь запущенный процесс из AppDomain?

Answer 1

Я придумал решение, которое почти соответствует тому, что я хочу.Я не могу получить процесс для нового выполнения AppDomain, потому что это тот же процесс, поэтому я просто беру текущий вывод .... за исключением того, что он не совсем работает.Если я создаю новый домен AppDomain (как показано ниже), вызывающая сторона службы WCF (страница ASPX) дважды запрашивает имя пользователя, а затем завершается сбоем без сообщения об ошибке.Если я изменяю конфигурацию текущего домена с помощью AppDomain.SetData, он начинает выполнение процесса, но выдает странные ошибки.Кажется, что процесс не может найти свои зависимости (которые все еще там).Что-то не так с этим кодом?

StringBuilder buffer = new StringBuilder();
StringWriter writer = new StringWriter(buffer);
Console.SetOut(writer);

AppDomainSetup domainSetup = new AppDomainSetup();
domainSetup.ApplicationBase = CommandLinePath;
domainSetup.ConfigurationFile = String.Format("{0}.{1}.config", ApplicationName, modifier);

AppDomain newDomain = AppDomain.CreateDomain("NewDomain", null, domainSetup);
newDomain.ExecuteAssembly(CommandLinePath + ApplicationName, null, args);

return buffer.ToString();

Answer 2

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

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