Sai,
You shouldn't have to do too much in the way of marshalling and memory
management. Of course, if you have any questions about specifics, feel free
to ask.
As a solution, I would have all of the managed wrappers implement an
interface that a) extends IDisposable, and b), exposes a property that
returns an IntPtr which represents the pointer to the instance
that is being held internally by the managed wrapper. This way, if you need
to pass the internals around, it becomes very easy to do so.
--
- Nicholas Paldino [.NET/C# MVP]
-
nicholas.paldino@exisconsulting.com
"Sai Kit Tong" <sktong@mmm.com> wrote in message
news:eWjIBwGfDHA.1732@TK2MSFTNGP12.phx.gbl...[color=blue]
> Thanks for the followup mail. It clearly gives a better light to see[/color]
through[color=blue]
> the tunnel at the other end. I will try the managed wrapper but stay away
> from COM if possible for installation & registry issues. I had made a[/color]
simple[color=blue]
> experiment, and was able to use a C++ class created from VC++ 6.0 IDE in a
> managed .NET C++ form application. I just need to dig deep into data
> marshalling and memory management.
>
> Thanks once again.
>
> "Nicholas Paldino [.NET/C# MVP]" <nicholas.paldino@exisconsulting.com>[/color]
wrote[color=blue]
> in message news:%237QBQUFfDHA.1820@TK2MSFTNGP10.phx.gbl...[color=green]
> > Sai,
> >
> > In your case, it is very simple. Since you only have the compiled[/color]
> code[color=green]
> > and the C/C++ DLL, you can only do the following:
> >
> > - For the functions that are exported from the dll (not classes, but[/color][/color]
stand[color=blue][color=green]
> > alone function exports), you can use the P/Invoke layer to make the
> > appropriate calls. Lifecycle management doesn't apply here, since there[/color]
> are[color=green]
> > no instances (for the most part). Any caveats (such as having static
> > variables holding parameters passed in, etc, etc) still need to be[/color]
> addressed[color=green]
> > the way you would normally address them in C/C++ code.
> >
> > - For instances in C++, you have no choice but to create COM wrappers[/color][/color]
and[color=blue][color=green]
> > then import them into managed code, or to create managed wrappers. If[/color][/color]
you[color=blue][color=green]
> > create COM wrappers, then your lifecycle management should be pretty[/color][/color]
easy,[color=blue][color=green]
> > as you have definite hooks into when the COM object is created and/or
> > released. Exception handling in this case would be easy, just wrap[/color][/color]
every[color=blue][color=green]
> > method/property call in a try/catch block and if there is an exception,[/color]
> have[color=green]
> > it return an HRESULT indicating failure. Retaining OO implementation[/color]
> should[color=green]
> > not be a problem. Threading can cause a kink here. You will have to[/color][/color]
make[color=blue][color=green]
> > sure that the objects that the threads are accessing are marshaled[/color]
> correctly[color=green]
> > into/out of the thread. This could cause a major problem.
> >
> > - If you create managed wrappers, then you still have some issues. You[/color]
> will[color=green]
> > have to use the __nogc modifier in the wrapper class to store the[/color][/color]
instance[color=blue][color=green]
> > of the original C++ class. Also, every wrapper should implement the
> > IDisposable interface, so that the instances can be explicitly cleaned[/color][/color]
up[color=blue][color=green]
> > and your native objects will be released correctly. On top of that, the
> > exception handling will be something similar that you have to do in COM,
> > basically wrapping the native call and then throwing a managed exception
> > class if something happens.
> >
> > Either way you go, you will have to have a mechanism that will map[/color][/color]
the[color=blue][color=green]
> > native instance (from it's location in memory most likely) to the[/color][/color]
managed[color=blue][color=green]
> > instance and vice versa. The reason for this is that the methods on the
> > objects more likely than not contain parameters of object types, and you
> > can't pass the COM instances or the managed instances into these[/color][/color]
methods.[color=blue][color=green]
> > So, what you have to do is have the managed class expose the native[/color][/color]
handle[color=blue][color=green]
> > to the contained class, or you have to have a mapping mechanism. Either
> > way, it's not going to be pretty.
> >
> > Hope this helps.
> >
> >
> > --
> > - Nicholas Paldino [.NET/C# MVP]
> > -
nicholas.paldino@exisconsulting.com
> >
> > "Sai Kit Tong" <sktong@mmm.com> wrote in message
> > news:Opfyr%23EfDHA.1736@TK2MSFTNGP12.phx.gbl...[color=darkred]
> > > I posted for help on legacy code interface 2 days ago. Probably I[/color][/color][/color]
didn't[color=blue][color=green][color=darkred]
> > > make it clear in my original mail. I got a couple of answers but none[/color][/color][/color]
of[color=blue][color=green][color=darkred]
> > > them address my issues directly (See attached response). My first[/color][/color][/color]
reply[color=blue][color=green][color=darkred]
> > > directed me to source code migration but I didn't have the source[/color][/color][/color]
code.[color=blue][color=green]
> > The[color=darkred]
> > > second reply mentioned about .NET interoperability (PInvoke I think)[/color][/color][/color]
but[color=blue]
> I[color=green][color=darkred]
> > > MENTIONED THAT I COULDN'T FIND ANY DOCUMENTATION FROM MSDN LIBRARY[/color][/color][/color]
BASED[color=blue][color=green]
> > ON[color=darkred]
> > > .NET INTEROPERABILITY ON ADDRESSING ISSUES SUCH AS LIFE CYCLE[/color][/color][/color]
MANAGMENT,[color=blue][color=green][color=darkred]
> > > GARBAGE COLLECTION, EXCEPTION HANDLING (exception can be throw from[/color][/color]
> native[color=green][color=darkred]
> > > or managed code - later for callback), AND RETAINING OF OBJECT[/color][/color][/color]
ORIENTED[color=blue][color=green][color=darkred]
> > > IMPLEMENTATION (ONE-TO-ONE MAPPINIG) AS WELL AS THREADING (NATIVE CODE
> > > THREADS).
> > >
> > > I really have been struggling to find .NET development answers from[/color][/color][/color]
MSDN[color=blue][color=green][color=darkred]
> > > library. I have been using MSDN library for my previous ATL, MFC,[/color][/color][/color]
C/C++[color=blue][color=green][color=darkred]
> > > developer but never face this level of frustrations. Most of the[/color][/color]
> articles[color=green][color=darkred]
> > > and references only provide simple examples without dealing with[/color][/color]
> practical[color=green][color=darkred]
> > > problems. As mentioned in my first mail, all of the practical issues[/color]
> > listed[color=darkred]
> > > above for native code interface have been clearly discussed in the[/color][/color][/color]
book[color=blue][color=green][color=darkred]
> > > "JAVA NATIVE INTERFACE", but nothing on that details were covered in[/color][/color]
> MSDN[color=green][color=darkred]
> > > library.
> > >
> > > So far, I have a feeling that Java JNI (at least on documentation)[/color][/color]
> allows[color=green]
> > a[color=darkred]
> > > better intergration with legacy basic C/C++ library (.dll). For my[/color][/color][/color]
case,[color=blue]
> I[color=green][color=darkred]
> > > have
> > > - No source code available
> > > - Only header file (C++ class declarations or C function signatures)
> > > - basic C/C++ dll (not COM .dll)
> > >
> > > I still have the hope that somebody could point me to the right[/color][/color]
> direction[color=green]
> > to[color=darkred]
> > > handle any practical issues for native legacy library interface within[/color]
> > .NET[color=darkred]
> > > framework.
> > >
> > > Thanks.
> > >
> > >
> > >
> > > ================================================== ===========
> > >
> > > Hi Sai,
> > >
> > > Yes, Wrapper is based on source code level.
> > > I think you should use the .Net interop to consume the unmanaged .dll.
> > > If you dlls are component, you can refer to the COM interop.
> > >
> > > There are many articles referring to the interop in MSDN.
> > > You can search interop keyword in MSDN.
> > >
> > > Best regards,
> > > Jeffrey Tan
> > > Microsoft Online Partner Support
> > > Get Secure! -
www.microsoft.com/security
> > > This posting is provided "as is" with no warranties and confers no[/color][/color]
> rights.[color=green][color=darkred]
> > >
> > > --------------------
> > > | From: "Sai Kit Tong" <sktong@mmm.com>
> > > | References: <#SVb9v4eDHA.1828@TK2MSFTNGP10.phx.gbl>
> > > <Ofu$1#4eDHA.3200@tk2msftngp13.phx.gbl>
> > > | Subject: Re: legacy code interface: Java JNI vs .NET[/color][/color][/color]
interoperability[color=blue][color=green][color=darkred]
> > > | Date: Mon, 15 Sep 2003 09:23:04 -0500
> > > | Lines: 76
> > > | X-Priority: 3
> > > | X-MSMail-Priority: Normal
> > > | X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
> > > | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> > > | Message-ID: <O3AhiT5eDHA.1732@TK2MSFTNGP12.phx.gbl>
> > > | Newsgroups: microsoft.public.dotnet.languages.csharp
> > > | NNTP-Posting-Host: 130.99.229.109
> > > | Path:
> > >[/color]
> >[/color]
>[/color]
cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTN GXA06.phx.gbl!TK2MSFTNGXA0[color=blue][color=green][color=darkred]
> > > 5.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gb l
> > > | Xref: cpmsftngxa07.phx.gbl[/color]
> > microsoft.public.dotnet.languages.csharp:184222[color=darkred]
> > > | X-Tomcat-NG: microsoft.public.dotnet.languages.csharp
> > > |
> > > | Thanks for the reply. I went back to MSDN and there is a chapter on
> > > Managed
> > > | C++ Migration Guide talking about C++ Wrapper. However, I am[/color][/color][/color]
confused[color=blue]
> by[color=green][color=darkred]
> > > | that article. The description in that article seems to focusing on
> > > wrapping
> > > | around C++ class that you already have "SOURCE CODE". I am looking[/color][/color]
> into[color=green][color=darkred]
> > > | interfacing with legacy C/C++ code without the source - I only have[/color][/color]
> the[color=green][color=darkred]
> > > | class header or the function signature, and I couldn't recompile the
> > > legacy
> > > | code/library. I looked through the PInvoke services prior to[/color][/color]
> submitting[color=green]
> > my[color=darkred]
> > > | first mail. As I mentioned, I couldn't find article on the PInvoke[/color]
> > service[color=darkred]
> > > | addressing life cycle managment, garbage collection, exception[/color][/color]
> handling[color=green][color=darkred]
> > > | (native/managed code responsibility) and retaining of object[/color][/color][/color]
oriented[color=blue][color=green][color=darkred]
> > > | implementation (one-to-one mapping) and threading.
> > > |
> > > | Might be I misunderstand the actual articles that you are referring.[/color]
> > Could[color=darkred]
> > > | you get me the direct links to those articles. Thanks in advance[/color][/color]
> again.[color=green][color=darkred]
> > > |
> > > | "Nicholas Paldino [.NET/C# MVP]"[/color][/color][/color]
<nicholas.paldino@exisconsulting.com>[color=blue][color=green][color=darkred]
> > > wrote
> > > | in message news:Ofu$1%234eDHA.3200@tk2msftngp13.phx.gbl...
> > > | > Sai,
> > > | >
> > > | > Personally, I feel that the interop picture in .NET is way[/color][/color]
> better[color=green][color=darkred]
> > > than
> > > | > in Java (on the windows platform, that is). Is all of your code[/color][/color][/color]
in[color=blue][color=green][color=darkred]
> > > C/C++?
> > > | > Did you export all of your code through functions, or are they in
> > > | libraries
> > > | > of C++ objects? If they are all in objects, then you will have to
> > > create
> > > | > some managed wrappers, in which case, the MSDN documentation is[/color][/color][/color]
your[color=blue][color=green][color=darkred]
> > > best
> > > | > bet. There are a number of articles in there on how to wrap your[/color]
> > native[color=darkred]
> > > | C++
> > > | > objects in managed code (the easiest being to aggregate the code,[/color]
> > using[color=darkred]
> > > | the
> > > | > "__nogc" type declaration).
> > > | >
> > > | > Hope this helps.
> > > | >
> > > | >
> > > | > --
> > > | > - Nicholas Paldino [.NET/C# MVP]
> > > | > -
nicholas.paldino@exisconsulting.com
> > > | >
> > > | > "Sai Kit Tong" <sktong@mmm.com> wrote in message
> > > | > news:%23SVb9v4eDHA.1828@TK2MSFTNGP10.phx.gbl...
> > > | > > Hi,
> > > | > >
> > > | > > I am developing a new application running on Windows platform[/color][/color][/color]
that[color=blue][color=green][color=darkred]
> > > needs
> > > | > to
> > > | > > interface with existing legacy code - written in basic C / C++.[/color][/color][/color]
I[color=blue]
> am[color=green][color=darkred]
> > > | > trying
> > > | > > to evaluate Java vs C# implementations. Originally, I have the
> > > | impression
> > > | > > that C# should be a clear winner.
> > > | > >
> > > | > > I started with Java and using the guideline from the book "Java[/color]
> > Native[color=darkred]
> > > | > > Interface". Though complex, the book provide details of the[/color]
> > practical[color=darkred]
> > > | > > implementation and potential pitfalls for poor implementation.
> > > | > Particularly,
> > > | > > it provides a clear picture on life cycle managment, garbage
> > > collection,
> > > | > > exception handling (responsibility) and retaining of object[/color][/color]
> oriented[color=green][color=darkred]
> > > | > > implementation (one-to-one mapping). However, when I switched my[/color]
> > focus[color=darkred]
> > > | on
> > > | > > C#, I had difficult in finding good literature and examples for
> > > handling
> > > | > > those issues. I checked Chapter 1 of "COM and .NET[/color][/color]
> Interoperability"[color=green][color=darkred]
> > > and
> > > | > > Chapter 15/16 of "Essential Guide to Managed Extensions for[/color][/color][/color]
C++".[color=blue][color=green][color=darkred]
> > > | Hence,
> > > | > > that makes me lean on the Java implementation that the C#
> > > | implementation -
> > > | > > based on the fact that I know what I will get in details. Did I[/color][/color]
> miss[color=green][color=darkred]
> > > any
> > > | > > information critical? Could anyone point me to better article in[/color]
> > this[color=darkred]
> > > | > > particular aspect?
> > > | > >
> > > | > > Thanks in advance.
> > > | > >
> > > | > >
> > > | > >
> > > | >
> > > | >
> > > |
> > > |
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]
