I don't have an answer as to which approach might work better. However, I wonder why you're trying so hard to avoid having your .NET code run within the COM caller's process. The only reason I can see for that is that you want to support multiple COM callers within different processes all working with the same instance of your .NET code (in which case I don't think your "design 2" can work).
The ability to use exactly the same code for .NET clients as for COM clients does not seem to me to be an advantage -- you are imposing overhead on the .NET clients that isn't necessary, without adding any extra functionality for the COM clients. BTW, in design 2, you could have the in-process part create a new AppDomain and run the .EXE in the new AppDomain. But I still don't know why you're unhappy with the .NET code running in the COM client's process (or AppDomain). At 04:40 AM 1/17/2005, Ramesh, Babu Koniki \(IE10\) wrote >Hello All, > >My question is "How do I automate a .Net exe?" > >The details are like this: > >Problem: >I have a .exe written in .Net (C#) >I want to make this similar to a COM out-of-proc server (Automation Server) >so that automation clients can interact with automation objects in this .exe >I found in .Net help that .Net doesn't support out-of-proc servers like COM. >Irrespective of the way a .Net assembly is implemented (.DLL or .EXE) it is >always treated as InProcServer in COM clients through mscoree.dll. > >Approach Used: >In order to simulate the COM out-of-proc server I came up with the following >design: > >Design 1: > >1. Defined a set of interfaces that I expose to automation clients in a >separate Interfaces DLL >2. Implemented these interfaces in the .exe as remotable types >3. Made the .exe use .Net Remoting to register these types with .Net >Remoting infrastructure >4. Wrote a wrapper DLL in .Net that can talk to this .exe using .Net >Remoting >5. This wrapper DLL implements the interfaces in Interfaces DLL but having >just call forwarding to .exe using .Net Remoting >6. This wrapper DLL can now be used by COM clients as well as .Net clients >to interact with the running .exe >7. In case the .exe is not running but clients request an automation object, >the wrapper DLL starts the .exe as a separate process, waits and then >forwards the request > >Design 2: > >The second design changes from first only in communication layer. Instead of >using .Net remoting, Reflection is used. > >1. Defined a set of interfaces that I expose to automation clients in a >separate Interfaces DLL >2. Implemented these interfaces in the .exe >3. Wrote a wrapper DLL in .Net that launches this .exe using >System.Reflection on a separate thread to make clients non-blocking. >4. This wrapper DLL implements the interfaces in Interfaces DLL but having >just call forwarding to .exe using Reflection >5. This wrapper DLL can now be used by a COM client as well as .Net client >to interact with the running .exe > >However, using this design, the .exe willl now run within client's process >(within its domain) instead of a separate process. > >I would like to know if these approaches are feasible or if there exists any >other simple approach that I can use. > >Thanks and Regards, >Ramesh. J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
