Question

I have a project which uses a component which lasts for the process's lifetime (see Force Disposal of an Inaccessible Static Object). To avoid that component from persisting I need to wrap it in a child process and call that.

Ideally I'd like to use Processes the same way I can Threads; having the compiler assist me in working with this process; though that's not possible due to the way Windows manages processes.

Are there recommended approaches to designing processes intended work together; i.e. best practices around how to call the child process, returning exceptions from child back to parent, and working with shared memory / WCF / some other method to allow the two processes to communicate with one another? Ideally I'd like to be able to work with the code for both processes in the same VS2012 solution and have the compiler do all it can to ensure compatibility of the two processes.

Était-ce utile?

La solution 2

There's the remoting approach to make many AppDomain work together transparently, but I would avoid it as it gets too complex and there're easier approaches.

Another good approach is using message queues and suscribing to them so it can be a good way of coordinating various processes easily.

Also, ASP.NET Web API self-host is easier to use and implement compared to WCF self-host.

In my opinion, I would go with the ASP.NET Web API approach.

Autres conseils

I've made a child process management library where the parent process and the child process are monitored due a bidirectional WCF pipe. If either the child process terminates or the parent process terminates each other is notified. There is also a debugger helper available which automatically attaches the VS debugger to the started child process

Project site:

http://www.crawler-lib.net/child-processes

NuGet Packages:

https://www.nuget.org/packages/ChildProcesses https://www.nuget.org/packages/ChildProcesses.VisualStudioDebug/

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top