I develop WinForms applications.
How can I understand which references that I have added to my application are in use, and which ones are unused?
If I don't remove unused references, will they degrade my application performance?
Unused references will not cause any performance loss when you run your application. Your references are used at compile time to look up unknown symbols.
It is just extra information given to your compiler; telling it where to look for symbols. When the compilation is over, it is no longer needed.
One way to see if reference is used by your code (without external tools) is to simply remove that reference and compile.
Used in the code? You'll get nice error message, just add it back.
Not used? Compile succeed and you can leave it removed.
If the reference is to your own project in the same Solution and there are few classes only, you can right click each class in Visual Studio and choose Find All References - if something is referencing that class you'll see it.
You can use extensions for VS. You can find them in VS Gallery. You can try this one:
Reference Assistant
Related
I have a class library lets call it UtilityLibrary.
I have a console application. So I right clicked on my solution and added an existing project (UtilityLibrary). I noticed that I can change the code of UtilityLibrary from within my console application.
The issue is if I had added UtilityLibrary to another application and the code had been changed it could causes issues. I was trying to avoid adding a dll reference so thought I would add a reference to my project however I am worried about the code being edited.
Have I added the reference to my project incorrectly?
If you where to check the Debug or Release folder if your console application you should see a UtlityLibrary.dll file, which would still mean that you are, in the end, adding a DLL reference (visual studio will do it for you).
Since you do not want to allow external entities to change your application, simply add a DLL reference instead.
Just to clarify, you can only change the source of one DLL from another application becuase visual studio can find the source files and makes them available to you.
No. You have done nothing wrong. And you can't just change the code of the compiled assembly. You are utilizing a feature from Visual Studio. Since you've build on this machine, and the PDB's are included, it can tell the assembly originated from that source code on your machine. So it allows you to edit it.
These edits don't come in the compiled assembly immediately, you have to compile it again in order to be in the assembly. (Note that you can extract the source code from any .NET assembly by using Refactor for example)
I have a need to identify if I'm referencing a specific assembly in my project/solution. I've not found an easy way to do this (I want to do it at design time and not run time if possible).
Seems this should be easy, but I'm not finding a way in VS, directly. Ideally, if I could see what/where I'm referencing (assuming that I am) would be great, too, so I can remove such references from my code.
Simply searching for "Assembly." in my code turns up nothing, now, for example.
A concrete example is in order: I want to know if I use anything in System.Reflection.Assembly. And I'd like to find the code that does it (in my source) if I do.
Do you want something like Assembly.GetReferencedAssemblies Method ?
http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getreferencedassemblies(v=vs.110).aspx
In Visual Studio (almost all versions) open the Solution Explorer window the second "folder" is the References section. If you expand that you'll be able to see the referenced assemblies.
Image from robowiki
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instance for each library and application. After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
Would like to understand why this happens and if something can be done to make this work more smoothly?
Not sure if it's relevant but most of my applications I write in VB.NET and libaries in C# (as I'm in progress of changing everything to C#). I also have C# files from the libraries open in the consumer application VS, as it pops up during debugging. I also reference library dlls in the library project /bin/Debug folder, because I'm making a lot of changes at this point of development.
Warning 1 Namespace or type specified in the Imports 'somelibrary'
doesn't contain any public member or cannot be found. Make sure the
namespace or the type is defined and contains at least one public
member. Make sure the imported element name doesn't use any
aliases. 'local path'
..
Error 72 Unable to load referenced library 'path\somelibrary.dll': The
process cannot access the file because it is being used by another
process.
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instances for each library and application.
This is the fundamental source of your problem. Visual Studio does not like it when things outside it's control change. You should have a single solution open with all the relevant projects included in it. Then when something changes, all the projects which depend on that project will automatically be rebuilt. (At least, that's the default.)
After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
I don't think it has anything to do with how many times you clean and rebuild it, but how long it's been since you last made a change - you have to wait long enough for the VS instance building the dll to release the lock on the file, before the VS instance that is using it is able to access it.
When you build a project you lock up the .DLL file in the project you build it from, because that is the version of the assembly that the library instance of visual studio will use - however you are referencing that very same library in another process hence the reason you are seeing the error.
You have two options, keep having two instances and then close the two instances open them again and it will be fine.
What you are better off doing is adding the project itself you are referencing (and are getting the error for) to your solution. Then instead of referencing YourProject/bin/debug/assembly.dll add a reference to the local project via the Projects tab. This will then keep one process referencing the appropriate assemblies that it needs.
For every project in the solution check the project settings -> Compile tab -> advanced compile options... -> target framework(all configurations), see if they are all (for example) .NET framework 4. having different or the wrong framework might cause the problems you're having right now
Is there any reason for it is not possible with Visual Studio to remove unused references (to projects and assemblies) in C# and C++ projects while it is possible to do so from a Visual Basic project (see here)?
I know you can do it with other tools like Resharper, I was just wondering if there was any technical reason for not being able to do this in C# and C++ projects? Or did Microsoft just choose it to work like that. It seems to be a quite useful feature.
Note that the compiler will automatically drop any unused references from the assembly, so at the assembly metadata level this is redundant. It then just becomes an IDE/tooling issue. Would it be impossible? no (although obviously it would need to keep any that are marked for copy-local, to ensure it gets deployed). We can probably assume, therefore, that it is simply a "time to implement vs utility" (compared to other more useful things that could be done).
I'm sure you could write an IDE extension for it if you wanted ;p
I found this suggestion on Microsoft Connect. It sounds like Microsoft actually thinks it is a good idea but just did not have the "time" (read: priority) to implement it. Too bad!
This functionality is there for VB (via the "Unused References" button on the References property page).But is the case of CSharp, For example, a user could add a reference to an assembly in order for it to get copied to the output directory. They might be using the assembly via reflection instead of compiling against it -- in such cases, there is no way for VS to detect that such an assembly is "used". So designing such algorithm is not 100% successful. But flag is a option that assembly mark as "unused" (however, the user would still have the choice as to whether to remove the assembly from the list of references).
Remove unused namespaces can do a bit work towards this.
How can I access the currently opened project's types(classes) from a Visual Studio add-in(be able to create instances of those classes within the add-in)? Is this possible through reflection? Or maybe dynamically include the project's assembly as a reference?
What I'd like to have in the end is a list of all types accessible from the project, taking into account referenced assemblies and types declared in the project itself. In absence of a method to actually find Type instances, a list of type names may do - this way, I won't run into problems if the project is not yet built and the types therein are not yet implemented.
I use Visual Studio 2008 and the language I prefer is C#.
Edit: I imagine I could parse each file and seek out class declarations, but I'd like to consider types from referenced assemblies as well. The references may be sought after by searching for "using" statements, but that leaves dynamically imported dll types an open issue. Thus, given the branching of separate situations to consider, I'm wondering if there isn't an easier way.
Sure, just get the assembly from the output directory and load it. I am not working on any EnvDTE projects right now so I can't just pop in and knock out a sample, but that is how you would be able to enumerate/instantiate classes.
But.... nobugz is hinting that something smells.. What are you trying to do? There may be a 'better' way to do it.
The Visual Studio code model offers automation clients the ability to discover code definitions in a project and modify those code elements.
For more information go to:
http://msdn.microsoft.com/en-us/library/ms228763(VS.80).aspx