DotNet UI with C++ backend - best way forward?

[Takeshi]

Hi All,

I am impressed with the aesthetic (UI) appeal of DotNet, but not by much
else, like it's new fangled languages etc... I have a legacy C++ 3tier
application, which uses C++ DLLs. I would like to use the DotNet
frontend (e.g. the PL provided by infragistics). However, I don't want
to start messing about with Managed C++ etc. Is there anyway I can use
my C++ DLLs (and C++ code of my application) and "bind" them to a DotNet UI?

Any ideas/suggestions will be very much appreciated.

MTIA

Takeshi

PS: I want to minimise the risk of going out on a limb with a "new"
language that never catches on (Remember Visual J++?), to minimise
future maintainance issues. Consequently, I would much rather prefer
solutions that use "tried and tested" languages like C and C++
(*possibly* VB, but that won't be my first choice since that has also
been given the .NET treatment)

[Edward Diener]

Takeshi wrote:

Hi All,

I am impressed with the aesthetic (UI) appeal of DotNet, but not by
much else, like it's new fangled languages etc... I have a legacy C++
3tier application, which uses C++ DLLs. I would like to use the DotNet
frontend (e.g. the PL provided by infragistics). However, I don't want
to start messing about with Managed C++ etc. Is there anyway I can use
my C++ DLLs (and C++ code of my application) and "bind" them to a
DotNet UI?

Any ideas/suggestions will be very much appreciated.

You can use Interop from any .NET language to use your DLL as long as they
are straight functions. But you will have to use some .NET language to
implement your .NET front end. Even Interop this way may have some
marshalling issues if the .NET types and the DLL function signature types
are different, which will require some .NET marshalling attributes to get
things right. If you use MC++, you don't need to use Interop as IJW ( It
Just Works ) makes it unnecessary.

However if your DLL is C++ classes, you need to use MC++. You can then:
1) Recompile your DLL as an unmanaged DLL and add DLL functions which create
an object and a return a pointer and delete the object, all from within your
DLL. You will use this creation and deletion rather than 'new' and 'delete'.
Then you can have a pure MC++ front end operating with an unmanaged C++ back
end.
or
2) Create a mixed mode MC++ front end assembly which uses your DLL ( DLL
still needs to be compiled as unmanaged C++ DLL with whatever version of
VC++ you are using ). There are a number of things you need to do in order
to implement your mixed mode MC++ assembly, all documented in MSDN under
"Converting Managed Extensions for C++ Projects from Pure Intermediate
Language to Mixed Mode".

[Takeshi]

Hi Edward,

Thanks for the prompt response. Don't want to use MC++. What about if I
"extern C" my C++ DLLS (i.e. convert them to regular Win32 DLLs) and
then write the GUI logic in VB (calling the functions from VB) ?

Will that work?

Tks

Edward Diener wrote:

Takeshi wrote:

Hi All,

I am impressed with the aesthetic (UI) appeal of DotNet, but not by
much else, like it's new fangled languages etc... I have a legacy C++
3tier application, which uses C++ DLLs. I would like to use the DotNet
frontend (e.g. the PL provided by infragistics). However, I don't want
to start messing about with Managed C++ etc. Is there anyway I can use
my C++ DLLs (and C++ code of my application) and "bind" them to a
DotNet UI?

Any ideas/suggestions will be very much appreciated.

You can use Interop from any .NET language to use your DLL as long as they
are straight functions. But you will have to use some .NET language to
implement your .NET front end. Even Interop this way may have some
marshalling issues if the .NET types and the DLL function signature types
are different, which will require some .NET marshalling attributes to get
things right. If you use MC++, you don't need to use Interop as IJW ( It
Just Works ) makes it unnecessary.

However if your DLL is C++ classes, you need to use MC++. You can then:
1) Recompile your DLL as an unmanaged DLL and add DLL functions which create
an object and a return a pointer and delete the object, all from within your
DLL. You will use this creation and deletion rather than 'new' and 'delete'.
Then you can have a pure MC++ front end operating with an unmanaged C++ back
end.
or
2) Create a mixed mode MC++ front end assembly which uses your DLL ( DLL
still needs to be compiled as unmanaged C++ DLL with whatever version of
VC++ you are using ). There are a number of things you need to do in order
to implement your mixed mode MC++ assembly, all documented in MSDN under
"Converting Managed Extensions for C++ Projects from Pure Intermediate
Language to Mixed Mode".

[Edward Diener]

Takeshi wrote:

Hi Edward,

Thanks for the prompt response. Don't want to use MC++. What about if
I "extern C" my C++ DLLS (i.e. convert them to regular Win32 DLLs) and
then write the GUI logic in VB (calling the functions from VB) ?
It will work since you are using functions and not classes. You still have
to use Interop from VB AFAIK. I am not a VB programmer but I am pretty sure
that Interop applies to VB also, just like it does in C# and MC++. In C# and
C++, Interop works through Platform Invoke and the Dllimport attribute. I
don't know what the VB terminology for Interop is but I am sure it must
exist, and I suspect it is essentially the same as C# and C++. For questions
about VB itself, someone else will have to answer you.

Will that work?

Tks

Edward Diener wrote:

Takeshi wrote:

Hi All,

I am impressed with the aesthetic (UI) appeal of DotNet, but not by
much else, like it's new fangled languages etc... I have a legacy
C++ 3tier application, which uses C++ DLLs. I would like to use the
DotNet frontend (e.g. the PL provided by infragistics). However, I
don't want to start messing about with Managed C++ etc. Is there
anyway I can use my C++ DLLs (and C++ code of my application) and
"bind" them to a DotNet UI?

Any ideas/suggestions will be very much appreciated.

You can use Interop from any .NET language to use your DLL as long
as they are straight functions. But you will have to use some .NET
language to implement your .NET front end. Even Interop this way may
have some marshalling issues if the .NET types and the DLL function
signature types are different, which will require some .NET
marshalling attributes to get things right. If you use MC++, you
don't need to use Interop as IJW ( It Just Works ) makes it
unnecessary.

However if your DLL is C++ classes, you need to use MC++. You can
then: 1) Recompile your DLL as an unmanaged DLL and add DLL
functions which create an object and a return a pointer and delete
the object, all from within your DLL. You will use this creation and
deletion rather than 'new' and 'delete'. Then you can have a pure
MC++ front end operating with an unmanaged C++ back end.
or
2) Create a mixed mode MC++ front end assembly which uses your DLL (
DLL still needs to be compiled as unmanaged C++ DLL with whatever
version of VC++ you are using ). There are a number of things you
need to do in order to implement your mixed mode MC++ assembly, all
documented in MSDN under "Converting Managed Extensions for C++
Projects from Pure Intermediate Language to Mixed Mode".