Suppose I have a Visual Studio solution called MySolution. MySolution contains a project with a public method defined like this: public void MyMethod(){...}.
If I have Resharper installed I can find the usages of MyMethod in MySolution by right clicking it and choosing Find Usages. However, suppose I have a number of other Visual Studio solutions on my hard drive which may or may not make use of MyMethod. Is there a simple way to track down these usages?
EDIT: Here's an attempted clarification of what I'm looking for. Suppose we have two other solutions MySolution2 and MySolution3. Each of these solutions contains a number of projects. Some of these projects may reference the assembly containing MyMethod. Let's call these projects referring projects. Some of the referring projects may actually make direct use of MyMethod. Let's call these projects client projects. I'm both interested in finding the referring projects (less ambitious) and the client projects (more ambitious).
How would the other solutions make use of MyMethod other than having its containing assembly referenced in the end?
If you mean is there a way to know if a particular method from a particular assembly referenced from a particular project is actually used in this project or not, then no, to my knowledge there's no way to do that other than going to each of these solutions, jumping to the method (say, with ReSharper's Go to symbol) and searching for its usages.
Related
Is there anyway within Visual Studio / TFS to identify which project produces which dll?
I'm aware you can look under a particular project's properties and see what the name of the dll is, but in the circumstance where you have loads and loads of projects this doesn't seem very efficient.
I've got the situation where I've got a project that references a dll, which includes a method I want to examine, but I don't know what project produces this dll.
Unfortunately, no. The only way I know is that you may could use a decompile extension. (Strongly not recommend to use) Through the source code after decompile, you can view namespace and judge which project produces the dll. (Under normal circumstances)
And you may also have to face some problems such as:
Legal issues
Need to pay for the extension
Only work for C#/.Net
The source code may be confusion and not standard
This should be a one time activity, you can go ahead and take a look into the project file, in case of C# project the csproj file.
If you do not want to do it opening each file, then i would say write a small tool to read all the project files and look for the name.
BTW, this will be different for different projects, and you need to find out the proper location to look.
We have a rather large solution with many projects under it. I am looking for a way to determine which dependencies are being used and which are not. We need to audit the solution and determine what is being used and what can be removed.
I have searched google and the visual studio gallery with no luck, does anyone know if a tool like this exists?
There's a couple different ways to define what "being used" means. If it's just a case of stale nuget packages that aren't referenced it's one thing, project/DLL references in individual projects that are referenced but not actually called is something else.
I can think of a couple different ways to do this. If you have Visual Studio Ultimate, you can use the "Generate Dependency Graph" under the Architecture menu to get a visualization of your various pieces, but that gets really message really fast.
Another option if you've got the cash it to buy a copy of ndepend. This thing lets you slice and dice your source code any number of ways; looking for unused dependencies is just one of the many ways you can use it to evaluate your code.
Say I have a class library project that I feel is getting too large and unwieldy and I want to break it out into smaller class library projects for easier distribution and deployment. Is there a way in VS2012 to use the refactor capability to accomplish this seamlessly?
So for example say my assembly has an IO package that I want to move to it's own project, so right now it might be:
MyAssembly.IO.Readers
MyAssembly.IO.Writers
etc
and I want to refactor all my references to have it in a different project completely (e.g.
MyIOSpecificAssembly). Is there an easy way to do this? Thanks
With ReSharper, you could drag-n-drop the file to another project (while holding SHIFT to move instead of copy), then use the adjust namespaces refactoring.
ReSharper also has various other refactorings that might be useful in this context, such as moving a type to another file, folder or namespace.
I have a solution with a decent number of projects (say, 30) and I want to find which of these projects reference a particular assembly.
Here's a concrete example: In the Object Browser I can see that two different versions of the same assembly are referenced throughout the solution. I want to see which project(s) use each of these references, so I can update them all to point to the same thing.
alt text http://www.freeimagehosting.net/uploads/bd7c85cb2e.png
Unfortunately, the .csproj files are scattered in different locations, so a simple grep is not all that simple.
Any suggestions?
I'm thinking of making a script that parses the .sln file and then parse each project file, but maybe there's a simpler solution.
PS. I'm using ReSharper, if that's any help.
In Resharper 5.0, you can click on a project and use "Find Code Dependent on Module". That should give you what you want.
It is easy enough to determine the namespace for a class by clicking "Go to Definition" (or by hovering) but I often need to know what dll something is defined in so I can add the appropriate reference to a different project that needs the same thing).
For example, in Silverlight there are many classes in the System.Windows.Controls namespace and these are spread across at least 5 different dlls.
I eventually figure out it through trial and error but there has to be an easier way.
Thanks in advance.
If the DLL of the class is a project in your solution then you can turn on the Track Active Item in Solution Explorer option (it's under Tools>Options>Projects and Solutions) so when you 'go to definition' on a class, the selection in the Solution Explorer will automatically move to it's file, then you can see in which project it's in.
If your namespaces are well named (so that they relate to the dll name) then you shouldn't have a problem. Maybe a few minutes of refactoring your namespaces is worth considering?
If you 'go to definition', then you can use save-as to easily see where it is saved in the project (and then cancel the save). (This of course relies on your folder structure being related to your namespace and assembly names, but usually getting the filename is enough to work out the project something belongs to)
edit: (of course, this only works for classes you have the source code for)
Unfortunately I think there isn't an easy way to do this. I feel your pain as I've had the exact same problems in the past.
My usual approach to solving this problem is reflector. For every solution I have, I typically have a reflector configuration which contains all of the DLL's in or referenced by that solution. When I need to find out the owning DLL I open reflector, do a quick search for the name and discover the DLL.
It's not an ideal solution but it works and is relatively quick.