2

I have a situation where a WCF service kicks off a .NET application and captures its output. Yes, I know that's ugly, but that's a separate issue. The issue I'm having is that I need to start the child process with a different configuration file, depending on input to the WCF service. I can't change the code to the child process, so I can't have it dynamically load a config file based on an argument. I saw the AppDomain method suggested here, but to the best of my knowledge, you don't get access to the Process object that way, so I can't capture its output.

So - is there a way to do this? Maintaining separate config files and copying them to the "main" location at run time is an option, but could lead to ugly race conditions. Any better ideas? Any way to extract the running process from the AppDomain?

Community
  • 1
  • 1
Deeko
  • 1,514
  • 9
  • 29

2 Answers2

2

I came up with a soltuion that almost fits what I want. I can't get the process for the new AppDomain execution because its the same process, so I just grab the current output....except it doesn't quite work. If I create a new AppDomain (like below), the caller of the WCF service (an ASPX page) asks for a username twice, then fails with no error message. If I change the config of the current domain using AppDomain.SetData, it starts executing the process, but throws strange errors. It almost seems like the process can't find its dependancies (which are still there). Does anything look wrong with this code?

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();
Deeko
  • 1,514
  • 9
  • 29
1

One option that avoids the race conditions would be to have the service create a new directory for the application on each invocation, copy the application to that directory, and write a custom configuration file. Of course, the service would need to delete that directory when the application exits. Or you'd need some sort of sweeper program that deletes those temporary directories from time to time.

If the application is a single executable, that solution would work pretty well. If there are many different assemblies, then you could have the service copy just the main executable to the temporary directory as above, and have it also modify the PATH environment variable so that the executable knows to look for other assemblies in the original directory.

Jim Mischel
  • 131,090
  • 20
  • 188
  • 351
  • Yea, I thought about doing a solution similar to this. It would work, but its not particularly "pretty" compared to a solution where I convince the existing application to load a different configuration file. Then again, nothing about this situation is pretty, so it might just be the way to do it... – Deeko Apr 05 '11 at 17:02