IJW on static library? Beginner question

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I have a large legacy MFC application. As is typical, there is an
executable along with several MFC DLLs. One of these DLLs is created by
staticly linking in many libraries resulting in one very large DLL that has
the bulk of the code.

I've downloaded the MFCWinFormsSample.EXE and have noticed that the main app
could stay as a native executable (i.e. no CLR support) whereas the various
..DLLs can be marked as having CLR support (using /clr switch).

My question is, what is the level of granularity that one can apply the CLR
support - is it only at the executable/DLL level or can it be applied at a
static library level, where that static library is linked into a DLL that
does not have CLR support enabled (and the other static libraries also don't
have CLR support enabled)? I expect the latter is not possible but thought I
would ask. My motivation is that I've got a lot of native code and would
like to keep it native as much as possible, to maintain optimal performance
and to avoid putting a bunch of pramas in all the other static libraries to
keep them native. I'm using VS 2005, if it makes any difference.

Thanks,
Notre
 
Notre Poubelle said:
Hello,

I have a large legacy MFC application. As is typical, there is an
executable along with several MFC DLLs. One of these DLLs is created by
staticly linking in many libraries resulting in one very large DLL that
has
the bulk of the code.

I've downloaded the MFCWinFormsSample.EXE and have noticed that the main
app
could stay as a native executable (i.e. no CLR support) whereas the
various
.DLLs can be marked as having CLR support (using /clr switch).

My question is, what is the level of granularity that one can apply the
CLR
support - is it only at the executable/DLL level or can it be applied at a
static library level, where that static library is linked into a DLL that
does not have CLR support enabled (and the other static libraries also
don't
have CLR support enabled)? I expect the latter is not possible but thought
I
would ask. My motivation is that I've got a lot of native code and would
like to keep it native as much as possible, to maintain optimal
performance
and to avoid putting a bunch of pramas in all the other static libraries
to
keep them native. I'm using VS 2005, if it makes any difference.
Click to expand...

Actually, you can control the CLR/native compilation on a per-function
basis. There should be no problem with keeping the bulk of your code native
and linking it with a few CLR-enabled modules that interact with WinForms.

-cd
 
Thank you very much for your reply Carl. When you say you can control
CLR/native compilation on a per function basis, do you mean by using pragmas?
Or is this another way to do this?

Ideally, I wouldn't have to do anything at all to most of my static
libraries, but instead create a new static library CLR support enabled and
link this into the common DLL, which does not have CLR support enabled.

Is this scenario reasonable?
Thanks,
Notre
 
Notre Poubelle said:
Thank you very much for your reply Carl. When you say you can control
CLR/native compilation on a per function basis, do you mean by using
pragmas?
Or is this another way to do this?
Click to expand...

Yes, #pragma (un)managed
Ideally, I wouldn't have to do anything at all to most of my static
libraries, but instead create a new static library CLR support enabled and
link this into the common DLL, which does not have CLR support enabled.

Is this scenario reasonable?
Click to expand...

I believe it should work just fine, yes.

-cd
 
Hi Notre,
another option would be to control CLR on per file base.
Solution explorer -Select cpp file-Open "properties","General". For all your
"old" files select "no clr support"
for your wrapper select "clr support"
HIH,
Boni
 
Thank you Boni & Carl.

I've created a static library that has CLR support and linked it into a DLL
that does not have CLR support. The code in the static library makes use of
managed libraries successfully and any code in the DLL may not use managed
libraries. This is great!

There are a couple of curious things. I halfway expected that when I used
reflector or ildasm, I would be able to see some managed classes but the
utilities say there's no CLI header and I guess that makes some sense, since
the DLL is not set to have CLR support (just the linked static library).

What's more confusing to me is that the when I used dumpbin /exports (or use
depends.exe from an earlier VS); there were no exports shown. However, my
static library does export both a C-style function and a C++ class. Does
this make sense to anyone?
 
Hi Notre,
I halfway expected that when I used reflector or ildasm,
I would be able to see some managed classes but the
utilities say there's no CLI header and I guess that makes
some sense, since the DLL is not set to have CLR support
(just the linked static library).
Click to expand...

