B
Brett
If I believe certain project references (VS.NET) aren't being used, how can
this be confirmed?
Thanks,
Brett
this be confirmed?
Thanks,
Brett
A
Alan Pretre
Brett said:
Hi. Delete the reference and recompile. If there are errors, it _was_ being
used and you need to put it back in. If it compiles OK, then it was
extraneous.
-- Alan
J
James Curran
Remove them, one at a time, and recompile. If you get an error, put it
back. If not, move on to the next.
--
--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
back. If not, move on to the next.
--
--
Truth,
James Curran
[erstwhile VC++ MVP]
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
B
Brett
I was hoping there was a more efficient way.
Will removing the unused reference shrink the overall assembly size?
VS.NET will add certain references I don't always need - system.data,
system.xml. Are there any cases these should remain if I know they will not
be used?
Thanks,
Brett
Will removing the unused reference shrink the overall assembly size?
VS.NET will add certain references I don't always need - system.data,
system.xml. Are there any cases these should remain if I know they will not
be used?
Thanks,
Brett
James Curran said:
A
Alan Pretre
Brett said:
Not much if any size difference, but it will load a little faster since the
system doesn't need to locate and open the referenced assemblies.
Nah go ahead and get rid of them. They are so commonly used that VS just
assumes you'll need them. It will be a slight annoyance in the future if it
turns out you do need one of them.
-- Alan
M
Mattias Sjögren
Not sure what you consider efficient. But you can also just open the
compiled assemlby in a tool like Ildasm and look which references are
there (".assembly extern" records in IL Asm syntax). The C# compiler
will remove unused references.
No
Mattias
B
Bruce Wood
Will removing the unused reference shrink the overall assembly size?
Do you mean that the C# compiler isn't smart enough not to insert code
to load assemblies that aren't used by the code? I would have thought
that either the compiler / CLR would load assemblies on "first use", so
if you don't call them, they don't get loaded, or at least not build in
code to load assemblies that aren't used in the code.
The "first use" method would seem the most efficient: what if your
program uses some large assembly but the user never takes an action
that would cause it to be called? Would the CLR load it when your app
starts up, anyway, even if the user never did anything that would
require that assembly? Now I'm curious.
Do you mean that the C# compiler isn't smart enough not to insert code
to load assemblies that aren't used by the code? I would have thought
that either the compiler / CLR would load assemblies on "first use", so
if you don't call them, they don't get loaded, or at least not build in
code to load assemblies that aren't used in the code.
The "first use" method would seem the most efficient: what if your
program uses some large assembly but the user never takes an action
that would cause it to be called? Would the CLR load it when your app
starts up, anyway, even if the user never did anything that would
require that assembly? Now I'm curious.
A
Alan Pretre
Bruce Wood said:
According to Matthias' other post, the C# compiler will eliminate unused
references. I wasn't aware of that one.
-- Alan
W
Willy Denoyette [MVP]
Bruce Wood said:Do you mean that the C# compiler isn't smart enough not to insert code
to load assemblies that aren't used by the code? I would have thought
that either the compiler / CLR would load assemblies on "first use", so
if you don't call them, they don't get loaded, or at least not build in
code to load assemblies that aren't used in the code.
The "first use" method would seem the most efficient: what if your
program uses some large assembly but the user never takes an action
that would cause it to be called? Would the CLR load it when your app
starts up, anyway, even if the user never did anything that would
require that assembly? Now I'm curious.
You are right.
Only assemblies that are 'referenced' in code (have entries in the
assembly's Metadata) can be loaded implicitely. Assemblies that are included
in your project settings (used by the compiler) but aren't referenced in
code are simply ignored by the compiler, they aren't included in the
Metadata and cannot be loaded implicitely.
Willy.
B
Bruce Wood
When are the assemblies loaded? When the application starts up, or upon
first call?
This may make a difference, for example, in an application that
produces reports and can produce graphs. The graphing assembly might be
some monster beast that can produce pie charts, bar charts, line
graphs, etc. If the user never requests a graph, does the assembly get
loaded anyway (since it is referenced by the main program assembly)? Or
does the CLR wait until the first attempt to call something in the
assembly before it loads it? I would hope the latter.
first call?
This may make a difference, for example, in an application that
produces reports and can produce graphs. The graphing assembly might be
some monster beast that can produce pie charts, bar charts, line
graphs, etc. If the user never requests a graph, does the assembly get
loaded anyway (since it is referenced by the main program assembly)? Or
does the CLR wait until the first attempt to call something in the
assembly before it loads it? I would hope the latter.
W
Willy Denoyette [MVP]
Bruce Wood said:
It's the latter, assemblies are demand loaded at first call.
Willy.
B
Brett
Willy Denoyette said:
Willy, where did you find this information? That's pretty good. I haven't
read anything about that. Appreciate any references you can provide.
Thanks,
Brett
W
Willy Denoyette [MVP]
Brett said:
1.. Applied Microsoft .NET Framework Programming - J. Richter
2.. Shared Source CLI Essentials - Stutz, Neward and Shilling
3.. Essential .NET: Volume 1 - Don Box
4.. Inside Microsof .NET IL Assembler - S Lidin
5.. The Common Language Infrastructure Annotated Reference - J.Miller, AW
6.. Compiling for the .NET Common Language Runtime (CLR) - Gough
7.. ECMA CLI Partition Specs http://msdn.microsoft.com/net/ecma/
8.. MSDN, MSDN Magazine, Microsoft CLR Team Blogs
http://blogs.msdn.com/default.aspx, Debugging experiences etc...
Willy.
B
Brett
Had to use the Amazon.uk site for this one.Willy Denoyette said:
Good stuff on the blogs.
Here's a couple more that have good ratings and seem worthwhile:
Shared Source CLI Essentials
The C# Programming Language by Anders Hejlsberg
Great references. Thanks.
Brett