Legacy Code interface (No good answer): Java JNI better than .NET interoperability??

[Sai Kit Tong]

I posted for help on legacy code interface 2 days ago. Probably I didn't
make it clear in my original mail. I got a couple of answers but none of
them address my issues directly (See attached response). My first reply
directed me to source code migration but I didn't have the source code. The
second reply mentioned about .NET interoperability (PInvoke I think) but I
MENTIONED THAT I COULDN'T FIND ANY DOCUMENTATION FROM MSDN LIBRARY BASED ON
..NET INTEROPERABILITY ON ADDRESSING ISSUES SUCH AS LIFE CYCLE MANAGMENT,
GARBAGE COLLECTION, EXCEPTION HANDLING (exception can be throw from native
or managed code - later for callback), AND RETAINING OF OBJECT ORIENTED
IMPLEMENTATION (ONE-TO-ONE MAPPINIG) AS WELL AS THREADING (NATIVE CODE
THREADS).

I really have been struggling to find .NET development answers from MSDN
library. I have been using MSDN library for my previous ATL, MFC, C/C++
developer but never face this level of frustrations. Most of the articles
and references only provide simple examples without dealing with practical
problems. As mentioned in my first mail, all of the practical issues listed
above for native code interface have been clearly discussed in the book
"JAVA NATIVE INTERFACE", but nothing on that details were covered in MSDN
library.

So far, I have a feeling that Java JNI (at least on documentation) allows a
better intergration with legacy basic C/C++ library (.dll). For my case, I
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 direction to
handle any practical issues for native legacy library interface within .NET
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 rights.

