Most used/useful Visual Studio addons?

Coldblackice

[H]ard|Gawd
Joined
Aug 14, 2010
Messages
1,152
Curious what other [h]'ers do with their Visual Studio setups. What addons/plugins do you use, and/or which are most useful to you?

"Visual Assist X" seems to be a pretty useful one. I'm curious about others.

(...and I have to ask here so I can "definitively" stop myself from searching on the subject anymore, hours later, giving in to my obsessive habit to research/improve/tweak endlessly :) )
 
ReSharper is a very significant plugin for me. I've also got the Visual Studio diff'ing hooks to use Beyond Compare.
 
Resharper is useful, but I personally don't use it. I've tried it a few times and most of the basic refactorings have found their way into visual studio. The code analysis is interesting, but I'd have to really spend some time going through the rules and configuring them to my standards. I hear it is good if you setup in a new job and someone hands you "their profile" which is already setup. Personally, I didn't feel like I needed anything in Resharper as much as people like to act like you must have it.

If you use SVN then a plugin like VisualSVN or AnkSVN is very useful. I use VisualSVN and it works well, but has license fee. AnkSVN I hear is free.

I also have a scroll bar replacement, it shows a miniature version of my code as the scrollbar.
 
Visual Assist X although its license cost may cause me eventually move to QtCreator in the future. I mean as a member of an academic institution the annual cost of Visual Assist is more than we pay for Microsoft Office + Visual Studio + Windows. I also use VSCommands lite but only for the reload feature on external project changes.
 
Resharper is pretty useful. I haven't worked somewhere that didn't have a coding standard of some kind, and Resharper is good for making it incredibly easy to follow any reasonable standard.

NuGet is also great, and again this is especially true if you're working for a company and other people will be collaborating with you. If I create a project and don't use something like NuGet, a lot of time is going to be wasted, through both other developers trying to set up their environment to build the project and myself having to assist them with that activity. With NuGet, when someone else opens my project they won't have to worry about resolving dependencies.

Whatever source control you're using is another thing you should try to integrate with Visual Studio. With Team Foundation Server, this is almost trivial, but if you're using something else, it's nice to have those integrated.

....And like PTNL said, it's always useful to be able to use some sort of merge/comparison tool. I like AraxisMerge, but I've also used BeyondCompare, and both of them offer a lot of value. Try to find a merge/comparison tool that can be used with Visual Studio easily.
 
Resharper is amazing. It makes programming so much easier and faster, especially the tedious parts.
 
Just looked at Resharper. Looks to me like it is a tool for people who do not want to spend the time learning how to code and optimize properly.
 
Resharper is amazing. It makes programming so much easier and faster, especially the tedious parts.

Can you tell me which portions of it are a must have for you? I've looked at getting it, but I dunno.. I don't really feel that it's shortcuts are something that I do that frequently. Give me like a top 5.
 
Can you tell me which portions of it are a must have for you? I've looked at getting it, but I dunno.. I don't really feel that it's shortcuts are something that I do that frequently. Give me like a top 5.
I'll throw in some of my favorites, and in no particular order...
- Intelligent search across file names, object names, project names, etc. (e.g. Typing "customer" will return a list of any files or classes having that word in the filename or contents, and is considered across all projects in the solution.)
- Code stubs and generating boilerplate implementations. (e.g. constructors, and quickly changing a public property's "get; set;" to auto-create private members and implement their usage in the public property)
- Forcing a constructor to change its signature or add a new signature from just the implementation.
- Moving classes between projects and propagating reference, namespace, and class name changes to any usages and dependent projects.
- Consolidating various for/foreach loops into LINQ statements. Though sometimes I ignore their suggestions if it drastically sacrifices clarity for brevity.
- Bulk code formatting against a particular code style.
- When viewing a file's contents, a hotkey can force the Solution Explorer to immediately scroll to and highlight the file being viewed. (Helps when you have a large number of projects in a solution, and don't want to visually scroll/seek through the entire list.)
- Complex highlighting and copy/pasting options. (e.g. copy the selected line and insert to the line below, and repeated presses of a hotkey selects a logically wider amount of data from where the cursor is located)

