I have a C++ dll in which I implemented a com interface. This dll is loaded in process A and process A is running. I want this process to run as COM local server. exe of this process is normal console application.
I have another process B which creates the instance of com class written in dll.
I want to use this instance to call method from the COM class but those method should be executed in process A. Currently they are running in process B.
When I create exe from com class and not dll then methods of com class are executing in different process.
But I cant create a separate 'exe' for com classes. I want them in a dll which is loaded in process A at runtime.
Use Running Object Table to achieve inter-process communication. https://www.codeproject.com/Articles/17490/Running-Object-Table-Provider-in-NET-consumer-in-M
Related
I have a C# 32-bit COM DLL that talks to a C# 64-bit exe using the 'DllSurrogate' method described in Hosting a .NET DLL as an Out-Of-Process COM Server (EXE).
I need this setup because the 32 bit C# talks to a legacy 32-bit C++ dll.
I thought everything was working fine, but I have just realised that when you create a second instance of the 64-bit exe you do not get a second "DLL Host" (COM Surrogate) process. This is no good for my application.
This is a Windows Desktop application and I need to know that if the user starts it multiple times they all run in their own separate processes. Otherwise, data in the legacy dll might be corrupted and they will certainly run into the 32-bit process memory limitation.
The surrogate is registered using the AppId DllSurrogate key.
The 32-bit class instance is created in the 64-bit exe by a call to CoCreateInstance.
From some Googling it seems that the solution to my problem should involve the REGCLS_SINGLEUSE key from the REGCLS Enumeration. However, I can't see where to supply that key. Also, I note that in this enumeration there is a separate REGCLS_SURROGATE key. I hope that doesn't mean that DLL Surrogate and Single Use are mutually exclusive!
Any ideas would be welcome.
I would like to mimic the behaviour of a VB6-Active-X-Exe.
To do that, I have created a new project and set its settings to "COM Visible=True".
I can now add this .exe to my main application, and I can call it, call functions in that .exe, etc.
However, it is not really out of process, I think.
I would therefore like to investigate more about such an .exe's behaviour.
But I did not find any official documentation on it.
Can somebody tell me where to find more info?
Thank you!
Out-of-process COM servers (ActiveX EXE's) are not as easy to create with VB.NET as they were with VB6. When you reference a .NET executable (as a .NET assembly reference, not as a COM reference) from another .NET project, it always treats it as in in-process library. The .NET Framework has no direct equivalent to COM's out-of-process servers. Typically, in such scenarios, it is recommended that you create a WCF service, a web service, or use .NET remoting. WCF services are preferred since they use the most modern technology of the three.
However, since .NET supports COM interoperability, it is technically possible to create a .NET executable which can be registered as a out-of-process COM server. Then, when another .NET project references it via COM (rather than as a .NET assembly reference) it will run out-of-process. Microsoft provides an example of how to do that here.
However, if you don't need it to be COM (so that it can be used by non-.NET applications), I would recommend that you go the pure .NET WCF service route.
I have a Visual C++ Program that needs to use another program to run some specific functions to communicate with my USB device. This second program is provided by the company of by USB Device.
The company also provides the DLL and Library to access the communication module.
The program runs just fine. I can communicate very well with the USB Device.
The problem is that the communication with the USB Device is not the only function of my Visual C++ program, so it should be able to open the program even if the communication module is not installed.
Using the method RegOpenKeyEx, I succeeded to check if the communication module is installed or not. Therefore I can just avoid calling the functions to access the usb device if the communication module is not available.
The problem is that my program is still not opening in a computer without the communication module. I appears the error:
"The Appication was unable to start correctly(0x000007b). Click OK to close the application."
Is it possible to solve my problem?
Instead of statically linking to the DLL, you need to dynamically load it. Then you can choose to load it or not based on whether it's installed. Here is an article showing how to do this, and Here is an SO question with some more detailed info on accessing the contents of a dynamically loaded DLL.
How do you force a local COM server to run under a common account (local system would be good)? The RunAs documentation seems like its only for DCOM and doesnt work locally.
The problem i face is that my CoCreateInstance is being called from processes that are running in different desktops and the SCM under this scenario wants to start a new server for each desktop, I only want a single instanse - as designed!
What you are describing is a system service, not a COM server. A COM server is designed to run under whatever session runs it, not under "session 0" (services) or any single session. If you need something that only runs under 1 session and has global access to everything else, you should use a Windows Service, not a COM server.
If you need the COM server aspect for other reason, but want to share resources globally or still have "one process" that controls whatever you need to do... you can have your COM server communicate with your service using whatever IPC method you prefer.
Also, in your comments you say "when I run from the command line" -- if you run an EXE from the command-line, it doesn't matter if it is registered as a COM server or not, it just runs like any other EXE/app -- which means it runs as whatever user you run it as, in whatever session you are in. Registering an EXE as a COM server just allows other processes to run that EXE and communicate with it via OLE/COM, but the EXE can still run as a normal app as well. For example, Microsoft Word and Outlook are both COM servers. That is, outlook.exe is a COM server, but of course you can also run it as a normal application.
I implemented an out-of-proc COM server (implemented in a Service). I don't want other applications to access all the functionality in the COM server, so I developed an in-proc server (DLL) which would talk to the out-of-proc server.
Because I don't want the interfaces in the out-of-proc COM server to be accessed directly, I don't embed the type library with the Service so I thought I could use #import and have access to the COM server through the TLB. However, when I try in my in-proc-server to create an instance of a class implemented in the service, I get an E_NOINTERFACE back. I guess this is due to marshalling, but I couldn't figure out how to overcome this.
Any idea on how to communicate from the in-proc-server with my out-of-proc server without exposing the interface details of the out-of-proc server?
I'm not sure about how this will help to conseal the interfaces, but there're three ways to make marshalling working and typelib is one of them. The other quite easy way is a proxy/stub - a bunch of code in a separate in-proc COM server that will automagically do the marshalling once it has been registered in Windows registry. Again, I'm not sure how this will help conseal the interface, but it looks more covert then a type library that just exposes teh interface to anyone with OLEView.