> > If it’s managed, and no native, why not a simple recompile? >
My experiment with Any CPU calling x86 was a sanity check before expanding to isolate some real native code. There are multiple issues at play here ... I will soon be given a fresh Borland C++ DLL which used to be a COM server, but has been converted to a "plain" DLL that I'll call through Interop. COM is great as advertised for getting wildly different components to talk to each other, and it's served us well for years. The reason for the change is twofold: (1) COM is hell to deploy and configure (2) My recent problem with VS2013 where it looks in the wrong registry key for CLSIDs when running as admin. The second problem is so severe that I have had to move all development of one large project back into a VM with VS2012. There are no search hits on this problem and it's one of the most nonsensical and unexpected I have ever seen. I could spend man days experimenting with no guarantee of finding an answer or workaround. We decided that this was a trigger to force us to remove COM and use Interop. So my experiment was to find a way of "isolating" the native Borland C++ DLL which has to called from an x86. Direct loading is out. Loading into an AppDomain is out (I quickly checked). So inter-Process is a candidate. Managed code that spins up multiple Processes that communicate and synchronise is not discussed in any depth that I have found so far. Doing that with Threads and AppDomains is well document and quite easy, but Processes have been neglected. I read part of THIS BOOK<http://www.orthogonal.com.au/photos/Scans/Book%20Covers/Other/Win32%20Developer%27s%20Reference%20Library%20-%20Base%20Services.jpg>last night and I was reminded that Windows has full support for multi-Processes of course, but how to do this from managed code? Has anyone got experience in this? Greg K
