Visual Studio 2010 has been out for over two months now. As I mentioned in a previous article, I give VS2010 a thumbs up. But I’m also a very picky developer who spends a lot of time each day within Visual Studio. So, even though I still give Visual Studio 2010 a thumbs up, the following is a list of features, additions, or issues that I would like to see addressed in the next version of Visual Studio.
Working IntelliSense with HTML Attributes
Desirability: Must have—currently busted.
Easily my favorite thing about Visual Studio is IntelliSense. In fact, hailing from a web developer background, I still remember the days when I used Visual InterDev and had absolutely no idea what the hell all of the bells, options, knobs, and levers did – but I didn’t care because InterDev gave me IntelliSense.
What baffles me though, is that a good 10 years after InterDev, Visual Studio 2010 doesn’t work within HTML attributes. I was certain this was one of those hideously annoying bugs in Visual Studio 2008 that was going to make my life so much easier with Visual Studio 2010. Only, Visual Studio 2010 IntelliSense doesn’t work within HTML Attributes either.
For example, if I’m working on an ASP.NET View, and need a <div> to have a dynamically populated id, IntelliSense won’t work. So, while coding the following, IntelliSense works as soon as I type the period after Model:
<p><%: Model.TopId %></p>
It even works in the following example (where I’m trying to outsmart it by wrapping stuff in quotes):
<p>”<%: Model.TopId %>”</p>
But if I try:
<div id=”Selection_<%: Model.TopId %>”><p>stuff goes here</p></div>
IntelliSense patently doesn’t work. At all. Same thing goes with a src, an alt, or any other attribute.
And, frankly, that’s insanely lame. So lame that I can’t quite understand how developers put up with it. Because, to me, it feels like a complete bug–especially when you think about all the amazing things that Visual Studio 2010 lets you do in terms of how well it knows and understands the DOM of any document you’re working with. So, fixing this one is a huge requirement for Visual Studio vNext in my book.
Font and Color Options for Attributes
Desirability: Really nice to have—added bonus.
Within my MVC applications I use attributes a fair deal to specify things like allowed HTTP verbs, caching directives, authorization requirements, and error handlers or SEO modifications, and so on. Consequently, it’s not uncommon for some of the Action methods within my controllers to almost get a bit of a “smell” to them in the sense that it’s hard to see the forest for the trees (or the logic through the attributes). The same thing goes with heavily componentized code as well – such as with DataAnnotations – as per Figure 1.
Figure 1: Attributes and Members – Hard to tell which is which.
Consequently, I had the great idea one day to zip into the Tools, Options, Fonts and Colors dialog box for Visual Studio 2010 and have it color attributes in a light-grey. Or, since I knew that VS2010 was written on top of all sorts of WPF goodness, my real hope was to be able to just tweak the Opacity of Attributes to some degree so that it would be easier to focus on methods and members at a glance, as per Figure 2.
Figure 2: Same code – but with “opaque” attributes.
My thought with this approach was that attributes would still be visible and easy to consume (or read) without stealing focus. Only, as near as I can tell, Visual Studio doesn’t have any way to target Attributes for styling. Consequently, this is a small feature that I would love to see added to Visual Studio vNext. (Even as an Add-In or Power Tool, etc.)
Desirability: Nice to have.
I’m a big fan of the Document Outline Window in Visual Studio – it’s a great way to get an “at a glance” overview of the DOM within an .ASPX (or .html) page while editing. I don’t use it all the time though, and that’s mostly because it goes dark when I switch over to a .cs or any other non .aspx/.html file.
What I would love though, would be a correspondingly useful window for working with C# (or VB.NET) files. Obviously, with code files there isn’t a DOM, but in the same way that the Properties Window (when working with a WebForm or WinForm) lets you toggle between alphabetized and categorized properties, it would be fantastic if you could get the same thing to provide a view of the code you’re working on. For example, in non-grouped mode, you’d just have a tree view showing the class itself, and all of its child-members. Members would be shown in the order they appeared within the file itself, and icons would show whether they were properties, methods, constructors, and so on. Then, double-clicking on one of these members would take you right to the code in question. Likewise, if you were looking at this window in Grouped Mode it would group all properties, methods, and so on into collapsible sections that you could navigate through and so on.
Right now the bottom-half of what you get in the Class View Explorer is VERY close to what I’m hoping for – only what’s displayed in the bottom half of the Class View Explorer isn’t synchronized with the file you’re currently editing. If it was (and if you could toggle between grouping different kinds of members or just seeing a representation of where members were physically laid out in the file), I think that would be very helpful. (There’s also that little drop-down thingy at the top right of .cs and .vb files that lets you select a member/method and go to it – which is fairly close to what I want but without the scrolling.)
In the end, this isn’t a make or break feature, but I can’t help but feel that having something like this could help me speed my way through files when I’m working on certain kinds of tasks.
Desirability: Really, really, really want.
I hate how the toolbar area (i.e., the collection of toolbars just below the menus) “bounces” up and down when you flip between different types of open files. For example, if you have a C# (or VB.NET) file open, along with a .CSS file, a .ASPX file, a .RESX file, and a .TXT file all open at the same time, each file type opens various toolbars. This usually means that the overall height of the toolbar area within Visual Studio is different for some, all, or each of these files. Yes, you can go in and try to stack and arrange the open toolbars for each different file type (or even close some of the toolbars if you don’t commonly use them), but the result is that when you toggle or tab between files, the tool area bounces up and down. And I don’t think that would be such a huge issue, but for the fact that I frequently like to close a number of different files by clicking on their tabs; only, when I do that, the location of the tabs changes due to bounce.
It’s probably fair to assume that Microsoft will eventually switch to using the Office Ribbon toolbar within Visual Studio at some point down the road. And while I love the Ribbon toolbar within Office, I’m not sure how well it would translate into use with Visual Studio. That said, if it creates a fixed-height toolbar area (which it will), then I’ll probably warm to it in a hurry. Either way, even without actively wanting Visual Studio to adopt the Ribbon toolbar, I’d really, really, really like Microsoft to make it easy to keep the toolbar area at a fixed-height.