I have a third party COM component (they don't offer a .Net assy), that has the additional feature that it only works under x86 compile.
I am trying to wrap this in a WCF service, but if I select x86, the service won't start (System.BadImageFormatException).
Any workarounds for this ?
Thanks
Larry
The issue is that the VS2008 WCF debugger will only start up in 64bit. I solved the problem by creating a 32bit host and running that
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 made a WCF Service Library projects. I added a reference of a c++ DLL . The Methods exposed by the WCF Service Call the c++ DLL functions. The Client is written in VBA(excel)
I can not Step into the C++ code whole debugging. Can someone guide me ?
I fixed it. Added the C++ project to the same solution of WCF Service and it worked
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 application that needs to communicate with a VS2008 VB.NET WCF server. I have built a VB.NET WCF DLL to be used on the client side, and it --almost-- works with the VB6 application. When I try to run the VB6 app in debug mode, I get "Could not find endpoint element with name 'NetTCPBinding_IComPortManager' and contract 'IComPortManager' in the ServiceModel client configuration section." Using a dummy VB.Net client app, with the same WCF DLL works fine. I presume that the VB6 app/WCF DLL is not finding app.config. Where should app.config be ? Is there a way to tell WCF where to find app.config ?
The app.config should be named as if your host was a .NET app, i.e.
YourAppName.exe.config
My answer here describes all the issues regarding VB6 and exe.config files.
I need to create a service. I know that you can do it with just a console application but it can also be done with ATL.. What are the benefits of the ATL Service vs a simple console application service? I understand that ATL is COM.. but what are the benefits of COM with the service.. thanks!
The service doesn't exactly benefit from COM, but rather the other way around.
By hosting your COM objects in a service, you get all the system features of services (startup before users log on, controlled policies watchdog, configuration of identity, etc.)
ATL gives you the opportunity to run your COM objects in a service context, as opposed to in-process (DLL) or regular out-of-process hosting. COM+ is another alternative for customized hosting.
If your service is just a background service, adding COM support could give you simple programmability, but otherwise I don't see any benefits.
So, I'm not sure that answers your question... The question feels backward :)