Granted that some of these may be partially/fully implemented in VS2013, and I haven't looked at a vanilla VS2013 installation to see what is and is not supported. But these are some offhand features that I have been using for several years.
 
Last edited:
Whatever source control you're using is another thing you should try to integrate with Visual Studio. With Team Foundation Server, this is almost trivial, but if you're using something else, it's nice to have those integrated.

I prefer to have this not integrated and instead do commits the explorer addons. I mean TortoiseGit and TortoiseSVN. Updates I usually do via a batch file out of a cmd.exe window that I always have open during coding.. The reason for that is the batch file updates from 8 or so different projects at one time. So I execute different batch files to update, configure (regenerate solution), compile and install (which generates an installer).
 
Looks to me like it is a tool for people who do not want to spend the time learning how to code and optimize properly.

Nope, it's a tool for people who already know how to code and optimize properly, but have much, much more important things to be doing than wasting their time manually doing things which can easily be done automatically.

If you've ever used a compiler, you're a hypocrite. I can write efficient code in assembly, for example, but I choose not to because I would waste my time implementing loop structures and other constructs that have already been implemented. Compilers have already solved those problems for me, so I can focus on the high-level design and making the application meet business needs rather than re-inventing the wheel over and over.
 
I think I may reinstall the resharper trial and give it a try and see how it goes.

Intelligent search across file names, object names, project names, etc. (e.g. Typing "customer" will return a list of any files or classes having that word in the filename or contents, and is considered across all projects in the solution.)
Sounds useful once you get into the habit of bringing it up to quickly jump between things.

- Code stubs and generating boilerplate implementations. (e.g. constructors, and quickly changing a public property's "get; set;" to auto-create private members and implement their usage in the public property)
Anything that makes get; set; accessors easier is good, can you create other get;set; formats? (For example, could I take an auto get;set; and convert it to a get and set which properly implements INotifyPropertyChanged with a backing variable?)

- Forcing a constructor to change its signature or add a new signature from just the implementation.
I know visual studio 2008+ allows you to add or reorder parameters to a method. I'm guessing resharper does a bit more.. One thing that is probably useful is to write out some code that uses a non-existent class and have it auto create the class for you. SomeNewClass c = new SomeNewClass(param1, param2); I think it will auto create that class + ctor for you which visual studio doesn't.

- Moving classes between projects and propagating reference, namespace, and class name changes to any usages and dependent projects.
Interesting... but it isn't an extremely common thing for me to need.

- Consolidating various for/foreach loops into LINQ statements. Though sometimes I ignore their suggestions if it drastically sacrifices clarity for brevity.
When I played with Resharper briefly, some of the foreach->LINQ suggestions it suggested were a terrible idea. I'm not sure if there were better uses for it.. I think it did suggest something foreach(var in list.Where(x => ...)) as opposed to something like foreach(var in list) if(....) which does makes sense.

- Bulk code formatting against a particular code style.
Yeah, I agree that is useful. I'd have to configure all my rules over time though to make it conform to my coding style.

- When viewing a file's contents, a hotkey can force the Solution Explorer to immediately scroll to and highlight the file being viewed. (Helps when you have a large number of projects in a solution, and don't want to visually scroll/seek through the entire list.)

Interesting. When I hear things like this I know it must be useful but I have a hard time thinking of a use case.. usually if I'm wanting to find a file it's so I can click on it to go to it. Once I had it open, there's less reason to want to find it in the solution explorer. I suppose if I wanted to delete it... hmm

- Complex highlighting and copy/pasting options. (e.g. copy the selected line and insert to the line below, and repeated presses of a hotkey selects a logically wider amount of data from where the cursor is located)

Interesting. I also seem to remember it could move entire methods up / down with a hot key which is handy.
 
In what way? Do you remember any examples?

I actually just reinstalled it. here's one, the following code finds the LocationViewModel for which the Location has been removed and removes the LocationViewModel that corresponds with it.

Code:
if (e.OldItems != null)
{
	foreach (Location l in e.OldItems)
	{
		LocationViewModel deleted = childrenCollection.FirstOrDefault(x => x.Location == l);
		if (deleted != null) // only if externally modified
			childrenCollection.Remove(deleted);
	}
}

