views:

1167

answers:

4

I have read that removing unused references makes no difference to the compiler as it ignores assemblies that are not being referenced in the code itself.

But I find it hard to believe because then, what is the real purpose of Removing unused references? It doesn't have any noticeable effect on the size of the generated assembly or otherwise. Or is this smart behaviour limited to the C# compiler (csc.exe) and not inherent to vbc.exe?

If this functionality is so useless, why does ReSharper offer it as a feature? Why is it provided within the Visual Studio Project Configuration dialog?

The only activity I can think of where this would be useful is during Deployment. References (used or unused) would still be copied by the installer. But for assemblies that reside in the GAC (for instance, BCL assemblies), this would not be a problem either.

+9  A: 

Apart from the source files being smaller, I think it is just better to have a clean source file that has no unused code or references.

Christophe Herreman
Thanks, Cristophe, but the question remains... how/why is it better?
Cerebrus
It's better because your source files will not be bloated will unused code/imports and hence will be easier to read and understand. Additionally, I think that the compiler will have less work to do and compiling will be a tiny bit faster. (I'm not 100% sure about that and this is compiler specific)
Christophe Herreman
+5  A: 

Visual Studio 2008 also has the feature to remove unused using directives.

Removing unused code makes the code neater, but you can also reduce the risk of conflicts. Sometimes there are classes with the same name in different assemblies. For example, there is an Image class both in System.Drawing and System.Web.UI.WebControls. If you have using directives for both namespaces and start using the Image class, the compiler can't tell which of the ones to use.

Guffa
+1: reduce the risk of conflicts
Sung Meister
+3  A: 

It is an optimization to make your project compile faster. It avoids having the compiler load metadata that will never be used. It's a minor one though, I'd guess at about 50 msec, depending on the speed of your hard drive and the file system cache state.

The C# compiler is smart enough to only emit .assembly references in the metadata of your compiled assembly for assemblies that are actually used. So you won't generate native images for assemblies you don't use when you run Ngen.exe. The JIT compiler won't be affected either way, it only loads assemblies as needed to translate the IL.

Hans Passant
+7  A: 

It prevents the CLR from loading the referenced module at runtime. This will reduce startup time (since it takes time to load each module). Depending on the size of the module it might noticeably reduce startup time.

One way to test this is to create a test WinForms project, add a reference to an assembly that isn't used (e.g., System.Web) then run and attach to the executable (e.g., F5). View the loaded modules (Debug -> Windows -> Modules) and you'll see the referenced assembly was loaded.

If you think about it, it would be pretty hard for the CLR to determine whether or not a dependency (it's in the manifest as a dependency once you add a reference to it) is really used... Especially since the execution of some code paths can't be known in advance...

Arnshea