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.
Related
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 3rd party COM component that won't work on Windows 8 but will work perfectly fine if run in Windows 7 compatibility mode on Windows 8. However, I don't want the software to run in compatibility mode, just the COM component. Is it possible?
BTW, it's not possible to get a newer/working version of the COM component.
Thanks
Compatibility mode applies to a whole process at a time. The only way to do what you ask for is to run the COM object in a different container process, either using DCOM (if the COM object's interfaces have the necessary stubs and proxies registered for use as an out-of-process object) or by writing your own remoting layer.
I have a vb6-mysql client-server desktop application which is distributed as a setup file.
It uses DLL all logical operations as well as database operations. The EXE and the DLL are installed in the server as well as the client machines. When I say server which only means the database resides in that machine no other difference in EXE or DLLs.
As all the database operations are done in the DLL when connected from a client machine, performance would be less. It is not possible now to change all the logic into database.
Is it possible to store the DLL in the server machine only and use the same DLL by the client machine also so that database connection will always be from the server itself?
Is converting the DLL to a windows service the possible solution for this?
How can I to convert it to a service?
And finally, if it is possible to make the DLL act as a service, what would the connection issues be?
You appear to be trying to rediscover n-tier application development.
The usual way this would be done using VB6 within a LAN would be to create an ActiveX EXE instead of a DLL so you can use DCOM. However DCOM isn't something you'd want to expose over the Internet.
For such cases it is more typical to use a commonly-open-port protocol such as HTTP or HTTPS. Almost everyone has firewall settings permitting outbound HTTP and HTTPS connections and most of the major Web servers undergo regular hardening to make them safer to expose to the Internet.
The classic way to do this with VB6 was to use IIS to host the Remote Data Service, which uses a form of Web Service "under the covers" where your program doesn't deal with the gory details. However this is a deprecated approach, and today configuring IIS and the RDS components can be a chore since they are locked down hard by default.
This leaves you with such things as the deprecated SOAP Toolkit or 3rd party tools such as those in the PocketSOAP suite... or you can roll your own.
Doing this from scratch can be a bit of work but is more flexible, allowing REST instead of SOAP which can have advantages in itself. You could use whatever Web server you choose that can work with VB6 (via CGI, etc.).
The hardest approach to justify might seem the simplest on the surface: create your own protocol over TCP and write a Windows Service. This can be the most flexible of all but it can be more work than other options and you are on your own as far as making it and keeping it secure. You'll probably also face firewall issues depending on where your clients are and what the local firewall policies are there.
When we could rely on DCOM the issues were relatively small aside from security configuration headaches. With the Internet in the picture it is an entirely different story.
This really isn't something you undertake casually. Even assuming that your database is safe exposed to the Internet is naive and should be rethought.
One of our websites uses the payment gateway HSBC CPI which requires a DLL to be registered (using regsvr32.exe), this DLL is then used inside an asp.net website. The problem is that the DLL is a 32-bit DLL and so it will not register with the the Windows 2008 operating system.
Is there a way we can wrap this 32 bit dll in a C#/.net project so that it's methods are exposed and can be registerd with the OS?
Any help would be very much appreciated.
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.