I am building a class library, and I am getting an error and I know that I need to add a reference.
Does VS have a feature where it will find the required library automatically, or do I need to know where the library is located and add the reference manually.
In java/eclipse, you may right click like and jars will be found automatically if on the build path, does VS have this concept?
We use Resharper for that feature and a lot of many other improvements to the IDE.
Couldn't use Visual Studio anymore without it.
ReSharper has a feature to do this. If it knows which assembly has the referenced type, it will suggest adding that assembly as a reference.
If you go alt+shift+F10 on the item that's missing a using it will suggest you the appropriate option (but you obviously need to have the assembly referenced already).
I am not aware of any way of running this on all the items in a single go though (without ReSharper).
Related
I have a C# project which contains references to assemblies in DLL format. I have the PDB information for these DLL files, contained in the same folder. When I press F12 on a referenced member, I want to go to the definition of the member. Instead, it gives me the metadata, which of course I don't want.
When VS is debugging, it does go to the source code if I single step into that method. But if I press F12 on that method, it still brings me to the metadata.
There is a similar question here, but it only applies to project references, and the accepted solution has nothing to do with my issue.
"Go To Definition" in Visual Studio only brings up the Metadata
To summarize:
Referenced project is a DLL
I have the PDB information
Single-stepping in debug-mode brings me to the source code
F12 brings me to metadata
I want F12 to bring me to the source code as debug does.
EDIT: Adding as a "Project" is not an option as it creates additional complexity as our solution file references about five other projects which are all under separate source control repositories.
In Visual Studio expand the References section, select the reference to your related project (the one that contains the source code you want to F12 into) right click on it and select "Remove".
Then add the reference back to the project by right clicking on References and selecting Add Reference, under the Projects tab (if your using VS 2012) select (or browse for) the project you want to add a reference to and then click the OK button.
This will rebuild the reference and you will be able to F12 into the referenced projects source code. You will need to do this with all the projects in your solutions that are having this issue.
I don't know why this happens but at least the solution to the problem is rather simple
If you have ReSharper installed, you should bring up ReSharper options, and look for External Sources. There you can specify the relevant options:
It appears that this issue has been solved in Visual Studio 2013. Having the PDB information in the same folder as the DLL is showing me the source code when I use Go To Definition. I do not have the Reflector extension installed.
Is the referenced DLL a project in your solution? I find that when I have the source code for the project, and it's in my solution, Visual Studio is able to link to this code much more easily. (without showing me meta data).
Also, be sure to add the reference by "Project" in the References popup.
This is generally what I do anyways when I have this problem
Hope this helps!
PS. PDB files are usually just for debugging (both locally and remote) and are not used for source code reading in the way you are attempting to use it. ("Go To Definition")
One solution to this issue is to use .NET Reflector, VS or VSPro edition. This program will modify Visual Studio to provide the required functionality.
http://www.reflector.net/
Unfortunately, it costs $135 to $195, which isn't an option for everybody.
Add the reference as a project instead of ..\bin\Debug\referenceFile.dll
That solved my issue
I also used add reference as a project and my problem has been resolved and it's working great. Actually I was stuck at this point from very long time and finally i resolved this issue.
References -> Add References -> Solution -> Projects -> Select reference
I'm using Visual Studio 2012.
In most solutions I have lots of projects which reference each other.
It's quite time consuming to always add the reference manually.
Is there a simple way (either built-in or via extension) to include a missing reference to an assembly in the own solution similar to the way missing usings are resolved?
Resharper does exactly this. If there's a class that is defined in another project in the solution, it offers you to reference that class and import the namespace. All you do is press "Alt+Enter, Enter" to pop up context menu and select the first option.
As mentioned before, resharper will be a good solution for your request. but if you are looking for a free visual studio extension that does the same you can use 'WoVS Quick Add Reference' extension.
Some info: http://ihadthisideaonce.com/2011/07/29/recommended-wovs-quick-add-reference/
Download link: https://visualstudiogallery.msdn.microsoft.com/dc06b54c-b6c4-4cf5-8203-a09c6979e881/
I hope it supports your questions..
This extension at least offers a way to add references to GAC assemblies
visual studio gallery
But it requires CodeRush and so also isn't a free choice.
I wrote a control library using visual studio 2010, I'll call it MyLibrary. MyLibrary references another control library I have that we'll call AnotherLibrary. I also have a clean virtual machine (CVM) and I've added AnotherLibrary to the GAC on the CVM. Using the CVM, I create a new WinForms project, add MyLibrary.dll to the toolbox, and drop one of the controls onto the form. Visual Studio will add MyLibrary.dll AND AnotherLibrary.dll to the references, even though AnotherLibrary.dll is in the GAC (and isn't needed). I can remove AnotherLibrary.dll from the references and everything is fine.
Is there a way to prevent visual studio from adding AnotherLibrary.dll in this scenario?
Edit: I've given this some thought and I have an example. When you add a TabControl to a parent control in the designer, visual studio won't add System.Design to the references, even though the TabControl depends on it. So, surely there is a way to do this?
You still need the reference. Just like you need the reference to, say, System.dll which is also in the GAC. You just don't need the copy of the assembly in your bin\Debug directory. That you happened to not break the compiler by removing the reference is possible, especially since is this is an indirectly used assembly. But some odds that you'll eventually run out of luck.
In general you really want to avoid using the GAC on your dev machine. Because you care about specific versions of an assembly when you, say, create a bug fix. You get those specific versions from source control, not the GAC.
Doesn't it make sense that it would automatically include all dependencies? It cannot assume that AnotherLibrary is in the GAC on every machine you might want to deploy your code on. Of course as you mentioned you can manually remove it....
Go To definition in Visual studio 2005 works only for files that are in my project. It never works for files that are included in external libraries like mfc. When I say Go To Definition for mfc function it always shows me the header file . Is this expected behavior?
And also how does this whole thing Go To Definition work?
Thanks
I'd make the small investment required in Visual Assist. Besides all the great features it offers, it has the Alt+G command which works way better than the Visual Studio go to definition :)
For the MFC source files (at least the Feature Pack ones) I learned to find out what folder are they in (usually at C:\Program Files\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc) and add that folder to the Find in Files dialog.
It's not as direct as Go to Definition, and you may have to browse among the find results, but it works...
Note: I second #flippy's answer of Visual Assist, it's really great.
External libraries are references to their compiled DLLs rather than the source when referencing your own projects.
The idea is that you don't need any more than the interface to external classes, but, if you would like to see the internals of DLLs you can use a tool such as Reflector.
Yes only the interfaces for MFC will be given in header file.Unless it is implemented with Template you will not be able to access the actual definition.The dlls have implementation for those interfaces.
Well if you think about it logically, as far as visual studio knows the only definition of the MFC object that is available is the definition it sees in the associated MFC header file, so unless you actually have the entire source for MFC it won't be able to look anywhere else.
The way that intellisense/go to definition works is via a file that is created when you compile the application. It stores a mapping between variables/functions and where they are declared (or could potentially be declared, in polymorphic situations), and when you right click to say "go to definition" it references that file.
Yes this is the expected behavior. Only the declarations (header files) of the MFC code are available on your box and hence that is the only location that it can take you to.
What are you expecting it to show?
I am hoping someone can help me with this. What I have been looking around for but can't seem to find is if there is someway to add an event, or anything else that will allow a visual studio plug-in to watch for an external reference to be added to a currently open solution / project?
Or even better yet would anyone happen to know of an add-in that automatically adds all controls from a referenced dll into the visual studio toolbox?
Thanks.
Not exactly what you asked, but I've written a Visual Studio 2008 Integration Package, and if I recall correctly I could override the "add reference" method, as well as inherit the "reference node" and thus change its behavior, for example its constructor.
This functionality might be missing from an add-in (which is more limited than an integration package), so you might consider writing a package instead.
I have written a macro that will change a file reference to a project reference if you add the project to the solution (and vice versa), but I don't think that's what you want?