CODEWITHSUNDEEP
c++vb.netcomdllvb6-migration
Alex
Alex

Reputation: 131

Converting c++ vb6 COM object into dot net

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.........

Upvotes: 0

Views: 998

Answers (3)

Franci Penov
Franci Penov

Reputation: 76021

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.

Upvotes: 1

MarkJ
MarkJ

Reputation: 30408

It sounds as if your C++ DLL is an ordinary DLL (not COM), and it was accessible to the VB6 using Declare statements.

You have two options.

  • You could call the C++ DLL directly from .Net using P/Invoke. No code changes would be needed to the C++, you can use the existing DLL. You can use the P/Invoke Interop Assistant to automatically generate the P/Invoke code from the headers of your C++.
  • If you are willing to change the C++, you could also use C++ Interop, which is supposedly less tedious to implement.

Upvotes: 1

Preet Sangha
Preet Sangha

Reputation: 65546

Ok you seem to have a slight misunderstanding. .net is a completly different environment to COM/VB. They are what's called unmanaged code, while .net is managed. You can call through from one to the other use something called InterOp (and there are many types of this).

First vb6 - to convert this to .net you need to recode the application. .net is not VB. Though the languages are similar.

.net is not active X either. You cannot just recompile a c++ dll (com or otherwise into .net). However there is a special version of C++ called managed C++ what rests between managed and unmanaged code.

You have the following options.

  1. Recode the VB program and use COM InterOp from vb.net to access the existing COM object
  2. Recode the VB program and recode the COM functionality (either Managed C++ or recoded to VB.net) to completely .net
  3. Leave the VB program and recode the COM functionality (either Managed C++ or recoded to VB.net) to completely .net and use the ability of .net to expose COM interfaces.
  4. Leave all alone

Upvotes: 1

Related Questions