I love the fact that I can create private and shared queries. Apparently, so does everyone else. I've seen the number of shared queries grow and grow over the past few weeks. Granted, I think this is in part because people get a new toy and they want to see what it does, so they go hog-wild with it; but at the same time, the shared queries are very useful. Most of the time, tho, they're only useful for certain groups. For instance, I don't care about the 5 different reports the QA team wants to run. So, why should I have to look at them all when I am in the shared queries folder? I shouldn't. The way I get around this is by creating shortcuts to the queries I use; but that doesn't resolve the clutter issue. There needs to be a way to add some organization here. Having the ability to add folders would resolve that immediately. I'm not sure whether a better solution exists, but I'd be open to anything.

Edit: This has already been reported three times (1 , 2 , 3 ). Looks like it will be included in a future release, probably the next release.

Here's a simple one that should be resolved now that the DSL Tools are available. As a matter of fact, I believe there's a sample of it in the SDK. Either way, I want a use case designer in Visual Studio. This would really be a great move towards a true model-driven architecture (MDA) environment.

Visual Studio's regular expression (regex) search isn't quite standard, as I've mentioned before. Fortunately, you can do most of what you need despite this. One thing missing, however, is the optional character/word identifier (question mark in "standard" regex). For instance, colou?r should return color and colour. The only work-around I know of is to use the 0-to-many occurrences identifier (asterisk). This means you'd search for colou*r, which would give you color and colour; however, it would also give you colouuuuuuuuuuuuuuur. As you can see, this would be a problem.

Luckily, in most scenarios, the lack of the optional identifier won't affect you too much. This is assuming you're searching compilation-ready code, that is. Let's use a VB search as an example. Searching for :i\.ToString(\(\))* should return something.ToString() and something.ToString().

Like I said, this scenario works just fine because, if your code is compilable, you should never have something.ToString()(). There are, however, circumstances where the 0-to-many identifier won't suffice. Of course, these are harder to come up with since they're more rare, but I'll do my best... Let's consider a search for declared strings and one-dimension string arrays, string(\[\])*:Wh+:i, which is intended to find string abc and string[] xyz. As you might imagine, there is a likelihood that you may also get string[][] abc, which is the problem in this case. Granted, I realize this may not be an ideal example, but the problem usually only comes into play when you have long, complicated search strings. The work-around for this case is to use the or operator: (string|string\[\]):Wh+:i. This will return either string abc or string[] xyz, but nothing else. As you can see, this makes the search string longer. Now, imagine if you're doing an even more complicated search for string-checking (i.e. someString.Equals(""), someString.Equals(anotherString), !someString.Equals(""), someString == "", someString != "", someString == null, someString != null, someString == null || someString.Length == 0, or someString != null && someString.Length > 0... just to name a few). The possibilities are seemingly endless. Of course, this is going to be a ridiculously long search string, anyway, but the optional identifier would make this so much easier.

FYI: :i is a VS-only shortcut that represents a C++ identifier ([a-zA-Z_$][a-zA-Z0-9_$]*)

FYI: :Wh is a VS-only shortcut that represents a white space character ([ \t\n\r] -- there might be a few others, too)

If you haven't caught my drift, yet, to sum it all up, I'd like to have an optional identifier. Hopefully, the question mark.

Code analysis is a wonderful thing and so is refactoring. With so many code analysis fixes that are simple refactoring techniques, why not create a simplistic way to refactor code for code analysis tweaks!? Honestly, I'm not surprised it's not in the existing release and I do expect that it will be in there in the future, but I haven't heard of anything like that, so we'll see.

One example is the code analysis performance warning regarding unnecessary casting (CA1800). This comes up a lot when you check to see if a generic object is of a more specific type and then cast it after that check. Instead, the practice is to use the as keyword, which will default to null, if the types aren't compatible. Consider this before and after block as what the refactoring could do...

Before

if (someObject is CustomObject)
    ((CustomObject)someObject).DoSomething();

After

CustomObject custom = someObject as CustomObject;
if (custom != null)
    custom.DoSomething();

Not only is the code easier to read, it's better performing. Then again, I'm not arguing for or against the code analysis. I simply want this simple task automated.

One of the great features of Visual Studio 2005 is the ability to dynamically add namespace declarations to your using/imports block at the top of the document while you're hacking away at code. As anal as I am about my code, I just wish the namespaces would be grouped and ordered in some fashion. All the feature does is toss the namespace to the end of the list; however, what I'd like to see is the ability to configure a rule for how to group and order the names. I think the best way to explain myself is with an example. So, let's say I'm using 6 namespaces: 3 .NET BCL namespaces, 2 third-party namespaces, and 1 namespace from my app. I want them all alphabetized and grouped as such, like so...

using System;
using System.Text;
using System.Web;

using Indigo.Business;
using Indigo.Web;

using Flanakin.Business;

This is helpful for when you're looking thru the file, you can see the namespaces at a very quick glance. Granted, you don't really need to look at them much, but if they have to be there, it only makes sense to put them in some sort of logical order.

The diff utility available on the Check-In dialog in Visual Studio Team Edition (Compare option on the context menu) is very basic. I'd love to see this support editing of the file(s). Well, files that can be edited. I'm not sure if this diff utility can be applied to 2 files not in a version control repository, but if so, both should be editable. If not, obviously, only the local version would be.

For those questioning the usefulness of 2 local file comparisons, you obviously haven't been working in the configuration management (CM) world for very long. This can be crucial; especially, if you're managing the repository.