Most developers don't run tests after they change code. This is mostly about habit, but also about perceived inconvenience, I imagine. There's an easy way to get around that... make VS smart enough to have tests automatically run in the background when the code they're testing is changed (and obviously recompiled). To do this, there might need to be a way to specify what class members are tested in each test method, but that'd be good anyway. I find myself putting that in all test method comments, anyway. Whether that's added via a code comment or attribute, I don't care; although, the latter makes a little more sense.
As I mentioned yesterday, I like the idea of check-in policies, but they are pretty annoying for those of us who like to check-in as much as possible. Why? Because you always have to rerun code analysis and tests before checking code in. Most of the time, this isn't a big deal. If I make a minor change like correct spelling in comments, I have to rerun both. Tell me what test is going to change based on a comment. None. Admittedly, some code analysis rules check for that, but is that really going to provide you much of anything? I just want check-in policies to have some sort of logic to identify whether or not there's any value in running them.
I love check-in policies, but there needs to be more options. For instance, I like code analysis and would like to have it on all of my projects, but it just gets annoying when I have to run code analysis on test projects, which don't really benefit from the recommended changes. In order to do this, we need an exception rules engine of some sort.
I hate when I open certain C# classes and Visual Studio shows me a designer to tells me to drag items from the toolbox to get started. I'm not a drag-n-drop guy. I want the code. This makes sense for VB, but not C#, in my mind. I simply want the ability to default to the code view.
I love the new profiling capabilities in Visual Studio, but there's still a gap when doing end-to-end performance testing and tuning. I'd really like to see the app get instrumented from beginning to end. While local devs won't see how constrained networks might affect their app, I think the perf tools can be smart enough to take the local tests and apply a few algorithms to show what kind of range of response times users should see, depending on their bandwidth and/or distance from the server. I know a lot of this might be a guessing game, but it'd be nice to at least have some numbers to see how big pages are and what user-focused response times are. At a minimum, I'd like to see the size of pages and the time spent requesting, processing, responding, and loading the page in the browser. Anything else would be icing on the cake. There was an entire office setup to do this when I was in the Air Force. Having it all built into the dev environment would save an immense amount of time and money; especially considering most devs aren't fully aware of all the factors that come into play and how they can tune their apps.
That kind of brings up another possible area of this end-to-end instrumentation. I'd like to tack on a
best proven practice analyzer to the output that would make recommendations. Of course, not all recommendations are universal, but at least providing some pros/cons to each would give devs more info than they have right now.
This one's fairly simple. I would love to see the ability to select a literal string and convert it to a string. Heck, while I'm at it, it might be nice to convert a literal to localized text. Either would be good; both would be great.
One thing I am continually annoyed with when working with the Visual Studio test framework is that, when a test fails, I have to look at the error to figure out what line of code in my test method caused the problem, then separately find that class, browse to the line, and figure out what's going on. This isn't how we do our development, so why is it how we do our unit test development? I know this was a v1 release -- although I hate that excuse -- but I hope we'll see some significant improvements in Orcas.
Edit: Looks like this was reported on VS 2005 beta 2 and ultimately closed with a claim that it was added to the RTM release. Obviously, it wasn't, so I added another suggestion . We'll see what they say.
Edit: According to the folks at Microsoft Connect, this will be in VS08. I look forward to it!
I can't stand the fact that a file's history only goes back as far as the last branch. When a file is branched, the history should include everything. I'm not sure why this wasn't the default action. As far as I know, this is how all (or at least most) other version control tools work.
One thing I find fairly aggravating is when I want to see files that have changed locally when I'm working with a TFS repository. Sure, I can see what's been checked out, but that doesn't mean those files have all been changed. Currently, all you can do is compare them one-by-one, which is a ridiculous process. Admittedly, my main reason for doing this is because I'm anal. I don't want files to be marked for check-in if they don't have any changes; specifically, I don't want them included in the check-in changeset. Based on this, I'd like to see TFS check-ins to ignore files that haven't changed or at least provide an option to do so.
Reported @ https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=260449
Edit: Some brilliant, small-minded person closed the suggestion and said we should simply not check-in files that haven't changed. The problem with this is that means we have to manually go thru every file that's been marked as changed. Consider a large check-in that includes hundreds of files. Checking all those files would take way too long and nobody would do it. I'm somewhat aggravated about this. I'll probably end up reporting it again.
Edit: Looks like this might be in the Team Foundation Power Tool v1.2. The tfpt uu command says it is supposed to "undo unchanged files." The question is, what does this really mean? You can specify a changeset, which tells me it allows you to remove unchanged files from a previously checked-in changeset. If that's the case, I'm very excited about it. I just hope it undoes currently checked out files when a changeset is not specified. Once I play with it, I'll report back, but this really needs to get included into the product instead of being a command-line action that must be performed.
I love the fact that Visual Studio 2005 comes with a class designer. Unfortunately, as with most v1 products and features, it's quite lacking. One feature it needs is the ability to display show what interfaces a class implements and vice-versa. From any class, you can see its base class or derived classes. From any interface, you can see its base interface or interfaces. Why can't you see a classes implemented interfaces or an interface's derived classes? This just doesn't make sense to me and I hope it gets added into the next release. I haven't played with it, yet, but this is a seemingly small feature that should be included, one might think.
Team Foundation Server needs to have the ability to ignore files, like CVS (.cvsignore file) and Subversion (svn:ignore directory tag). The concept is simple. When checking in files, unnecessary files should be ignored. Visual Studio does a pretty good job at ignoring some files (i.e. bin and obj directories and .suo and .user files). There are times, however, that this isn't enough. For these cases, you need an ignore capability.
I love Visual Studio's profiling/instrumentation capabilities; however, I wish there were settings or class/member attributes that could be used that would allow you to either exclusively ignore or inclusively instrument certain methods. The main difference between the two would be that an exclusive run would gather timing for everything by default while an inclusive run would only gather timing for the items you specify.
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.
I really want the ability to revert files from the check-in screen in Visual Studio. I use this a lot more than deleting files
. Basically, Visual Studio needs to mimic TortoiseSVN
Visual Studio needs to allow users to delete files from the check-in screen. The capability is pretty simple, but very useful.