473,714 Members | 2,139 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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

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 interoperabilit y (PInvoke I think) but I
MENTIONED THAT I COULDN'T FIND ANY DOCUMENTATION FROM MSDN LIBRARY BASED ON
..NET INTEROPERABILIT Y 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 interoperabilit y
| 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.publi c.dotnet.langua ges.csharp
| NNTP-Posting-Host: 130.99.229.109
| Path:
cpmsftngxa07.ph x.gbl!cpmsftngx a10.phx.gbl!TK2 MSFTNGXA06.phx. gbl!TK2MSFTNGXA 0
5.phx.gbl!TK2MS FTNGP08.phx.gbl !TK2MSFTNGP12.p hx.gbl
| Xref: cpmsftngxa07.ph x.gbl microsoft.publi c.dotnet.langua ges.csharp:1842 22
| X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.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************ **@exisconsulti ng.com>
wrote
| in message news:Of******** ********@tk2msf tngp13.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************* *@exisconsultin g.com
| >
| > "Sai Kit Tong" <sk****@mmm.com > wrote in message
| > news:%2******** ********@TK2MSF TNGP10.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 Interoperabilit y"
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.
| > >
| > >
| > >
| >
| >
|
|
Nov 15 '05 #1
3 2374
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************* *@exisconsultin g.com

"Sai Kit Tong" <sk****@mmm.com > wrote in message
news:Op******** ********@TK2MSF TNGP12.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 interoperabilit y (PInvoke I think) but I
MENTIONED THAT I COULDN'T FIND ANY DOCUMENTATION FROM MSDN LIBRARY BASED ON .NET INTEROPERABILIT Y 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 interoperabilit y
| 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.publi c.dotnet.langua ges.csharp
| NNTP-Posting-Host: 130.99.229.109
| Path:
cpmsftngxa07.ph x.gbl!cpmsftngx a10.phx.gbl!TK2 MSFTNGXA06.phx. gbl!TK2MSFTNGXA 0 5.phx.gbl!TK2MS FTNGP08.phx.gbl !TK2MSFTNGP12.p hx.gbl
| Xref: cpmsftngxa07.ph x.gbl microsoft.publi c.dotnet.langua ges.csharp:1842 22 | X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.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************ **@exisconsulti ng.com>
wrote
| in message news:Of******** ********@tk2msf tngp13.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************* *@exisconsultin g.com
| >
| > "Sai Kit Tong" <sk****@mmm.com > wrote in message
| > news:%2******** ********@TK2MSF TNGP10.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 Interoperabilit y"
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.
| > >
| > >
| > >
| >
| >
|
|

Nov 15 '05 #2
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************ **@exisconsulti ng.com> wrote
in message news:%2******** ********@TK2MSF TNGP10.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************* *@exisconsultin g.com

"Sai Kit Tong" <sk****@mmm.com > wrote in message
news:Op******** ********@TK2MSF TNGP12.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 interoperabilit y (PInvoke I think) but I MENTIONED THAT I COULDN'T FIND ANY DOCUMENTATION FROM MSDN LIBRARY BASED

ON
.NET INTEROPERABILIT Y 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 interoperabilit y
| 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.publi c.dotnet.langua ges.csharp
| NNTP-Posting-Host: 130.99.229.109
| Path:

cpmsftngxa07.ph x.gbl!cpmsftngx a10.phx.gbl!TK2 MSFTNGXA06.phx. gbl!TK2MSFTNGXA 0
5.phx.gbl!TK2MS FTNGP08.phx.gbl !TK2MSFTNGP12.p hx.gbl
| Xref: cpmsftngxa07.ph x.gbl

microsoft.publi c.dotnet.langua ges.csharp:1842 22
| X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.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************ **@exisconsulti ng.com>
wrote
| in message news:Of******** ********@tk2msf tngp13.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************* *@exisconsultin g.com
| >
| > "Sai Kit Tong" <sk****@mmm.com > wrote in message
| > news:%2******** ********@TK2MSF TNGP10.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 Interoperabilit y" 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.
| > >
| > >
| > >
| >
| >
|
|


Nov 15 '05 #3
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************* *@exisconsultin g.com

