Yes, this sounds like a great idea as well. It would still need to reside
in a seperate DLL since it sounded like the original message indicated a
lack of access to the source code.
Either way, a shim DLL will be needed.
But, I do like this approach better because it's much cleaner to the client.
-T
> I have just done this. Here is a real sample code.
> Make a C++.NET class lib to wrap your legacy code.
>
> The #include "lppaddress.h" is the good old C++ header.
> You make a new class that wraps the old one.
> Make a private member to old a pointer to the old fashion instance. The
> __gc compiler modifier is what makes this class a .NET 'thing'. You can
> then use the wrapper as a regular class library in other projects. I
> forgot where I got the info but a search for __gc on the net may lead
> you to more info.
> In this example, I just wrapped the minimum I needed. I guess there is
> no work around, you need to wrap
> all the methods by hand.
> Have fun.
>
> ------------------------------------------
>
> #include "lppaddress.h"
>
> #using <mscorlib.dll>
>
> using namespace System;
>
> namespace XX
> {
>
> public __gc class LppLANAddress
> {
> public:
> // constructor
> LppLANAddress() { m_pC = new LPPCL::CLppLANAddress(); }
> // destructor
> ~LppLANAddress() { delete m_pC; }
> // method
> LppLANAddress(DWORD dwAddress)
> {
> m_pC = new LPPCL::CLppLANAddress (dwAddress);
> }
>
> __property DWORD get_Address() { return m_pC->GetAddress(); }
>
>
> System::String* ToExportFormat() {
> UInt32 raw = m_pC->GetAddress();
> System::String* res =System::String::Format
> ("{0:x8}",__box(raw))->ToUpper();
> return res;
> }
>
>
>
> private:
> LPPCL::CLppLANAddress * m_pC;
> };
>
>
> -----Original Message-----
> From: Steve Clark [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2003 5:06 PM
> To: [EMAIL PROTECTED]
> Subject: [ADVANCED-DOTNET] access to a legacy DLL with a C++ API
>
>
> Hi:
>
> I can't find any references to the ability to call a legacy DLL that
> exports a standard C++ object API.
>
> Assume you have a legacy .DLL that exports some good old fashion C++
> classes, so it has a true C++ object API, not just a C API. Assume
> further that this .DLL does not have a COM interface.
>
> Can the objects in this .DLL be used by a .NET assembly (managed C++ or
> other language)? If it had a COM interface, it would be trivial. If it
> had a C API, it would be pretty easy using the P/Invoke stuff. If I
> were free to take the source code from the DLL and wrap that into a .NET
> assembly using managed extensions, that would probably be pretty
> straightforward, although I expect there are some restrictions. But I
> can't find any information on how to just use the C++ objects from the
> legacy DLL as-is.
>
> Thanks!