yes, your DLL is not a .NET assembly, so the reflector and ildasm would not
work for it.
What's more confusing to me is that the when I used dumpbin
/exports (or use depends.exe from an earlier VS); there were
no exports shown. However, my static library does export both
a C-style function and a C++ class.
Click to expand...

Do you mean you use the dumpbin /exports to check the target DLL, but there
is not any export symbols found?

If so, have you really exported any functions/classes from that DLL(not
your static library), can you use those exported functions/classes in a
C/C++ application?


Thanks!

Best regards,

Gary Chang
Microsoft Community Support
======================================================
PLEASE NOTE the newsgroup SECURE CODE and PASSWORD will be updated at 9:00
AM PST, February 14, 2006. Please complete a re-registration process by
entering the secure code mmpng06 when prompted. Once you have entered the
secure code mmpng06, you will be able to update your profile and access the
partner newsgroups.
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================
 
Hi Gary,
Do you mean you use the dumpbin /exports to check the target DLL, but there
is not any export symbols found?
Yes.

If so, have you really exported any functions/classes from that DLL(not
your static library), can you use those exported functions/classes in a
C/C++ application?
Click to expand...

My DLL does not explicitly export any classes or functions. However, it is
defined as a MFC extension DLL. And my static library, which is linked into
my DLL does explicitly export a C style function.

Yes, everything seems to work although I have a possibly unrelated problem.
I want the project that generates an extension DLL to also generate a static
library (.lib) at the same time (so I can statically link this to the EXE
project) and I can't seem to do this. My code is based on a modified
Microsoft sample, and the sample originally generated both a DLL and a .lib
file from the same project using a single configuration. I modified this
code so that I pulled lots of the functionality into a separate project that
is compiled into a static library and linked into the DLL and at this point,
I seem to have broke both things: I can't see any exported functions/classes
and I can't generate both a DLL & .lib from the same project in the same
configuration.

Notre
 
Notre Poubelle said:
Hi Gary,


My DLL does not explicitly export any classes or functions. However, it
is
defined as a MFC extension DLL. And my static library, which is linked
into
my DLL does explicitly export a C style function.
Click to expand...

dumpbin /exports only shows DLL exports. Public symbols available in a
library are a different beast - you can see them with dumpbin /symbols
(intermixed with a lot of noise).
Yes, everything seems to work although I have a possibly unrelated
problem.
I want the project that generates an extension DLL to also generate a
static
library (.lib) at the same time (so I can statically link this to the EXE
project) and I can't seem to do this. My code is based on a modified
Microsoft sample, and the sample originally generated both a DLL and a
.lib
file from the same project using a single configuration. I modified this
code so that I pulled lots of the functionality into a separate project
that
is compiled into a static library and linked into the DLL and at this
point,
I seem to have broke both things: I can't see any exported
functions/classes
and I can't generate both a DLL & .lib from the same project in the same
configuration.
Click to expand...

When you say that you want to generate a DLL and a LIB, do you mean a static
library that contains the same code as the DLL, or an "import library" that
can be linked with an EXE that uses the DLL?

If the former, you need to have two projects - one that builds the DLL and
one that builds the LIB.

If the latter, an import library is normally generated automatically by a
DLL project (there's a checkbox in the project settings to generate an
import library). If you examine the import libary with dumpbin /exports,
you won't see anything - use dumpbin /symbols instead.

-cd
 
dumpbin /exports only shows DLL exports. Public symbols available in a
library are a different beast - you can see them with dumpbin /symbols
(intermixed with a lot of noise).
Click to expand...

Thanks Carl! That gives me more of what I would expect (and then some).
Sorry for the dumb question, but do entries in the fifth column of the table
produced by running dumpbin /symbols that are marked as External mean these
are the exported functions/classes? Are these symbols eventually exported
from the DLL to external clients of the DLL or are they only exported from
the static library to the DLL that links to the static library? It seems
like there are some extra symbols marked as External that I didn't see when I
ran dumpin /exports from the DLL, when everything was inside the DLL, and I
didn't have a static library. The extra symbols seem to MS stuff...

When you say that you want to generate a DLL and a LIB, do you mean a static
library that contains the same code as the DLL, or an "import library" that
can be linked with an EXE that uses the DLL?

If the former, you need to have two projects - one that builds the DLL and
one that builds the LIB.

