Home/ Questions/Q 3342642
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T00:51:45+00:00

I have a COM object in C++ and VB6 and everything is compiled and

  • 0

I have a COM object in C++ and VB6 and everything is compiled and packaged using Visual Studio 2003. The C++ generates the DLL, and VB6 the EXE, so from the legacy code I can call the EXE that calls the DLL and so on.

I need to migrate these to Visual Studio 2008. However, I have some questions

1) I can compile the C++ and generate the DLL – ( I think is ok)
2) VB.Net doesn’t have the option to generate COM/ActviveX anymore as VB6, so no idea
– I tried to generate windows exe and call the dll, but it doesn’t work. I think because it has some COM calls.

So what is the best solution to get rid of COM/ActiveX and deliver something?

Compile in C++ and load adding references in VB.net? I tried this but the DLL doesn’t load………

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You have not clarified if the VB code is an out-of-process COM server, or a client consuming the C++ inproc COM object.

    If the VB code is a client, you can use build it as a VB.Net executable, with either a COM reference to the coclass, or if you don’t want the C++ object to be registered during the build, you can use the TlbImp tool on the type library to generate a managed interop assembly to reference from the VB.Net code.

    If your VB.Code is an out-of-process COM server, you have to mark the classes you want to be creditable through COM with the COMVisible attribute, and then use the RegAsm tool to register your assembly with COM.

    Another alternative is to compile the C++ code as managed C++ and referen it from the VB code as a standard managed assembly. The advantage of this approach is that you would completely bypass the COM interop layer and stay fully in the managed world, which has certain perfect benefits. on the other hand,there are two drawbacks – a) your C++ code would be accessible only to that particular client unless you put it in the GAC, and b) writing managed C++ wil require a bit of a rampup. I don’t think the first one would affect you, as in your scenario it sounds that COM was used only as a convenient way to cross from the VB6 code to a lower level C++. However, the second one might give you some troubles.

    Update: Based on your comment update, it seems that actually you have a C++ code that is called directly from the VB code, which in turn is called through COM from other clients.

    If this indeed is the case, then my suggestion would be to recompile the VB6 code as a VB.Net (and you might have to make some changes to the code, as the two platforms are not absolutely identical), and expose it using COMVisible as a COM object, and use P/Invoke to consume the current C++ code (which is fairly similar to the way currently your VB6 code consumes it). There shouldn’t be need to recompile the C++ as a managed C++ component.

    • 0