471,318 Members | 3,223 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,318 software developers and data experts.

statically linking managed C++ into a C# project

I'm starting work on what will eventually be a very, very LARGE project. A
lot of the project involves taking C/C++ class libraries and wrapping them
with managed C++. I'd like to minimize the number of DLLs I have (because
I'd like to keep my sanity). Is there some way to compile a managed C++ DLL
into a C# DLL, or am I just stuck consolidating the managed C++ into a
single DLL?

Lee
Dec 6 '05 #1
7 7285
Lee,

No, you can not statically link DLLs in .NET.

However, what you could do is when you create your wrapper for your C++
classes in a managed C++ assembly, instead of compiling that into an
assembly, compile it into a module.

Then, when compiling your C# project, you can reference the module and
have that built into the assembly.

You will have to compile these from the command line if using .NET 1.1,
or alter your MSBUILD file (your project file) if using .NET 2.0 or above
(or use the command line as well, if you wish).

On the C++ side, look at the /LN option. This will allow you to create
an MSIL module. Then, on the C# side, look at the /addmodule option, which
will allow you to specify an additional module to include in your assembly.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Lee Crabtree" <lc*******@goisi.com> wrote in message
news:e0****************@TK2MSFTNGP12.phx.gbl...
I'm starting work on what will eventually be a very, very LARGE project.
A lot of the project involves taking C/C++ class libraries and wrapping
them with managed C++. I'd like to minimize the number of DLLs I have
(because I'd like to keep my sanity). Is there some way to compile a
managed C++ DLL into a C# DLL, or am I just stuck consolidating the
managed C++ into a single DLL?

Lee

Dec 6 '05 #2
You are a wonderful person.

Lee

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:e4******************@TK2MSFTNGP09.phx.gbl...
Lee,

No, you can not statically link DLLs in .NET.

However, what you could do is when you create your wrapper for your C++
classes in a managed C++ assembly, instead of compiling that into an
assembly, compile it into a module.

Then, when compiling your C# project, you can reference the module and
have that built into the assembly.

You will have to compile these from the command line if using .NET 1.1,
or alter your MSBUILD file (your project file) if using .NET 2.0 or above
(or use the command line as well, if you wish).

On the C++ side, look at the /LN option. This will allow you to create
an MSIL module. Then, on the C# side, look at the /addmodule option,
which will allow you to specify an additional module to include in your
assembly.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Lee Crabtree" <lc*******@goisi.com> wrote in message
news:e0****************@TK2MSFTNGP12.phx.gbl...
I'm starting work on what will eventually be a very, very LARGE project.
A lot of the project involves taking C/C++ class libraries and wrapping
them with managed C++. I'd like to minimize the number of DLLs I have
(because I'd like to keep my sanity). Is there some way to compile a
managed C++ DLL into a C# DLL, or am I just stuck consolidating the
managed C++ into a single DLL?

Lee


Dec 6 '05 #3
Note that it won't work this way.
/addmodule expects a "verifiable" netmodule, that is, a module produced with
/clr:safe option of C++/CLI.
Managed C++ code that wraps native C++ can't get compiled using /clr:safe
unless PInvoke interop is used, but PInvoke can not be used to wrap
unmanaged classes.

Willy.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:e4******************@TK2MSFTNGP09.phx.gbl...
Lee,

No, you can not statically link DLLs in .NET.

However, what you could do is when you create your wrapper for your C++
classes in a managed C++ assembly, instead of compiling that into an
assembly, compile it into a module.

Then, when compiling your C# project, you can reference the module and
have that built into the assembly.

You will have to compile these from the command line if using .NET 1.1,
or alter your MSBUILD file (your project file) if using .NET 2.0 or above
(or use the command line as well, if you wish).

On the C++ side, look at the /LN option. This will allow you to create
an MSIL module. Then, on the C# side, look at the /addmodule option,
which will allow you to specify an additional module to include in your
assembly.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Lee Crabtree" <lc*******@goisi.com> wrote in message
news:e0****************@TK2MSFTNGP12.phx.gbl...
I'm starting work on what will eventually be a very, very LARGE project.
A lot of the project involves taking C/C++ class libraries and wrapping
them with managed C++. I'd like to minimize the number of DLLs I have
(because I'd like to keep my sanity). Is there some way to compile a
managed C++ DLL into a C# DLL, or am I just stuck consolidating the
managed C++ into a single DLL?

Lee


Dec 6 '05 #4
Forgot about the verifiable part...
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:OE****************@TK2MSFTNGP10.phx.gbl...
Note that it won't work this way.
/addmodule expects a "verifiable" netmodule, that is, a module produced
with /clr:safe option of C++/CLI.
Managed C++ code that wraps native C++ can't get compiled using /clr:safe
unless PInvoke interop is used, but PInvoke can not be used to wrap
unmanaged classes.

Willy.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:e4******************@TK2MSFTNGP09.phx.gbl...
Lee,

No, you can not statically link DLLs in .NET.

However, what you could do is when you create your wrapper for your
C++ classes in a managed C++ assembly, instead of compiling that into an
assembly, compile it into a module.

Then, when compiling your C# project, you can reference the module and
have that built into the assembly.

You will have to compile these from the command line if using .NET
1.1, or alter your MSBUILD file (your project file) if using .NET 2.0 or
above (or use the command line as well, if you wish).

On the C++ side, look at the /LN option. This will allow you to
create an MSIL module. Then, on the C# side, look at the /addmodule
option, which will allow you to specify an additional module to include
in your assembly.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Lee Crabtree" <lc*******@goisi.com> wrote in message
news:e0****************@TK2MSFTNGP12.phx.gbl...
I'm starting work on what will eventually be a very, very LARGE project.
A lot of the project involves taking C/C++ class libraries and wrapping
them with managed C++. I'd like to minimize the number of DLLs I have
(because I'd like to keep my sanity). Is there some way to compile a
managed C++ DLL into a C# DLL, or am I just stuck consolidating the
managed C++ into a single DLL?

Lee



Dec 6 '05 #5
Willy,
/addmodule expects a "verifiable" netmodule


Why would it care about verifiability? I could /addmodule a mixed mode
module without problems here. With the 2.0 compiler I just had to
specify /platform:x86 for it to be accepted.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Dec 6 '05 #6

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
Willy,
/addmodule expects a "verifiable" netmodule


Why would it care about verifiability? I could /addmodule a mixed mode
module without problems here. With the 2.0 compiler I just had to
specify /platform:x86 for it to be accepted.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.


Mattias,

Sorry for not being more explicit.
What I meant was that the way Nicholas explained would not work.
Now, what you did was simply adding a reference to a single "mixed mode"
netmodule (mixed mode = process specific), and you solved this with the
/platform:x86 option. That means your C# main program becomes machine
specific, no big deal though.
The problem is however that your netmodule must be distributed with your
main program assembly (.exe), a netmodule is referenced not statically
linked, right.
So, in the scenario of the OP, (remember he want's to reduce the number of
modules (DLL's)), we have:
1- C# assemblies, say a main program (entry point)
2- managed C++ code wrappers (mixed), and
3- native C++ code (wrapped classes) DLL's
building a netmodule for 2 doesn't solve the OP's problem, you still end
with three units of distribution, and it doesn't work anyway, you have to
link 2 and 3, as 2 calls into 3.
Ok, you could build a netmodule from 2 and 3, but you can't link a DLL from
this netmodule (linker returns: fatal error LNK1302: only support linking
safe .netmodules; unable to link ijw/native .netmodule).

That means at best you end with a .exe and a netmodule, and
- a netmodule is IMO not a valid unit of distribution
- is not loadable from unmanaged code, that would mean that still you need
to distribute the unmanaged code DLL, if used by unmanaged caller.
- and still you need the /platform:x86 option.

Willy.


Dec 6 '05 #7

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:Og****************@TK2MSFTNGP14.phx.gbl...

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl...
Willy,
/addmodule expects a "verifiable" netmodule


Why would it care about verifiability? I could /addmodule a mixed mode
module without problems here. With the 2.0 compiler I just had to
specify /platform:x86 for it to be accepted.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.


Mattias,

Sorry for not being more explicit.
What I meant was that the way Nicholas explained would not work.
Now, what you did was simply adding a reference to a single "mixed mode"
netmodule (mixed mode = process specific), and you solved this with the
/platform:x86 option. That means your C# main program becomes machine
specific, no big deal though.
The problem is however that your netmodule must be distributed with your
main program assembly (.exe), a netmodule is referenced not statically
linked, right.
So, in the scenario of the OP, (remember he want's to reduce the number of
modules (DLL's)), we have:
1- C# assemblies, say a main program (entry point)
2- managed C++ code wrappers (mixed), and
3- native C++ code (wrapped classes) DLL's
building a netmodule for 2 doesn't solve the OP's problem, you still end
with three units of distribution, and it doesn't work anyway, you have to
link 2 and 3, as 2 calls into 3.
Ok, you could build a netmodule from 2 and 3, but you can't link a DLL
from this netmodule (linker returns: fatal error LNK1302: only support
linking safe .netmodules; unable to link ijw/native .netmodule).

That means at best you end with a .exe and a netmodule, and
- a netmodule is IMO not a valid unit of distribution
- is not loadable from unmanaged code, that would mean that still you need
to distribute the unmanaged code DLL, if used by unmanaged caller.
- and still you need the /platform:x86 option.

Willy.


Sorry, but I forgot to tell that linking the managed and unmanaged C++
object modules (.obj) files into a mixed mode assembly (DLL), and refer to
this one from C# is IMO a better option.

Willy.

Dec 6 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Schraalhans Keukenmeester | last post: by
1 post views Thread by LinuxN00b | last post: by
reply views Thread by zhangrusi | last post: by
2 posts views Thread by Joerg M. Colberg | last post: by
36 posts views Thread by Martin Larsen | last post: by
5 posts views Thread by =?Utf-8?B?aWduaGVucnk=?= | last post: by
reply views Thread by rosydwin | last post: by

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.