versus Resharper's suggestion:

Code:
if (e.OldItems != null)
{
	foreach (LocationViewModel deleted in e.OldItems.Cast<Location>().Select(l => childrenCollection.FirstOrDefault(x => x.Location == l)).Where(deleted => deleted != null))
	{
		childrenCollection.Remove(deleted);
	}
}

The first one is pretty readable, the second one is ugly.

edit: Also..

I never want to use query style syntax, I prefer the chained LINQ extension method syntax. Can I force it to never use the former? It's odd in the above case it used chained LINQ extension methods, but in another case it uses 'from ... select ... where.. ' which I do not want
 
Last edited:
Anything that makes get; set; accessors easier is good, can you create other get;set; formats? (For example, could I take an auto get;set; and convert it to a get and set which properly implements INotifyPropertyChanged with a backing variable?)
Not sure, I can certainly take a look.

Interesting... but it isn't an extremely common thing for me to need.
Right -- It isn't common for me as well, but is wonderful for the few times that I do need it.

When I played with Resharper briefly, some of the foreach->LINQ suggestions it suggested were a terrible idea. I'm not sure if there were better uses for it.. I think it did suggest something foreach(var in list.Where(x => ...)) as opposed to something like foreach(var in list) if(....) which does makes sense.
For me, it's more of a subjective judgment call. Though if I see a whole bunch of "let" statements, then that is usually a clear sign to revert it.

Interesting. When I hear things like this I know it must be useful but I have a hard time thinking of a use case.. usually if I'm wanting to find a file it's so I can click on it to go to it. Once I had it open, there's less reason to want to find it in the solution explorer. I suppose if I wanted to delete it... hmm
For me, this feature gets used as a side-effect of tracing through through a chain of code files and methods. After enough forward/reverse traversal through various files and projects, I sometimes need to know what specific file I am looking at and, more importantly, the project it is in. So being able to press a hotkey to immediately highlight the file in the Solution Explorer is nice thing. I wouldn't consider its loss as disastrous to productivity, but it's certainly been an "icing on the cake" type of feature for me.
Edit: I guess I could mouse-over the tab in Visual Studio, and logically figure out based on the displayed path in the tooltip, but doing so takes more time than a hotkey.
 
Here's my current plugin list minus the source control related plugins:

ViEmu (though I probably will be switching to VsVim soon)
Resharper
StyleCop
DotCover
NuGet
 
I actually just reinstalled it. here's one, the following code finds the LocationViewModel for which the Location has been removed and removes the LocationViewModel that corresponds with it.

Code:
if (e.OldItems != null)
{
	foreach (Location l in e.OldItems)
	{
		LocationViewModel deleted = childrenCollection.FirstOrDefault(x => x.Location == l);
		if (deleted != null) // only if externally modified
			childrenCollection.Remove(deleted);
	}
}

versus Resharper's suggestion:

Code:
if (e.OldItems != null)
{
	foreach (LocationViewModel deleted in e.OldItems.Cast<Location>().Select(l => childrenCollection.FirstOrDefault(x => x.Location == l)).Where(deleted => deleted != null))
	{
		childrenCollection.Remove(deleted);
	}
}

The first one is pretty readable, the second one is ugly.

I take preference to the second one. For starters, I don't find any difficulty in reading the second one, so I don't see how it's ugly. More importantly, though, the second one more accurate describes the logic you're actually trying to implement. The second one is 'get every element which meets a condition and do something to it, whereas the first one is get every single element, get another element based off of that element, test it to make sure you need it and then do something to it.

A loop should be:
Code:
<what items to get>
{
    <what to do to it>
}
...not:
Code:
<get every item>
{
    <figure out which ones you wanted>
    <what to do to it>
}
 
I take preference to the second one. For starters, I don't find any difficulty in reading the second one, so I don't see how it's ugly. More importantly, though, the second one more accurate describes the logic you're actually trying to implement. The second one is 'get every element which meets a condition and do something to it, whereas the first one is get every single element, get another element based off of that element, test it to make sure you need it and then do something to it.

