I was given a half-finished project to finish. It was written in C++ using Visual Studio 2005.
Is it possible to somehow continue the project in VB.Net? If it is, can you guide me?
Thanks
A:
Assuming you're talking about VB6, you have to compile your c++ project as a dll file with extern "C" decorated outputs. That means functions only, no classes at all. If you can make your project work like that, it's the easiest way to integrate it in vb6, just look up Declare Function/Sub and translate the declarations as appropiate.
Now the other way, which includes working classes, is to expose COM objects from your c++ project, and in VB6 you just add a reference to it and use it as you would any VB6 class. It's however a lot more work.
Blindy
2009-12-31 18:01:12
Thanks for your prompt response.Sorry, I should have been more specific. I am talking about using vb.net. How does that change the picture?
2009-12-31 18:04:50
Well VB.NET has the same import capabilities as vb6 when it comes to C++ dll's, so the first point remains pretty much the same. COM objects are also easily accesible from VB.NET. It does open a 3rd option though: you can compile your c++ project as a managed dll and manually expose managed classes of your code, then add a reference from vb.net and seamlessly use them with no issues. Look up `IDispose` if you're going this route as unmanaged resources need special care in .NET.
Blindy
2009-12-31 18:25:38
Being that I'll need to work with the c++ classes in addition to functions, Would you say that option #3 would be most suited?
2009-12-31 18:46:58
Yes, but you need to build a c++/cli wrapper for every c++ class you have. Depending on how many classes there are, this may take a while. It might be faster to finish your project in c++ and write the final gui or whatever in vb as a com object that you import from c++ and use it, or just write it all in c++.
Blindy
2009-12-31 23:41:36
+1
A:
I've had success at doing this in Visual Studio, though my scenario may be somewhat different.
I was given an existing C++ app to add functionality to, and decided to implement the new features in C#/VB. In the General properties for the app, I changed my "Common Language Runtime support" setting to /clr. I then created my new classes in C# and VB and linked them in using the "Resolve #using References" section on the "C/C++" node of the project properties.
This did not eliminate the need to write C++, as I still needed to code some C++/CLI to integrate the two parts of the app, but it did let me write most of the new functionality that I wanted to write in languages that I'm more productive in.
Of course, this could get annoying if you have half-implemented objects in C++ and you want to implement the other half of the same in VB, in which case this method might get quite annoying to use and maintain.
dsolimano
2009-12-31 18:22:30
Thanks, dsolimanoI may indeed have some half-implemented objects. You say it might be annoying, but would it be possible to continue impelementing the objects in VB?Also, can you provide me with some code sample (or guidance) for integrating the 2 parts?
2009-12-31 18:29:43
One thing you could do would be to implement the new functionality in a VB object and then make the C++ object forward the calls to the VB object. That would give you an object half in C++ and half in VB. You would be using aggregation, essentially. For a quick intro to the C++/cli side, I like http://www.codeproject.com/KB/mcpp/quickcppcli.aspx
dsolimano
2009-12-31 18:52:34
getting back to your original reply, where did you create the new classes - inside the existing c++ project? I don't see an option to create a class in a different language...
2010-01-01 16:16:03
No, you need to create a separate project and link it in to the C++ project.
dsolimano
2010-01-02 06:38:41
A:
If the app isn't done, then I don't recommend trying to do the "rest" in VB unless there's a reasonable segmentation of the existing and new code such that you could turn the existing C++ stuff into a library to be used by the VB code. But only if it makes any kind of sense (think encapsulation here -- is the code suitable to stand (or at least lean) on its own?)
Otherwise, it sounds like a maintenance nightmare, where parts of a routine are in one codebase and parts are in another and debugging and enhancing become 10x as hard.
Joe
2009-12-31 19:26:10