C++ code called from C#

[Daniel P.]

I have some legacy code I would like to wrap by some new managed C++
classes, put them all into a DLL and then call the managed classes from a C#
app.

Can anyone recommend me a link with some info about this?

Also, can I statically link my DLL to my C# application or I have to ship
the Managed C++ DLL with the C# exe appllication?

Thanks!

[William DePalo [MVP VC++]]

"Daniel P." <da******@hotma il.comU> wrote in message
news:Os******** ******@TK2MSFTN GP09.phx.gbl...

I have some legacy code I would like to wrap by some new managed C++
classes, put them all into a DLL and then call the managed classes from a C# app.
The second part of your question is a gimme. Once you have an MC++ object,
any .Net code in any CLS compliant language can make use of it. Now it is
true that some languages don't support all of the types supported by MC++
(unsigned's as I recall) that is often little more than a nit.
Can anyone recommend me a link with some info about this?
As to the first part of your question you can use "IJW" or it just works so
that a managed C++ member function can call an unmanged C++ function. The
MC++ compiler writes the code to hop the fence between the two environments.

For tips on interoperabilit y take a look at this:

http://msdn.microsoft.com/library/de...part2start.asp

and this

http://msdn.microsoft.com/library/de...part2start.asp

I like the treatment of interoperabilit y in the book "Essential Guide to
Managed Extensions for C++" (Apress) by Challa and Laksberg of the VC team.
Also, can I statically link my DLL to my C# application or I have to ship
the Managed C++ DLL with the C# exe appllication?

Well, if you want to call into a DLL, you'll have to ship it. :-) As to the
linking mechanism used by C# sorry but I don't know what your options are.
That'll probably be answered in the C# group.

Regards,
Will

[Tarek Madkour [MSFT]]

"William DePalo [MVP VC++]" <wi***********@ mvps.org> wrote in
news:Op******** ******@TK2MSFTN GP12.phx.gbl:

Also, can I statically link my DLL to my C# application or I have to
ship the Managed C++ DLL with the C# exe appllication?

Well, if you want to call into a DLL, you'll have to ship it. :-) As
to the linking mechanism used by C# sorry but I don't know what your
options are. That'll probably be answered in the C# group.

Using VS2002/2003, you'll need to ship two physical files. The tools do
not expose a way to link them into one image.

In VS2005, you'll be able to compile your code as .netmodules and link
them into a single-file assembly.

Thanks,
--
Tarek Madkour, Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers
no rights.

[Willy Denoyette [MVP]]

Tarek,

IMO the linker (link.exe) refuses to merge pure .netmodules (C#, VB, C++
/clr:safe or /clr:pure) and .netmodules containing native code (C++
/clr)into a single assembly .
So in the case you wrap native code with managed code, you will always need
the separate mixed code assembly, or am I missing something?

Willy.

"Tarek Madkour [MSFT]" <ta****@online. microsoft.com> wrote in message
news:Xn******** *************** ******@207.46.2 48.16...

"William DePalo [MVP VC++]" <wi***********@ mvps.org> wrote in
news:Op******** ******@TK2MSFTN GP12.phx.gbl:

Also, can I statically link my DLL to my C# application or I have to
ship the Managed C++ DLL with the C# exe appllication?

Well, if you want to call into a DLL, you'll have to ship it. :-) As
to the linking mechanism used by C# sorry but I don't know what your
options are. That'll probably be answered in the C# group.

Using VS2002/2003, you'll need to ship two physical files. The tools do
not expose a way to link them into one image.

In VS2005, you'll be able to compile your code as .netmodules and link
them into a single-file assembly.

Thanks,
--
Tarek Madkour, Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers
no rights.

[Brandon Bray [MSFT]]

Willy Denoyette [MVP] wrote:

IMO the linker (link.exe) refuses to merge pure .netmodules (C#, VB, C++
/clr:safe or /clr:pure) and .netmodules containing native code (C++
/clr)into a single assembly .
So in the case you wrap native code with managed code, you will always
need the separate mixed code assembly, or am I missing something?

If it comes from another language, you'll pass a .netmodule to the linker.
If it comes from C++, you're almost always better off passing object files
rather than .netmodule files to the linker.

Remember that object files can have metadata too, so other compilers can
reference them.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Willy Denoyette [MVP]]

Brandon,

Thanks for the prompt reply.

I just tried to link a C# netmodule and a mixed mode .netmodule (C++
14.00.40603) and this is what the linker say's...

fatal error LNK1302: unable to link .netmodule containing native code
So it looks like we should never use mixed mode .netmodules (using C++) to
be passed to the linker, but instead link the .obj files.

Willy.

"Brandon Bray [MSFT]" <br******@onlin e.microsoft.com > wrote in message
news:ex******** ******@TK2MSFTN GP09.phx.gbl... Willy Denoyette [MVP] wrote:

IMO the linker (link.exe) refuses to merge pure .netmodules (C#, VB, C++
/clr:safe or /clr:pure) and .netmodules containing native code (C++
/clr)into a single assembly .
So in the case you wrap native code with managed code, you will always
need the separate mixed code assembly, or am I missing something?

If it comes from another language, you'll pass a .netmodule to the linker.
If it comes from C++, you're almost always better off passing object files
rather than .netmodule files to the linker.

Remember that object files can have metadata too, so other compilers can
reference them.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

[Ronald Laeremans [MSFT]]

That is correct.

Ronald Laeremans
Visual C++ team

"Willy Denoyette [MVP]" <wi************ *@pandora.be> wrote in message
news:eV******** ******@TK2MSFTN GP09.phx.gbl...

Brandon,

Thanks for the prompt reply.

I just tried to link a C# netmodule and a mixed mode .netmodule (C++
14.00.40603) and this is what the linker say's...

fatal error LNK1302: unable to link .netmodule containing native code

So it looks like we should never use mixed mode .netmodules (using C++) to
be passed to the linker, but instead link the .obj files.

Willy.

"Brandon Bray [MSFT]" <br******@onlin e.microsoft.com > wrote in message
news:ex******** ******@TK2MSFTN GP09.phx.gbl...

Willy Denoyette [MVP] wrote:

IMO the linker (link.exe) refuses to merge pure .netmodules (C#, VB, C++
/clr:safe or /clr:pure) and .netmodules containing native code (C++
/clr)into a single assembly .
So in the case you wrap native code with managed code, you will always
need the separate mixed code assembly, or am I missing something?

If it comes from another language, you'll pass a .netmodule to the
linker.
If it comes from C++, you're almost always better off passing object
files
rather than .netmodule files to the linker.

Remember that object files can have metadata too, so other compilers can
reference them.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.