A loop should be:
Code:
<what items to get>
{
    <what to do to it>
}
...not:
Code:
<get every item>
{
    <figure out which ones you wanted>
    <what to do to it>
}

I agree with this. To make the suggestion cleaner, you can refactor further:

Code:
foreach(var location in GetLocationsToRemove(e.OldItems))
{
    childrenCollection.Remove(location);
}

function IEnumerable<LocationViewModel> GetLocationsToRemove(... OldItems)
{
   if(OldItems == null)
     return new LocationViewModel[0];
  
   return e.OldItems.Cast<Location>()
          .Select(l => childrenCollection
                .FirstOrDefault(x => x.Location == l))
          .Where(deleted => deleted != null)
}
 
I understand what you guys are saying and for a case like this I think it makes a lot of sense:

Code:
foreach(Person p in People)
	if(p.Sex == Sex.Female)
		// do something
		
foreach(Person female in People.Where(p => p.Sex == Sex.FemalE))
	// do something

And maybe, arguably for my case it also makes sense. But to what end? How many nested selected statements with a LINQ expression until it is illegible? If I gave both pieces of code to someone new to .NET and LINQ which do you think they'd understand easier? Which version do you think is easier to craft by hand? (and how many levels deep) If it is easier to craft the multi-step version by hand, does it imply that it would also be easier to read? I think it is at least thought provoking.
 
If I gave both pieces of code to someone new to .NET and LINQ which do you think they'd understand easier?

It depends. If they're a Java developer, they might struggle with the lambdas briefly. But there a lot of people whom are very familiar with the notion of lambda expressions (because they use languages which feature them. Most do, in fact) and the notion of LINQ is not by any stretch of the imagination complicated, so plenty of non-.NET developers would have no trouble grasping the more expressive code. Either way, give it a couple of hours and they'll no longer have any amount of trouble with the LINQ version.

Regardless, though, I don't write my code to appeal to someone who doesn't understand .NET and LINQ. Readability and code clarity is about making sure a competent developer can understand your code...it's not about avoiding significant language features for the sake of not intimidating someone who isn't familiar with the language you're using. Any competent .NET developer should be able to look at a simple LINQ-driven loop like in your example and understand what it is expressing.

How many nested selected statements with a LINQ expression until it is illegible?

Nested expressions there mean your original code had a lot of nested if statements. If the corresponding LINQ expression is hideous, it's because the original loop was hideous. It would have been hideous either way, and if you really find yourself writing code that turns into n-nested lambdas or n-nested if statements, you're probably writing bad code, so it's a symptom of developer incompetence not a symptom of LINQ being illegible. You shouldn't really end up with 5 or 6 nested statements. That's code-smell.

Which version do you think is easier to craft by hand?

If you find it easier not to write nested lambda expressions, you've just found an example of a reason to use ReShaper. If you find it easier to just write the nested lambda expressions (I do), then there really is no problem here.
 
Last edited:
Kinda going on a tangent here but Dogs brings up a good point. Your nested loops may be a code smell.

If we examine what the code is trying to do, we'll see that we're simply trying to remove the locations contained in OldItems from childrenCollection.

I'm not sure on the actual type of childrenCollection but if it's a List or Collection type, you do not need to check for the existance of the item as you currently are doing.

Your code can be reduced to the following:

Code:
if(e.OldItems == null)
    return;

foreach(var location in e.OldItems.Cast<Location>())
{
    childrenCollection.Remove(location);
}
 
How many nested selected statements with a LINQ expression until it is illegible? If I gave both pieces of code to someone new to .NET and LINQ which do you think they'd understand easier?

As many as are needed. You shouldn't develop towards someone who is new to a language (unless you're teaching); assume some language proficiency from users.

If I'm nesting, I usually break it down something like this:
Code:
            var newPagesToTest = Types.PageViews.GetFromX(x)
                .Where(view => view.StatusCode == 200 
                            && view.FinalUrlID.HasValue 
                            && !alreadyTestedPages.Any(testedPage => testedPage.PageUrl == view.FinalUrl))
                .Select(page => new { PageID = page.FinalUrlID.Value, PageUrl = page.FinalUrl})
                .Distinct();
 
