views:

49

answers:

3

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.

A: 

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)

Jason Williams
That is easy. I am looking for classes in dlls that for which I do not have the source code. For example, in Silverlight there are many classes in the System.Windows.Controls namespace and these are spread across at least 5 different dlls.
Jersey Dude
+1  A: 

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.

Idan K
True, but then I could just search for it. The case I am interested is where it it not in the current project? For example, in Silverlight there are many classes in the System.Windows.Controls namespace and these are spread across at least 5 different dlls.
Jersey Dude
A: 

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.

JaredPar