--------------------
| From: "Sai Kit Tong" <sk****@mmm.com>
| References: <#S**************@TK2MSFTNGP10.phx.gbl>
<Of**************@tk2msftngp13.phx.gbl>
| Subject: Re: legacy code interface: Java JNI vs .NET interoperability
| 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: <O3**************@TK2MSFTNGP12.phx.gbl>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: 130.99.229.109
| Path:
cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTN GXA06.phx.gbl!TK2MSFTNGXA0
5.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gb l
| Xref: cpmsftngxa07.phx.gbl microsoft.public.dotnet.languages.csharp:184222
| 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 confused by
| that article. The description in that article seems to focusing on
wrapping
| around C++ class that you already have "SOURCE CODE". I am looking into
| interfacing with legacy C/C++ code without the source - I only have the
| class header or the function signature, and I couldn't recompile the
legacy
| code/library. I looked through the PInvoke services prior to submitting my
| first mail. As I mentioned, I couldn't find article on the PInvoke service
| addressing life cycle managment, garbage collection, exception handling
| (native/managed code responsibility) and retaining of object oriented
| implementation (one-to-one mapping) and threading.
|
| Might be I misunderstand the actual articles that you are referring. Could
| you get me the direct links to those articles. Thanks in advance again.
|
| "Nicholas Paldino [.NET/C# MVP]" <ni**************@exisconsulting.com>
wrote
| in message news:Of****************@tk2msftngp13.phx.gbl...
| > Sai,
| >
| > Personally, I feel that the interop picture in .NET is way better
than
| > in Java (on the windows platform, that is). Is all of your code in
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 your
best
| > bet. There are a number of articles in there on how to wrap your native
| C++
| > objects in managed code (the easiest being to aggregate the code, using
| the
| > "__nogc" type declaration).
| >
| > Hope this helps.
| >
| >
| > --
| > - Nicholas Paldino [.NET/C# MVP]
| > - ni**************@exisconsulting.com
| >
| > "Sai Kit Tong" <sk****@mmm.com> wrote in message
| > news:%2****************@TK2MSFTNGP10.phx.gbl...
| > > Hi,
| > >
| > > I am developing a new application running on Windows platform that
needs
| > to
| > > interface with existing legacy code - written in basic C / C++. I am
| > 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 Native
| > > Interface". Though complex, the book provide details of the practical
| > > 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 oriented
| > > implementation (one-to-one mapping). However, when I switched my focus
| on
| > > C#, I had difficult in finding good literature and examples for
handling
| > > those issues. I checked Chapter 1 of "COM and .NET Interoperability"
and
| > > Chapter 15/16 of "Essential Guide to Managed Extensions for C++".
| 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 miss
any
| > > information critical? Could anyone point me to better article in this
| > > particular aspect?
| > >
| > > Thanks in advance.
| > >
| > >
| > >
| >
| >
|
|

[Nicholas Paldino [.NET/C# MVP]]

Sai,

In your case, it is very simple. Since you only have the compiled code
and the C/C++ DLL, you can only do the following:

- For the functions that are exported from the dll (not classes, but stand
alone function exports), you can use the P/Invoke layer to make the
appropriate calls. Lifecycle management doesn't apply here, since there are
no instances (for the most part). Any caveats (such as having static
variables holding parameters passed in, etc, etc) still need to be addressed
the way you would normally address them in C/C++ code.

- For instances in C++, you have no choice but to create COM wrappers and
then import them into managed code, or to create managed wrappers. If you
create COM wrappers, then your lifecycle management should be pretty easy,
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 every
method/property call in a try/catch block and if there is an exception, have
it return an HRESULT indicating failure. Retaining OO implementation should
not be a problem. Threading can cause a kink here. You will have to make
sure that the objects that the threads are accessing are marshaled correctly
into/out of the thread. This could cause a major problem.

- If you create managed wrappers, then you still have some issues. You will
have to use the __nogc modifier in the wrapper class to store the instance
of the original C++ class. Also, every wrapper should implement the
IDisposable interface, so that the instances can be explicitly cleaned up
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 the
native instance (from it's location in memory most likely) to the managed
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 methods.
So, what you have to do is have the managed class expose the native handle
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]
- ni**************@exisconsulting.com

"Sai Kit Tong" <sk****@mmm.com> wrote in message
news:Op****************@TK2MSFTNGP12.phx.gbl...

I posted for help on legacy code interface 2 days ago. Probably I didn't
make it clear in my original mail. I got a couple of answers but none of
them address my issues directly (See attached response). My first reply
directed me to source code migration but I didn't have the source code. The second reply mentioned about .NET interoperability (PInvoke I think) but I
MENTIONED THAT I COULDN'T FIND ANY DOCUMENTATION FROM MSDN LIBRARY BASED ON .NET INTEROPERABILITY ON ADDRESSING ISSUES SUCH AS LIFE CYCLE MANAGMENT,
GARBAGE COLLECTION, EXCEPTION HANDLING (exception can be throw from native
or managed code - later for callback), AND RETAINING OF OBJECT ORIENTED
IMPLEMENTATION (ONE-TO-ONE MAPPINIG) AS WELL AS THREADING (NATIVE CODE
THREADS).

I really have been struggling to find .NET development answers from MSDN
library. I have been using MSDN library for my previous ATL, MFC, C/C++
developer but never face this level of frustrations. Most of the articles
and references only provide simple examples without dealing with practical
problems. As mentioned in my first mail, all of the practical issues listed above for native code interface have been clearly discussed in the book
"JAVA NATIVE INTERFACE", but nothing on that details were covered in MSDN
library.

So far, I have a feeling that Java JNI (at least on documentation) allows a better intergration with legacy basic C/C++ library (.dll). For my case, I
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 direction to handle any practical issues for native legacy library interface within ..NET 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 rights.

--------------------
| From: "Sai Kit Tong" <sk****@mmm.com>
| References: <#S**************@TK2MSFTNGP10.phx.gbl>
<Of**************@tk2msftngp13.phx.gbl>
| Subject: Re: legacy code interface: Java JNI vs .NET interoperability
| 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: <O3**************@TK2MSFTNGP12.phx.gbl>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: 130.99.229.109
| Path:
cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTN GXA06.phx.gbl!TK2MSFTNGXA0 5.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gb l
| Xref: cpmsftngxa07.phx.gbl microsoft.public.dotnet.languages.csharp:184222 | 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 confused by
| that article. The description in that article seems to focusing on
wrapping
| around C++ class that you already have "SOURCE CODE". I am looking into
| interfacing with legacy C/C++ code without the source - I only have the
| class header or the function signature, and I couldn't recompile the
legacy
| code/library. I looked through the PInvoke services prior to submitting my | first mail. As I mentioned, I couldn't find article on the PInvoke service | addressing life cycle managment, garbage collection, exception handling
| (native/managed code responsibility) and retaining of object oriented
| implementation (one-to-one mapping) and threading.
|
| Might be I misunderstand the actual articles that you are referring. Could | you get me the direct links to those articles. Thanks in advance again.
|
| "Nicholas Paldino [.NET/C# MVP]" <ni**************@exisconsulting.com>
wrote
| in message news:Of****************@tk2msftngp13.phx.gbl...
| > Sai,
| >
| > Personally, I feel that the interop picture in .NET is way better
than
| > in Java (on the windows platform, that is). Is all of your code in
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 your
best
| > bet. There are a number of articles in there on how to wrap your native | C++
| > objects in managed code (the easiest being to aggregate the code, using | the
| > "__nogc" type declaration).
| >
| > Hope this helps.
| >
| >
| > --
| > - Nicholas Paldino [.NET/C# MVP]
| > - ni**************@exisconsulting.com
| >
| > "Sai Kit Tong" <sk****@mmm.com> wrote in message
| > news:%2****************@TK2MSFTNGP10.phx.gbl...
| > > Hi,
| > >
| > > I am developing a new application running on Windows platform that
needs
| > to
| > > interface with existing legacy code - written in basic C / C++. I am
| > 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 Native | > > Interface". Though complex, the book provide details of the practical | > > 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 oriented
| > > implementation (one-to-one mapping). However, when I switched my focus | on
| > > C#, I had difficult in finding good literature and examples for
handling
| > > those issues. I checked Chapter 1 of "COM and .NET Interoperability"
and
| > > Chapter 15/16 of "Essential Guide to Managed Extensions for C++".
| 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 miss
any
| > > information critical? Could anyone point me to better article in this | > > particular aspect?
| > >
| > > Thanks in advance.
| > >
| > >
| > >
| >
| >
|
|

[Sai Kit Tong]

Thanks for the followup mail. It clearly gives a better light to see through
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 simple
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]" <ni**************@exisconsulting.com> wrote
in message news:%2****************@TK2MSFTNGP10.phx.gbl...

Sai,

In your case, it is very simple. Since you only have the compiled code and the C/C++ DLL, you can only do the following:

- For the functions that are exported from the dll (not classes, but stand
alone function exports), you can use the P/Invoke layer to make the
appropriate calls. Lifecycle management doesn't apply here, since there are no instances (for the most part). Any caveats (such as having static
variables holding parameters passed in, etc, etc) still need to be addressed the way you would normally address them in C/C++ code.

- For instances in C++, you have no choice but to create COM wrappers and
then import them into managed code, or to create managed wrappers. If you
create COM wrappers, then your lifecycle management should be pretty easy,
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 every
method/property call in a try/catch block and if there is an exception, have it return an HRESULT indicating failure. Retaining OO implementation should not be a problem. Threading can cause a kink here. You will have to make
sure that the objects that the threads are accessing are marshaled correctly into/out of the thread. This could cause a major problem.

- If you create managed wrappers, then you still have some issues. You will have to use the __nogc modifier in the wrapper class to store the instance
of the original C++ class. Also, every wrapper should implement the
IDisposable interface, so that the instances can be explicitly cleaned up
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 the
native instance (from it's location in memory most likely) to the managed
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 methods.
So, what you have to do is have the managed class expose the native handle
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]
- ni**************@exisconsulting.com

"Sai Kit Tong" <sk****@mmm.com> wrote in message
news:Op****************@TK2MSFTNGP12.phx.gbl...

I posted for help on legacy code interface 2 days ago. Probably I didn't
make it clear in my original mail. I got a couple of answers but none of
them address my issues directly (See attached response). My first reply
directed me to source code migration but I didn't have the source code. The

second reply mentioned about .NET interoperability (PInvoke I think) but I MENTIONED THAT I COULDN'T FIND ANY DOCUMENTATION FROM MSDN LIBRARY BASED

ON

.NET INTEROPERABILITY ON ADDRESSING ISSUES SUCH AS LIFE CYCLE MANAGMENT,
GARBAGE COLLECTION, EXCEPTION HANDLING (exception can be throw from native or managed code - later for callback), AND RETAINING OF OBJECT ORIENTED
IMPLEMENTATION (ONE-TO-ONE MAPPINIG) AS WELL AS THREADING (NATIVE CODE
THREADS).

I really have been struggling to find .NET development answers from MSDN
library. I have been using MSDN library for my previous ATL, MFC, C/C++
developer but never face this level of frustrations. Most of the articles and references only provide simple examples without dealing with practical problems. As mentioned in my first mail, all of the practical issues

listed

above for native code interface have been clearly discussed in the book
"JAVA NATIVE INTERFACE", but nothing on that details were covered in MSDN library.

So far, I have a feeling that Java JNI (at least on documentation) allows a

better intergration with legacy basic C/C++ library (.dll). For my case,

I 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 direction to

handle any practical issues for native legacy library interface within .NET

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

rights.
--------------------
| From: "Sai Kit Tong" <sk****@mmm.com>
| References: <#S**************@TK2MSFTNGP10.phx.gbl>
<Of**************@tk2msftngp13.phx.gbl>
| Subject: Re: legacy code interface: Java JNI vs .NET interoperability
| 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: <O3**************@TK2MSFTNGP12.phx.gbl>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: 130.99.229.109
| Path:

cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTN GXA06.phx.gbl!TK2MSFTNGXA0

5.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gb l
| Xref: cpmsftngxa07.phx.gbl

microsoft.public.dotnet.languages.csharp:184222

| 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 confused by | that article. The description in that article seems to focusing on
wrapping
| around C++ class that you already have "SOURCE CODE". I am looking into | interfacing with legacy C/C++ code without the source - I only have the | class header or the function signature, and I couldn't recompile the
legacy
| code/library. I looked through the PInvoke services prior to submitting my

| first mail. As I mentioned, I couldn't find article on the PInvoke

service

| addressing life cycle managment, garbage collection, exception

handling | (native/managed code responsibility) and retaining of object oriented
| implementation (one-to-one mapping) and threading.
|
| Might be I misunderstand the actual articles that you are referring.

Could

| you get me the direct links to those articles. Thanks in advance again. |
| "Nicholas Paldino [.NET/C# MVP]" <ni**************@exisconsulting.com>
wrote
| in message news:Of****************@tk2msftngp13.phx.gbl...
| > Sai,
| >
| > Personally, I feel that the interop picture in .NET is way better than
| > in Java (on the windows platform, that is). Is all of your code in
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 your
best
| > bet. There are a number of articles in there on how to wrap your

native

| C++
| > objects in managed code (the easiest being to aggregate the code,

using

| the
| > "__nogc" type declaration).
| >
| > Hope this helps.
| >
| >
| > --
| > - Nicholas Paldino [.NET/C# MVP]
| > - ni**************@exisconsulting.com
| >
| > "Sai Kit Tong" <sk****@mmm.com> wrote in message
| > news:%2****************@TK2MSFTNGP10.phx.gbl...
| > > Hi,
| > >
| > > I am developing a new application running on Windows platform that
needs
| > to
| > > interface with existing legacy code - written in basic C / C++. I am | > 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

Native

| > > Interface". Though complex, the book provide details of the

practical

| > > 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 oriented | > > implementation (one-to-one mapping). However, when I switched my

focus

| on
| > > C#, I had difficult in finding good literature and examples for
handling
| > > those issues. I checked Chapter 1 of "COM and .NET Interoperability" and
| > > Chapter 15/16 of "Essential Guide to Managed Extensions for C++".
| 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 miss any
| > > information critical? Could anyone point me to better article in

this

| > > particular aspect?
| > >
| > > Thanks in advance.
| > >
| > >
| > >
| >
| >
|
|

[Nicholas Paldino [.NET/C# MVP]]

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]
- ni**************@exisconsulting.com

"Sai Kit Tong" <sk****@mmm.com> wrote in message
news:eW**************@TK2MSFTNGP12.phx.gbl...

Thanks for the followup mail. It clearly gives a better light to see through 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 simple 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]" <ni**************@exisconsulting.com> wrote in message news:%2****************@TK2MSFTNGP10.phx.gbl...

Sai,

In your case, it is very simple. Since you only have the compiled code

and the C/C++ DLL, you can only do the following:

- For the functions that are exported from the dll (not classes, but stand

alone function exports), you can use the P/Invoke layer to make the
appropriate calls. Lifecycle management doesn't apply here, since there

are

no instances (for the most part). Any caveats (such as having static
variables holding parameters passed in, etc, etc) still need to be

addressed

the way you would normally address them in C/C++ code.

- For instances in C++, you have no choice but to create COM wrappers and then import them into managed code, or to create managed wrappers. If you create COM wrappers, then your lifecycle management should be pretty easy, 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 every method/property call in a try/catch block and if there is an exception,

have

it return an HRESULT indicating failure. Retaining OO implementation

should

not be a problem. Threading can cause a kink here. You will have to make sure that the objects that the threads are accessing are marshaled

correctly

into/out of the thread. This could cause a major problem.

- If you create managed wrappers, then you still have some issues. You

will

have to use the __nogc modifier in the wrapper class to store the instance of the original C++ class. Also, every wrapper should implement the
IDisposable interface, so that the instances can be explicitly cleaned up 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 the native instance (from it's location in memory most likely) to the managed 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 methods. So, what you have to do is have the managed class expose the native handle 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]
- ni**************@exisconsulting.com

"Sai Kit Tong" <sk****@mmm.com> wrote in message
news:Op****************@TK2MSFTNGP12.phx.gbl...

I posted for help on legacy code interface 2 days ago. Probably I didn't make it clear in my original mail. I got a couple of answers but none of them address my issues directly (See attached response). My first reply directed me to source code migration but I didn't have the source code.

The

second reply mentioned about .NET interoperability (PInvoke I think)

but I MENTIONED THAT I COULDN'T FIND ANY DOCUMENTATION FROM MSDN LIBRARY

BASED ON

.NET INTEROPERABILITY ON ADDRESSING ISSUES SUCH AS LIFE CYCLE

MANAGMENT, GARBAGE COLLECTION, EXCEPTION HANDLING (exception can be throw from

native or managed code - later for callback), AND RETAINING OF OBJECT ORIENTED IMPLEMENTATION (ONE-TO-ONE MAPPINIG) AS WELL AS THREADING (NATIVE CODE
THREADS).

I really have been struggling to find .NET development answers from MSDN library. I have been using MSDN library for my previous ATL, MFC, C/C++ developer but never face this level of frustrations. Most of the articles and references only provide simple examples without dealing with practical problems. As mentioned in my first mail, all of the practical issues

listed

above for native code interface have been clearly discussed in the book "JAVA NATIVE INTERFACE", but nothing on that details were covered in MSDN library.

So far, I have a feeling that Java JNI (at least on documentation) allows

a

better intergration with legacy basic C/C++ library (.dll). For my case, I 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 direction

to

handle any practical issues for native legacy library interface within .NET

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

rights.
--------------------
| From: "Sai Kit Tong" <sk****@mmm.com>
| References: <#S**************@TK2MSFTNGP10.phx.gbl>
<Of**************@tk2msftngp13.phx.gbl>
| Subject: Re: legacy code interface: Java JNI vs .NET

interoperability | 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: <O3**************@TK2MSFTNGP12.phx.gbl>
| Newsgroups: microsoft.public.dotnet.languages.csharp
| NNTP-Posting-Host: 130.99.229.109
| Path:

cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTN GXA06.phx.gbl!TK2MSFTNGXA0

5.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gb l
| Xref: cpmsftngxa07.phx.gbl

microsoft.public.dotnet.languages.csharp:184222

| 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 confused by

| that article. The description in that article seems to focusing on
wrapping
| around C++ class that you already have "SOURCE CODE". I am looking into | interfacing with legacy C/C++ code without the source - I only have the | class header or the function signature, and I couldn't recompile the
legacy
| code/library. I looked through the PInvoke services prior to submitting

my

| first mail. As I mentioned, I couldn't find article on the PInvoke service

| addressing life cycle managment, garbage collection, exception

handling | (native/managed code responsibility) and retaining of object

oriented | implementation (one-to-one mapping) and threading.
|
| Might be I misunderstand the actual articles that you are referring.

Could

| you get me the direct links to those articles. Thanks in advance

again. |
| "Nicholas Paldino [.NET/C# MVP]" <ni**************@exisconsulting.com> wrote
| in message news:Of****************@tk2msftngp13.phx.gbl...
| > Sai,
| >
| > Personally, I feel that the interop picture in .NET is way better than
| > in Java (on the windows platform, that is). Is all of your code in 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 your best
| > bet. There are a number of articles in there on how to wrap your

native

| C++
| > objects in managed code (the easiest being to aggregate the code,

using

| the
| > "__nogc" type declaration).
| >
| > Hope this helps.
| >
| >
| > --
| > - Nicholas Paldino [.NET/C# MVP]
| > - ni**************@exisconsulting.com
| >
| > "Sai Kit Tong" <sk****@mmm.com> wrote in message
| > news:%2****************@TK2MSFTNGP10.phx.gbl...
| > > Hi,
| > >
| > > I am developing a new application running on Windows platform that needs
| > to
| > > interface with existing legacy code - written in basic C / C++. I am

| > 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

Native

| > > Interface". Though complex, the book provide details of the

practical

| > > 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 oriented | > > implementation (one-to-one mapping). However, when I switched my

focus

| on
| > > C#, I had difficult in finding good literature and examples for
handling
| > > those issues. I checked Chapter 1 of "COM and .NET Interoperability" and
| > > Chapter 15/16 of "Essential Guide to Managed Extensions for

C++". | 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

miss any
| > > information critical? Could anyone point me to better article in

this

| > > particular aspect?
| > >
| > > Thanks in advance.
| > >
| > >
| > >
| >
| >
|
|