Using a VB.NET interface from an unmanaged C++ application

[Sin]

Here's the situation... We have a product which was developped in C++
(win32) and had a Borland C++Builder interface (totally COM-free and proud
of it).

A little over 2 years ago (before the first official release of .NET) we
migrated the interface to VB.NET and the only way we found to make it all
work was to wrap all our C++ objects in COM classes to expose them to VB,
and expose the VB.NET forms as ComClasses for our C++ project to use them...

So the question is... Is there a clean way to integrate a VB.NET interface
into an unmanaged C++ application without ever touching COM? Or is there at
least a way to improve our design to minimize our use of COM?

The biggest problem is that we now have about 500 UUIDs to handle (as well
as 50+ vcprojects because all our objects are doubled by the wrappers)...
This is causing alot of extra work for installation/removal as well as
debugging, versioning, file control, etc... It's really a pain...

I'd be interrested in knowing how others are doing with this problem in
"large scale" projects like ours...

Thanks alot!

Alex.

 

[William DePalo [MVP VC++]]

(totally COM-free and proud of it).

I am familiar with this sentiment. ;-)

So the question is... Is there a clean way to integrate a VB.NET interface
into an unmanaged C++ application without ever touching COM? Or is there at
least a way to improve our design to minimize our use of COM?

The next time you are in a bookstore, take a gander at this:

http://www.apress.com/book/bookDisplay.html?bID=61

The second half of the book is all about interoperation among the various
languages and environments. I don't have the book near me know, but I can
tell you that you can get your COM wrappers from your VB.Net classes for
free (almost). There is a tool whose name escapes me know that will do the
job for you.

I think you find some useful info here as well:

http://www.dotnetextreme.com/articles/ccwrcw.asp

Of course, one of the reasons that MC++ exists (in my view) is to straddle
the fence between the managed and unmanaged worlds. Because the MC++
compiler permits managed and unmanaged functions in the same module and same
application you could have gone the other way using MC++ as the bridge to
expose both interfaces.

Regards,
Will

 

[Sin]

(totally COM-free and proud of it).

I am familiar with this sentiment. ;-)

Too few poeple feel like this lol! I've been programming Windows
applications profesionnaly for 8 years now and I have yet to write a COM
object (short of VB projects, but that doesn't really count!).

The next time you are in a bookstore, take a gander at this:

http://www.apress.com/book/bookDisplay.html?bID=61

The second half of the book is all about interoperation among the various
languages and environments. I don't have the book near me know, but I can
tell you that you can get your COM wrappers from your VB.Net classes for
free (almost). There is a tool whose name escapes me know that will do the
job for you.

Well as I said it's not that it's complicated or tedious to actually make
the COM objects... It's all that comes with it that's a problem... The fact
we have like 50 projects in our solution (we had about 20 before migrating
to .NET), the fact we now have 150+ UUIDs to register, unregister, keep
track, new version management is also a problem (we need to be able to have
both versions of the software debuggable on the same box, which means we use
a different set of UUIDs for each version)...

It would not be a problem if we had under 5 or 10 projects, but due to the
scope of the project, it's alot of work.

I think you find some useful info here as well:

http://www.dotnetextreme.com/articles/ccwrcw.asp

I'll look into it, thanks!

Of course, one of the reasons that MC++ exists (in my view) is to straddle
the fence between the managed and unmanaged worlds. Because the MC++
compiler permits managed and unmanaged functions in the same module and same
application you could have gone the other way using MC++ as the bridge to
expose both interfaces.

Eumm... I'll have to think about that and see what options this opens. I
know a descent design would be to have a managed C++ application as the main
application... From there we could call VB interfaces without any of the COM
crap, and the managed C++ app could call unmanaged functions and libraries,
etc... But this would require alot of work at this point, most likely too
much.... I don't really see how managed C could be of any help at this
point... I'll read up and think about it though!

Alex.