Embedding VC++ Application/DLL into a vb.net application

  • Thread starter Thread starter Bob
  • Start date Start date
B

Bob

I would appreciate any suggestions on handling the following...
I currently have a VC++ MDI Application. The core pieces/products are
all handled in separate dll's.
Our shop has slowly been rewriting other applications over to VB.net.
My application has now been targeted with coming over, but management
does not want to incur a rewrite timeline. Since we have a standard
vb.net framework in place, their thoughts are to try and take the
prewritten VC++ GUI pieces and have them instantiate within the VB.net
framework application.

I have been doing some research, and it seems like PInvoke is out,
since it appears to be good for the one-shot function calls.

The application is not a COM app, so Interop does not seem like such a
low-effort idea either, since it would appear to go that route, I
would have to rewrite my framework pieces in a COM wrapper in order to
then be able to use it from within the vb.net frame.

The only other option I see is wrapping my application pieces that can
come over with managed C++ and mixing that with vb.net.

Any thoughts would be greatly appreciated.
Regards
 
Bob said:
I would appreciate any suggestions on handling the following...
I currently have a VC++ MDI Application. The core pieces/products are
all handled in separate dll's.
Our shop has slowly been rewriting other applications over to VB.net.
My application has now been targeted with coming over, but management
does not want to incur a rewrite timeline. Since we have a standard
vb.net framework in place, their thoughts are to try and take the
prewritten VC++ GUI pieces and have them instantiate within the VB.net
framework application.
Click to expand...

IMO it is impossible to have a single migration scheme which serves all
possible cases well. So take this with a grain of salt ...

Nevertheless, I'd take a step back. I'd try to think of how it would make
sense to invoke, from managed C++, the native functions that you have
exported from the "separate dll's" you mention. For example, if you have
"free functions" f1(), f2() and f3(), then perhaps you define an MC++ class
C with static functions C::f1(), C::f2(), C::f3(). On the other hand if you
expose a class interface in those DLLs then you'd want a similar managed
class with similar public functions with similar signatures.

No matter the interface, MC++ allows you to call native functions from
managed functions without thinking about it. (This is called "It just works"
or IJW). And since all managed languages share the same object model, once
you get that to work, your VB.Net application can use the managed C++ class
doing anything special.

Regards,
Will
 
Back
Top