"Sai Kit Tong" <sk****@mmm.com > wrote in message
news:eW******** ******@TK2MSFTN GP12.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************ **@exisconsulti ng.com> wrote in message news:%2******** ********@TK2MSF TNGP10.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************* *@exisconsultin g.com

"Sai Kit Tong" <sk****@mmm.com > wrote in message
news:Op******** ********@TK2MSF TNGP12.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 interoperabilit y (PInvoke I think)
but I MENTIONED THAT I COULDN'T FIND ANY DOCUMENTATION FROM MSDN LIBRARY
BASED ON
.NET INTEROPERABILIT Y 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
interoperabilit y | 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.publi c.dotnet.langua ges.csharp
| NNTP-Posting-Host: 130.99.229.109
| Path:

cpmsftngxa07.ph x.gbl!cpmsftngx a10.phx.gbl!TK2 MSFTNGXA06.phx. gbl!TK2MSFTNGXA 0
5.phx.gbl!TK2MS FTNGP08.phx.gbl !TK2MSFTNGP12.p hx.gbl
| Xref: cpmsftngxa07.ph x.gbl

microsoft.publi c.dotnet.langua ges.csharp:1842 22
| X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.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************ **@exisconsulti ng.com> wrote
| in message news:Of******** ********@tk2msf tngp13.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************* *@exisconsultin g.com
| >
| > "Sai Kit Tong" <sk****@mmm.com > wrote in message
| > news:%2******** ********@TK2MSF TNGP10.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 Interoperabilit y" 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.
| > >
| > >
| > >
| >
| >
|
|



Nov 15 '05 #4

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
1903
by: j-integra_support | last post by:
Looking for Java/COM interoperability tools? Thousands of companies world-wide are using J-Integra for COM for interoperability between Java and Microsoft COM applications. J-Integra for COM is a pure Java implementation of the DCOM protocol, making it several times faster than Web Services. J-Integra for COM Features: * Access J2EE components from VB, C++, ASPs, etc... * Access COM components from EJBs, Servlets, JSPs, Applets, etc......
8
2011
by: Russ | last post by:
Hello. I have a very large business application written all in VC++ and MFC. Now I want to interface some of it to the web. I have VS.NET2003 and have been studing walkthroughs and documentation and trying some things. I wanted to build an XML web service that would interface to my existing data and classes. But most of the examples are for C#, which I do not know, and which can not understand the C++ header files needed to interface...
4
1412
by: Mark | last post by:
In the Visual C++ 7.1 compiler is there a legacy code mode? This is for non-GUI code. Its easy enough to bring the project in but of course I get a lot of clashes with ISO std C++ conventions. example) old style std library includes such as iostream.h thanks
1
2521
by: Sai Kit Tong | last post by:
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...
3
4020
by: Sai Kit Tong | last post by:
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...
1
2095
by: Sai Kit Tong | last post by:
I have to interface managed application with my legacy dll. I have employed the wrapper approach but I have to deal with the asynchronous callback from the legacy dll, which likely goes through a thread other than the initial calling thread. I got the idea from MSDN and other responses from this group by using the delegate. However, for garabage collection issue, I need to pin the delegate. Since my callback is asynchronous, I have been...
2
1638
by: Mark Olbert | last post by:
First off, the sympathy is for all you poor buggers out there who have to figure out how to marry Managed Extensions for C++ onto your legacy code. My condolences; my brief experience with the process leads me to believe the Microsoft hates all of its VC++ developers :) Now, the question. I'm getting a NullReferenceException in a __gc class that wraps functionality in a legacy C/C++ app (it's actually part of the Nero burning rom api). ...
2
1586
by: Ben | last post by:
I'm left with some legacy code using plain old str, and I need to make sure it works with unicode input/output. I have a simple plan to do this: - Run the code with "python -U" so all the string literals become unicode litrals. - Add this statement str = unicode
8
2518
by: Osiris | last post by:
Back in the 1990's there was a library on the market for building 'forms' in the MSDOS environment. With theis toolset, you could build userfriendly I/O routines with input/output fiields with validation , choice-lists etc. Does it still exist ? anyone has it out there ? I would like to compile some legacy code again, and need this product, named CSCAPE
0
8815
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9187
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
9033
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7960
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
5961
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4730
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
3164
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2529
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2113
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.