*Note: see http://www.jetbrains.net/devnet/message/5244658 for another version of this answer.
Reading through the posts, it looks like there is some confusion as to the original question. Let me take a stab at it.
The original post is really asking the question: "How do I identify and remove references from one Visual Studio project to other projects/assemblies that are not in use?" The poster wants the assemblies to no longer appear as part of the build output.
In this case, ReSharper can help you identify them, but you have to remove them yourself.
To do this, open up the References inth Solution Browser, right mouse click on each referenced assembly, and pick "Find Dependent Code". See:
You will either get:
A list of the dependencies on that Reference in a browser window, or
A dialog telling you "Code dependent on module XXXXXXX was not found.".
If you get the the second result, you can then right mouse click the Reference, select Remove, and remove it from your project.
While you have to to this "manually", i.e. one reference at a time, it will get the job done. If anyone has automated this in some manner I am interested in hearing how it was done.
You can pretty much ignore the ones in the .Net Framework as they don't normally get copied to your build output (typically - although not necessarily true for Silverlight apps).
Some posts seem to be answering the question: "How do I remove using clauses (C#) from a source code file that are not needed to resolve any references within that file".
In this case, ReSharper does help in a couple ways:
- Identifies unused using clauses for you during on the fly error detection. They appear as Code Inspection Warnings - the code will appear greyed out (be default) in the file and ReSharper will provide a Hint to remove it:
- Allows you to automatically remove them as part of the Code Cleanup Process:
Finally, realize that ReSharper does static code analysis on your solution. So, if you have a dynamic reference to the assembly - say through reflection or an assembly that is dynamically loaded at runtime and accessed through an interface - it won't pick it up. There is no substitute for understanding your code base and the project dependencies as you work on your project. I do find the ReSharper features very useful.