If the latter, an import library is normally generated automatically by a
DLL project (there's a checkbox in the project settings to generate an
import library). If you examine the import libary with dumpbin /exports,
you won't see anything - use dumpbin /symbols instead.
Click to expand...

Oh; I didn't realize there were two different things. Based on your
clarification, the thing I am creating and linking into my DLL is a static
library. The .lib I wish to create alongside the DLL is then an import
library. Since I'm already asking dumb/beginner questions (sorry!), I'll
continue the trend. I can't seem to find the checkbox in the project
settings that you're referring to. I thought something like that must exist,
but I've use a file comparison utility to compare the original project file,
that generated both a DLL and import library and my modified one that does
not generate the import library and I can't see any relevant difference. I
also compared the C/C++ and Linker command line switches between the two
project and I'm still clueless as to what's not set.

Thanks again for your help!
 
Hi Notre,
but do entries in the fifth column of the table produced
by running dumpbin /symbols that are marked as
External mean these are the exported functions/classes?
Are these symbols eventually exported from the DLL
to external clients of the DLL or are they only exported
from the static library to the DLL that links to the static library?
Click to expand...

No, the symbols marked by the External are external symbols. It means they
are not defined by your DLL, but defined by the libraries which are
referenced by your DLL(e.g. your static library).

Thanks!

Best regards,

Gary Chang
Microsoft Community Support
======================================================
PLEASE NOTE the newsgroup SECURE CODE and PASSWORD will be updated at 9:00
AM PST, February 14, 2006. Please complete a re-registration process by
entering the secure code mmpng06 when prompted. Once you have entered the
secure code mmpng06, you will be able to update your profile and access the
partner newsgroups.
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================
 
Thank you Gary for your reply & clarification.

I think I need to clarify my goals to everyone. I would like to add limited
..NET support to my existing MFC application. My MFC application uses a few
MFC Extension DLLs. One of these extension DLLs links in several static
libraries. At this point in time, there is no managed code support. What
I'd like to do is to create a new static library, add CLR support to it, and
link this static library into the above mentioned DLL but leave the EXE,
extension DLLs and all other static libraries without CLR support. Based on
a sample I got from MS (see original post), I've made some modifications to
simulate this. For this most part this seems to be working. Thanks for
everyone's help to this point, I really appreciate it.

In the MS sample, the extension DLLs export classes and C style functions.
My MFC app does the same thing. I took the MS sample and modified one of the
extension DLLs such that I moved the C style function and C++ classes out of
the DLL and into a linked static library. At this point I lost the exported
functions & classes. I'm concerned the same thing will happen with my real
MFC application. Right now, in my real MFC app, there are static libraries
that have C style functions and classes that are exported through the main
DLL to which they are linked. I need to maintain this ability. This is why
I'm concerned (and confused) why my modifications to the samples have lost
this ability...

Thanks for taking the time to read & help.
Notre
 
Hi Notre,

A static library is a file containing objects and their functions and data
that is linked into your program when the executable file is built. Unlike
a dynamic library, it should not export any function or class. Your project
uses its linked static library just as another general couple of .h and
.cpp files. You can take it as a precompiled compilation unit of your
project.

Please refer to the following article for the further information:

Win32 Static Libraries
http://www.functionx.com/visualc/libraries/staticlib.htm

Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
======================================================
PLEASE NOTE the newsgroup SECURE CODE and PASSWORD will be updated at 9:00
AM PST, February 14, 2006. Please complete a re-registration process by
entering the secure code mmpng06 when prompted. Once you have entered the
secure code mmpng06, you will be able to update your profile and access the
partner newsgroups.
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================
 
I wanted to follow up and thank everyone for their help on this issue. I
ended up using the solution suggested by Boni - to add CLR support on a per
file basis and leave the project and most files as no-CLR support. This
allowed me the minimal use of managed code that I required while not messing
up exported functions and classes.

Notre
 
You are welcome, Notre.

Good Luck!

Best regards,

Gary Chang
Microsoft Community Support
======================================================
PLEASE NOTE the newsgroup SECURE CODE and PASSWORD will be updated at 9:00
AM PST, February 14, 2006. Please complete a re-registration process by
entering the secure code mmpng06 when prompted. Once you have entered the
secure code mmpng06, you will be able to update your profile and access the
partner newsgroups.
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top