Your code can be reduced to the following:

Code:
if(e.OldItems == null)
    return;

foreach(var location in e.OldItems.Cast<Location>())
{
    childrenCollection.Remove(location);
}

Well not quite.. This code isn't really finished and it has been some months since I've looked at it, but if I recall correctly... here's what is going on.

I have a tree of Locations that is being displayed in a WPF TreeView with various edit commands. Therefore, each node in the Location tree is wrapped with a LocationTreeViewModel which has those commands and display properties. Each LTVM has a collection of children LTVMs because it is of course a tree as well. (It's very similar to a directory tree in explorer). The code synchronizes changes which may occur externally to the class in the model's child collection with the ViewModel's child collection. If you are familiar with WPF this is the way I've done it to bind the hierarchical data template to the proper commands in the view-model.

So to explain, Children is a collection of LocationViewModels, while e.OldItems in this case is a Location (model data). The code basically looks to see if a ViewModel exists for the deleted location, and if it does, it also removes the ViewModel.

I think there could be a way to clean it up, because I believe (and I'm not sure I remember that well) that the only way a ViewModel would not exist for a deleted Location is if its Parent ViewModel in the tree was responsible for deleting it (Not from an outside influence to the model data). So perhaps the solution is to intentionally NOT delete the ViewModel but instead just modify the model data directly, and allow the above synchronization method to handle removal of the ViewModel. This would allow me to at least assume that I'm just locating the correct ViewModel to remove. But that may only save me the FirstOrDefault call and null check.. I'd have to look into it more, but I'm not really looking at this piece of code at the moment.

Off topic, but since I was looking at it, I refactored it as so:

Code:
// if the location's children collection is modified externally to this object, this keeps the view model collection in sync
private void OnSubLocationsCollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
	if (e.NewItems != null)
		foreach (Location locationWithoutViewModel in GetLocationsWithoutViewModels(e.NewItems.Cast<Location>()))
			Children.AddNewItem(new LocationViewModel(dialogs, siteService, locationWithoutViewModel, this));

	if (e.OldItems != null)
		foreach (LocationViewModel viewModelForDeletedLocation in GetViewModelsForDeletedLocations(e.OldItems.Cast<Location>()))
			Children.Remove(viewModelForDeletedLocation);
}

private IEnumerable<Location> GetLocationsWithoutViewModels(IEnumerable<Location> newLocations)
{
	return newLocations.Where(newLocation => Children.Cast<LocationViewModel>()
							   .All(viewModel => viewModel.location != newLocation));
}

private IEnumerable<LocationViewModel> GetViewModelsForDeletedLocations(IEnumerable<Location> delLocations)
{
	return delLocations.Select(delLocation => Children.Cast<LocationViewModel>()
							 .FirstOrDefault(viewModel => viewModel.location == delLocation))
	                  Where(viewModelToDelete => viewModelToDelete != null);
}

edit: formatting got messed up in [H]ardForum
 
Last edited:
Anything that makes get; set; accessors easier is good, can you create other get;set; formats? (For example, could I take an auto get;set; and convert it to a get and set which properly implements INotifyPropertyChanged with a backing variable?)
Not sure, I can certainly take a look.
Follow-up on this... I started working on a code template, but was not getting the desired integration from the ALT+ENTER context from INotifyPropertyChanged and the public property. Then a brief Google-ing showed me that this feature has been in ReSharper since version 7.

The reason why I wasn't seeing it in the context selection was because ReSharper wasn't aware of the right implementation to consider. Once I included the ReSharper code annotations in my project and added proper decoration on the implementation ("NotifyPropertyChangedInvocator"), then the desired context choices appeared to modify a "get; set;" implementation to have a backing field with notification callout.
 
Last edited:
Follow-up on this... I started working on a code template, but was not getting the desired integration from the ALT+ENTER context from INotifyPropertyChanged and the public property. Then a brief Google-ing showed me that this feature has been in ReSharper since version 7.

The reason why I wasn't seeing it in the context selection was because ReSharper wasn't aware of the right implementation to consider. Once I included the ReSharper code annotations in my project and added proper decoration on the implementation ("NotifyPropertyChangedInvocator"), then the desired context choices appeared to modify a "get; set;" implementation to have a backing field with notification callout.

oh wow.. yeah that's cool. I didn't know it already does this and it even has the option to use the lambda to make it refactor safe when inheriting NotificationObject.
 
Indent Guides.
It still boggles my mind that VS doesn't have such a feature by default. I imagine, though, that DevDiv is too busy making rapid, high-quality improvements to their C++ compiler to be able to find the time.

(lol)
 
It still boggles my mind that VS doesn't have such a feature by default. I imagine, though, that DevDiv is too busy making rapid, high-quality improvements to their C++ compiler to be able to find the time.

(lol)

I tried indent guides out, I dunno.. I disabled it. I couldn't justify the extra visual noise considering I can already tell if something is indented or not. I'm not sure I understand its purpose.
 
It's helpful to be able to toggle them on and off in cases where there's a lot of meat between indent levels. It's very easy to discern indentation when indented blocks are short, and when there aren't many levels of indentation to begin with, but it's great to be able to reach for the guides when you really need the visual clarification.

Another conspicuously absent feature from VS is a customizable guideline, which either needs to be registry-hacked in or an extension used to enable it.
 
If your code blocks are so long that you need an indent guide, it may be time to consider refactoring your code.
 
It's helpful to be able to toggle them on and off in cases where there's a lot of meat between indent levels.

You know, that's exactly what I looked for but it didn't appear to support shortcuts to allow it to be toggled and honestly I'm not sure I really needed it other than to toggle it for coolness on occasion.
 
If your code blocks are so long that you need an indent guide, it may be time to consider refactoring your code.
Depends on the language. It's been my experience writing asynchronous, callback-heavy JavaScript apps that long, heavily-spaghettified functions are frequently unavoidable. Despite the availability of promise interfaces and being able to use named callbacks, you're still very much at the mercy of closure captures, and that limits what you're able to do to sensibly break up code.

In other languages and in other scenarios, yeah, I'd argue that you're generally right. But one doesn't always have the luxury to re-factor code you need to look at (when's the last time you refactored any of the C++ libraries you used, including the STL implementations you use?)
 
