When checking in a file in VS against TFS, if you click on the Work Items section, select a work item, and change the Check-in Action dropdown by selecting it and pressing “a”, which signifies “Associate,” when you click off of the dropdown, the value is reverted back to the default, “Resolve.”

Reported @ https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=260453

Edit: I'm not sure who responded to this, but they obviously have a problem with English -- the first sentence didn't even make sense. They seemed to think the problem only happens on one work item as an odd occurrence. They suggested I discuss this in the forums. The problem with that is that I've been able to reproduce this on all work items using multiple TFS instances.

Windows does a mediocre job of saving passwords. Sure, passwords are saved, but there always seem to be problems when the password changes. This is only one problem, tho. What I'd really like to see is the ability to group resources together to use one set of credentials. Enterprises have been providing single sign-on capabilities for quite a while. Those who haven't, are trying to move to this type of simplicity. With that, you typically have one credential store (i.e. Active Directory (AD)) and all enterprise resources use those credentials. What I'd like to see is, when you're asked for your credentials, you should have the option to use an existing set. I'm not sure if I'm explaining this very well, so let me give you an example...

I work for Contoso. I login to my corporate laptop using my contoso\flanakin credentials provided by AD. That's great. When I'm mobile, I may log into Outlook Web Access (OWA), which uses the same credentials. Alternatively, I may open Outlook, which, of course, uses the same credentials. Now, say I need to VPN into the network from a personal computer. Nowadays, I'll use a smart card to VPN in; however, once I get in, I'll have to re-authenticate with every individual resource. A few examples might be the SharePoint sites I use for the project I'm working on, internal collaboration sites, and my internal weblog. Honestly, I could give a hundred different types of internal resources, but you get the idea.

Currently, Windows needs 3 things to save your credentials: username, password, and the resource you're accessing. I want to change this in two fundamental ways. First, let me name the credential set. This way, I can specify contoso\flanakin as my Contoso Corporate Account. This may not be a huge deal, but it'd be nice to have a simple name. Second, allow me to add a group of resources to the access list for this credential set. This is obviously the key to what I'm really looking for. The value of this lies in the simple fact that, when I have to manage my credentials, I can change one and all of them will be able to acknowledge and use that change. This would be invaluable to me and anyone who uses a lot of access-controlled resources.

In Windows Vista, when you connect to a network, you can give it a name and icon and, more importantly, specify whether it's a public, unprotected or private connection. I'd have to say this leaves some significant middle-ground. I'd like to see a third option: protected. Granted, I'm pulling this state from my development experience, but I honestly think it's necessary. I will say that I should probably investigate the differences between public and private networks in more detail, but the bottom line is that, on public networks, your computer is locked down a bit more. This means your network access is limited and, I believe, will essentially make you "invisible" to some network resources. Obviousy, any network admins will be able to see you're connected, but their access to your machine will still be locked down pretty tightly -- one of the many things I love about Vista. The private network is almost a no-holds-barred options. Ok, not really that open, since all other security features in Vista are active, but your computer (and all programs currently running) aren't limited to network access, unless otherwise set in some other setting. This also means everyone on the network can see you.

I'd like an option that keeps the computer "invisible" and locks down incoming network access without restricting outgoing communications. Part of the reason I'd like an option in this middle ground is because, as a consultant, I may connect my laptop to a customer's network, but I still want to stay away from anything flying around. I don't want the network to even try to assume control or push content to me. I admit that this doesn't happen often... that I'm aware of; but I like the idea of feeling secure with such an option. Again, I haven't done any research into the differences in public and private networks or the customization of either, so this may not even be a valid request.

This isn't new, but I had to mention it. Since the inception of C#, I have wanted an equivalent to the VB with block. I believe I've heard that it won't be done, but that's not going to stop me from hoping. The idea is simple and it shouldn't affect the IL code that's generated from C#. This is merely a tool in which a developer could speed up development a bit.

Client client = new Client();
with (client)
{
    .FirstName = "Michael";
    .LastName = "Flanakin";
    .Coolness = CoolFactor.ToTheMax;
}

...should compile to...

Client client = new Client();
client.FirstName = "Michael";
client.LastName = "Flanakin";
client.Coolness = CoolFactor.ToTheMax;

I can see maintainability issues with a feature like this, but there are potential maintainability issues with the misuse or overuse of any tool.

Windows Vista's Start Menu Properties dialog has a handful of items that have three options. Most of them have options like show link, show menu, or don't show the item at all. I'm thinking that these could be represented as a tri-state menu, where show link is the partial check, show menu is the full check, and don't show is unchecked. I will say that this isn't a big deal, but merely a thought. The current approach may be better because most users probably couldn't figure out my suggestion. The existing solution is a bit more explicit. Nonetheless, I figured it'd be worth mentioning to get the gears churnin'.

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.

This may not be a big deal, but I can see how it might be useful every once in a while. It's a good practice to catch specific exceptions so you're not randomly missing some crucial bug in your application. Sometimes you want to catch a small exception, but let others bubble up. As-is, you'd have to create multiple catch blocks to catch each individual exception or add code to check to see if an exception is of a certain type to decide whether or not to rethrow it. Doing a bunch of casting checks will be a performance problem -- granted, maybe not a huge one, but moreso than separate catch blocks, I believe (I haven't tested that theory).

Let me give you an example. Let's say you have a string value you need to convert to an integer and then use that as an array index. If the value can't be parsed, the conversion could throw three exceptions: ArgumentException, OverflowException, or FormatException. However, if you're directly feeding this into an array, you may end up with a good integer, but a bad index, which would result in an IndexOutOfBoundsException exception. With this, you may want the out of bounds exception bubbled, but handle the case of a bad number. Simply catching an Exception will obviously catch all situations. Instead, I'd like to see something like this: catch(ArgumentException, OverflowException, FormatException). Obviously, if you want to do something with the exceptions, you'd have to specify variable names for them, but you get the idea.

Again, this may not be a big deal, but I like the practice of catching all exceptions and dealing with them where they occur. I also admit that this may be a bad example -- anyone wanting to cover all bases would check the index, too. I'm simply noting one small example, tho. I'm sure I could come up with several others where developers make typical assumptions without catching the exceptions. Probably the most typical one is the NullReferenceException. Yeah, I caught you on that one, didn't I?

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.

Here's a different resolution  to a problem I've mentioned before: unsolicited email. The typical scenario is that an email goes out to a large group of people and then everyone starts making comments, sometimes completely off the subject. Either way, you may not even care about them. Working in large organizations, the problem can me multiplied because you end up getting on distribution lists that you don't care about at all, but are purely there for political reasons. No matter why you received the email, you don't want to participate in the useless email conversation that seems to be never-ending. If only we could unsubscribe to an email conversation. Basically, it'd be like specifying a conversation as junk email, except there'd have to be some limitations to ensure a separate conversation wouldn't get accidentally marked as junk.

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.