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.
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.
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.
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.
Currently I have 4 solutions that are independent projects, however there is quite a bit of duplicated code when it comes to a few areas of the applications.
At the moment it is simply a few forms and their associated code.
When I want to change or improve something, I have to copy and paste to all relevant projects.
I looked at creating a new project within one of the solutions for the .dll/class library, but I felt that this was incorrect. (Please say if I am wrong).
As it is a component for all the applications, I decided to create a new solution for the .dll/class library and am looking at moving the shared code over to that - but, having never gone down this route before, what are my options from here?
Am I able to then include this solution within the others if I need to make a simple change and have it updated in all the projects or instead, should I always be working on the shared component in a separate instance of Visual Studio, outside of the applications using it?
That's exactly the right way to handle this situation.
You can include projects in multiple solutions by right-clicking the solution and selecting Add Existing Project...
Any changes you then make will appear in all solutions. The only problem this leads to is that it's possible to break one solution from another. This is where automated builds on commit to source control come into their own.
Put shared codes in separate Solution/Project as Class Library,
In post build event of shared projects copy dll's to a specific directory,
Add shared dll's from this directory to other projects/solutions
By doing this each time you build your consumer projects, they will use latest dll's automatically.
Moving the common code into a separate shared assembly is an excellent option.
One thing to think about is to keep your common business logic or business object type code separate from UI related code like custom controls - if you need to then have two common assemblies. This is more work initially, but makes things way easier further down the track when you need to make UI changes or change the control suite you are using.
Maybe that's silly, but I'm confused again when trying to find appropriate names for my projects.
I have a solution with two projects. First project is a library, which will be used by other libraries in the future, for creating plugins for my app. Second project is a exe, which uses first project to create GUI and do some stuff, eg. load plugins.
In similar situation, when one project is a dll and second is an exe, how do you choose names for each project?
Lets say, that I would like to peek a name GraphDemonstration. The exe should be GraphDemonstrationGUI and dll - GraphDemonstration? But exe is not just a GUI. So maybe GraphDemonstration for exe and GraphDemonstrationLib for dll?
I have had similar situation in the past. Maybe there is some kind of naming convention? I don't even know if my "problem" is related to VS only.
GraphDemonstration for your EXE is fine because it describes the purpose of the EXE. However, you said the library will be used by other projects later so the "GraphDemonstration" part of GraphDemonstrationLibrary may not be the best choice. Perhaps GraphLibrary, or GraphHelper, or maybe more specific depending on what is actually included in the library. For example, if the library handles instantiating an Excel object to generate a graph you could call it ExcelGraphHelper.dll.
If this is library of main class CSomeClass I name project SomeClassLibrary.
For projects smillary but non from main object.