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?
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.