tags:

views:

57

answers:

2

In .net, exes are assemblies and can be referenced just like dlls. This means that any of their types can be used from any other program given they're defined as public. What are the implications in calling another exe's Main function from your code? Obviously the thread that Main is called in would be blocked until the program terminated, unlike spawning a new process. What other potential issues would this have?

+5  A: 

The program would run in your AppDomain.

Therefore, any shared state used by both programs could get messed up.

To solve this, you can call AppDomain.ExecuteAssembly.

In either case, the program itself might not handle it correctly - the current directory, command-line arguments, and other per-process state (such as environment variables) would be shared with the parent process.

SLaks
True, although this is a solution that leads to its own problems. :-)
Steven Sudit
@Steven: Such as?
SLaks
@SLaks: I'm glad you asked. First, calling a method in another AppDomain means using .NET remoting. Second, doing so without injecting the foreign assembly into your own domain requires introspection and wrapper classes. Third, handling exceptions from the untrusted and presumably unstable code can be a mess, particularly when the AppDomain closes forcefully. Been there, done that, have the scars to show for it.
Steven Sudit
@Steven: Most of those problems are avoided by `ExecuteAssembly`.
SLaks
@SLaks: I suppose that's true if you're using `ExecuteAssembly` as an alternative to `Process.Start`. However, that's assuming that you have no interaction with it. I'm not sure what the use case for that would be. My gut feeling is that, if I really don't need to share anything, I'd be better off giving it a process of its own instead of just an AppDomain in a shared process.
Steven Sudit
A: 

I looked up the specifics about AppDomains in Jeffery Richter's CLR via C#. Here are the bullet points he gives about what AppDomains provide for those who are curious about the things that would be corruptible/open security holes.

  • Objects created by code in one AppDomain cannot be accessed directly by code in another AppDomain

  • AppDomains can be unloaded

  • AppDomains can be individually secured

  • AppDomains can be individually configured

Tim Coker