By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,435 Members | 2,939 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,435 IT Pros & Developers. It's quick & easy.

Compiling from native to managed VC++ /clr option dramatically enlarge static lib size.

P: n/a
I have an unmanaged MFC project. The output is static lib. I would like
to compile using /clr option. The native lib size is 64 megs and with
/clr and /O1 options is 940 megs.
Is it possibly Metadata enlarge size so dramaticlly?
And I would like to know any suitable solution of my problem.

Jun 12 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"dovgani" <do*****@hotmail.com> wrote in message
news:11**********************@g10g2000cwb.googlegr oups.com...
I have an unmanaged MFC project. The output is static lib. I would like
to compile using /clr option. The native lib size is 64 megs and with
/clr and /O1 options is 940 megs.
Is it possibly Metadata enlarge size so dramaticlly?
And I would like to know any suitable solution of my problem.


I guess that you compile all your souce files with /clr. This is seldom
necessary. Consider compiling only those filed with /clr that you really
need to compile to managed code. In the best case, write managed code in a
separate source file and call it from you native code.
Jun 12 '06 #2

P: n/a
>>I have an unmanaged MFC project. The output is static lib. I would like
to compile using /clr option. The native lib size is 64 megs and with
/clr and /O1 options is 940 megs.
Is it possibly Metadata enlarge size so dramaticlly?
And I would like to know any suitable solution of my problem.


I guess that you compile all your souce files with /clr. This is seldom
necessary. Consider compiling only those filed with /clr that you really
need to compile to managed code. In the best case, write managed code in a
separate source file and call it from you native code.


But even so, this is a 15 times increase in size. is this normal?

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"
Jun 12 '06 #3

P: n/a
Bruno van Dooren wrote:
I have an unmanaged MFC project. The output is static lib. I would
like to compile using /clr option. The native lib size is 64 megs
and with /clr and /O1 options is 940 megs.
Is it possibly Metadata enlarge size so dramaticlly?
And I would like to know any suitable solution of my problem.


I guess that you compile all your souce files with /clr. This is
seldom necessary. Consider compiling only those filed with /clr that
you really need to compile to managed code. In the best case, write
managed code in a separate source file and call it from you native
code.


But even so, this is a 15 times increase in size. is this normal?


It may well be. Consider that the native version has virtually no metadata,
while the managed version has full metadata; including metadata describing
the contents of <windows.h> (or at least parts of it), if it's been
included.

-cd
Jun 13 '06 #4

P: n/a
"Bruno van Dooren" <br**********************@hotmail.com> wrote in message
news:O0****************@TK2MSFTNGP03.phx.gbl...
I have an unmanaged MFC project. The output is static lib. I would like
to compile using /clr option. The native lib size is 64 megs and with
/clr and /O1 options is 940 megs.
Is it possibly Metadata enlarge size so dramaticlly?
And I would like to know any suitable solution of my problem.


I guess that you compile all your souce files with /clr. This is seldom
necessary. Consider compiling only those filed with /clr that you really
need to compile to managed code. In the best case, write managed code in
a separate source file and call it from you native code.


But even so, this is a 15 times increase in size. is this normal?

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"


If you compile everything with /clr, this is possible. Roughly spoken,
without /clr, the only metadata is the decoated method names. With /clr, for
eyery function, there is the decorated name (as before), an entry in the
method table, the undecorated name, a custom attribute containing the
decorated name, the method's signature, including C++/CLI specific signature
modifiers ...

As Carl has mentioned, in addition to that there is a P/Invoke function
definition for every native function that is called in the code. For each
P/Invoke function definition, there is a similar overhead as described
above. If the lib contains many functions that wrap another functions 1:1,
the P/Invoke metadata can be a huge amount.

Marcus


Jun 13 '06 #5

P: n/a

Marcus Heege wrote:
"Bruno van Dooren" <br**********************@hotmail.com> wrote in message
news:O0****************@TK2MSFTNGP03.phx.gbl...
I have an unmanaged MFC project. The output is static lib. I would like
to compile using /clr option. The native lib size is 64 megs and with
/clr and /O1 options is 940 megs.
Is it possibly Metadata enlarge size so dramaticlly?
And I would like to know any suitable solution of my problem.

I guess that you compile all your souce files with /clr. This is seldom
necessary. Consider compiling only those filed with /clr that you really
need to compile to managed code. In the best case, write managed code in
a separate source file and call it from you native code.


But even so, this is a 15 times increase in size. is this normal?

--

Kind regards,
Bruno van Dooren
br**********************@hotmail.com
Remove only "_nos_pam"


If you compile everything with /clr, this is possible. Roughly spoken,
without /clr, the only metadata is the decoated method names. With /clr, for
eyery function, there is the decorated name (as before), an entry in the
method table, the undecorated name, a custom attribute containing the
decorated name, the method's signature, including C++/CLI specific signature
modifiers ...

As Carl has mentioned, in addition to that there is a P/Invoke function
definition for every native function that is called in the code. For each
P/Invoke function definition, there is a similar overhead as described
above. If the lib contains many functions that wrap another functions 1:1,
the P/Invoke metadata can be a huge amount.

Marcus


Thank you guys.
A little more details.
I have large(very large) application. Static library I am talking about
is presentation lib
I would like to use a new .NET controls (menu, toolbar).
Another words just to dress a new shell.
After our discussion. I think the best way is to rewrite that lib in
managed code.
But this is not easy job.

Jun 13 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.