Depends on the language. It's been my experience writing asynchronous, callback-heavy JavaScript apps that long, heavily-spaghettified functions are frequently unavoidable. Despite the availability of promise interfaces and being able to use named callbacks, you're still very much at the mercy of closure captures, and that limits what you're able to do to sensibly break up code.

In other languages and in other scenarios, yeah, I'd argue that you're generally right. But one doesn't always have the luxury to re-factor code you need to look at (when's the last time you refactored any of the C++ libraries you used, including the STL implementations you use?)

Yeah that's a good point about legacy code. Sometimes you have to work with what you have.
 
Got pretty far off topic, but I use:

Visual Studio 2012 / 2013
-- Web Essentials
-- Productivity Power Tools
-- Resharper
-- AutoHistory (basically git style commit for each file when you save, but not actually commited to anything just local, still use source control ;))
-- nCrunch for always on tests
-- SideWaffle Templates
 
Got pretty far off topic, but I use:

Visual Studio 2012 / 2013
-- Web Essentials
-- Productivity Power Tools
-- Resharper
-- AutoHistory (basically git style commit for each file when you save, but not actually commited to anything just local, still use source control ;))
-- nCrunch for always on tests
-- SideWaffle Templates
Thanks for the reminder about the "Web Essentials" plugin; I had forgotten about that one. I'll check out those other items, too.

In addition to Web Essentials, these are also added to my earlier list:
- Slow Cheetah for config file transformations
- NUnit for unit tests and integration tests
- WiX for creating installers
 
Currently installed in VS2012:
- Source control / SharePoint specific stuff
- Indent Guides
- Spell checker
- Web Essentials
- ReSharper
- NuGet

It's interesting to see so many using ReSharper. KingKaeru turned me onto it a couple years ago and I can't imagine visual studio without it. It would be like turning off intellisense.
 
One I haven't seen listed: collapse anything. I use that for C#, because by default only comments, regions, and method blocks are collapsible.
 
Back
Top