bharry's WebLog

Team Explorer 2005 update for interoperating with TFS 2010 is now available!

bharry — Mon, 15 Mar 2010 14:34:00 GMT

This morning we delivered the final version of the patch to Team Explorer 2005 that enables it to work well with a TFS 2010 server. Of course, it will also still work well against a 2005 or 2008 server. You can download the update here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=22215e4c-af6f-4e2f-96df-20e94d762689

and, of course, the update for Team Explorer 2008 has been available for a while:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cf13ea45-d17b-4edc-8e6c-6c5b208ec54d

Good luck with it and let me know if I can help you,

Brian

Delays delivering mail alerts in TFS 2010

bharry — Fri, 12 Mar 2010 17:16:00 GMT

I've seen a few people complain about longer delays delivering mail alerts in TFS 2010. The reason is that, by default, we batch all notifications and process them every 2 minutes. This was done to accomplish higher scale on very high volume servers. In retrospect a 2 minute delay was not the best default. We will look at changing this for SP1. In the meantime, you can change the default yourself. You can set the delay to 0 if you want, in which case you'll get the same behavior you saw in TFS 2008. Chris Sidi wrote a post giving some details of how this works.

Also, we are working on a Power Tool that will provide a UI for browsing and modifying these kinds of settings.

Brian

TFS 2010 Installation and Upgrade success rates

bharry — Fri, 12 Mar 2010 14:42:43 GMT

As I’ve discussed in the past, we work VERY hard in this release to really improve the ease of installing TFS. We’ve done everything from making more components optional, reducing prereqs, configuring prereqs for you, providing better defaults, implementing better diagnostic checks, making configuration serviceable and more. It’s been a lot of work but I think it has really paid off in really transforming the TFS install experience from one that is very long and most people dread to one that’s pretty short, easy and problem free.

Part of our “secret” to doing all of this has been intensive instrumentation. We’ve used both Dr. Watson and SQM to collect tons of information from Betas, LCTPs and the RC to understand what people are doing and what problems they are having. We’ve also used blogs, forums, emails and support to follow up diligently on virtually every report of problems to try to get to the bottom of it and make some improvement that will reduce or eliminate the chance that someone else hits in the future.

I wanted to share with you some of the results. Here’s some data on RC installation and upgrade success rates (as reported by our telemetry). Some definitions:

Initial Success – Means the user succeeded the first time they tried.

Overall Success – Means the user failed one or more times but ultimately succeeded. The failures can come from something as simple as trying to install the 64-bit version of TFS on a 32-bit OS (which quite a few people have tried over the various releases :)) to more involved issues like permissions not being right or misconfigured prereqs, etc.

Failure – Means as best we can tell, the user was not able to get the installation working.

Now all of this is a bit fuzzy due to limitations imposed by privacy restrictions. We have to use indirect mechanisms to tell if two attempts are from the same “user”. We actually can’t collect information on who the user is. So it’s very possible that some number of the failures were actually Overall Successes but we weren’t able to tell that the ultimate success was the same user as the failure.

Here’s the success rates for fresh installs for the RC:

And here’s the success rates for upgrades for the RC:

Here’s the versions people were upgrading from:

We have been able to identify and improve several issues that lead to the failures on the RC. We are expecting that the RTM success rate will be even better. By contrast in TFS 2008, the success rates were 5-10% lower than this.

Here’s some other random and somewhat interesting statistics from our SQM data:

Operating System TFS 2010 is installed on:

This is the first release we’ve supported installing on a client OS and a client OS is the #1 install target and a total of almost 37% of installs are on client OSes.

32 vs 64 bit installs:

This is the first release we’ve supported 64-bit OSes and almost 2/3rds of installs are on them.

And here’s how much memory people have in their TFS machines:

Brian

Pre-ordering VS 2010 Professional Edition

bharry — Thu, 11 Mar 2010 12:18:00 GMT

Microsoft Visual Studio 2010 Professional will launch on April 12 but you can beat the rush and secure your copy today by pre-ordering at the affordable estimated retail price of $549, a saving of $250.

Along with all the great new features in Visual Studio 2010 (see www.microsoft.com/visualstudio) Visual Studio 2010 Professional includes a 12-month MSDN Essentials subscription which gives you access to core Microsoft platforms: Windows 7 Ultimate, Windows Server 2008 R2 Enterprise, and Microsoft SQL Server 2008 R2 Datacenter.

So visit http://www.microsoft.com/visualstudio/en-us/pre-order-visual-studio-2010 to check out all the new features and sign up for this great offer.

Brian

Programming Practices: Part 2 – Thoughts on TDD

bharry — Wed, 10 Mar 2010 15:19:19 GMT

Well, it seems the last post wasn’t too controversial. Let me try something that might be a bit more controversial. Heck, it might even get some people down right agitated with me but that’s OK, disagreement is a useful tool to drive clarity and understanding.

I don’t like Test Driven Development. I don’t just not like it, I think it’s a bad idea.

How’s that for an inflammatory statement? Probably gonna make the cool kids black ball me :)

I don’t spend a bunch of time debating the fine points of the various popular development techniques with people so I suspect someone is going to jump in and tell me I’ve missed the point of TDD – and maybe they are right. Let me refine my statement a bit and then launch into both what I like about TDD and what I don’t like. So here’s a little softer statement.

I don’t like a literal interpretation of TDD.

If I think about what the goals of TDD are (and I’m doing a bit of reverse engineering to get there), then here is what I like about TDD:

1) Focus first on how you are going to use a thing, not the thing – I watch many people early in their software development career (including myself) make the same mistake over and over. They have an application to build. They envision and architecture, decompose the components and then start building them. After a few years they start to realize that the contracts between the components are really important so they start to get very rigorous about encapsulation, abstraction and contracts but their overall approach is the same.

I can’t tell you how many times in my life I’ve done this and spent hours or days building enough components to get reasonably high up in the dependency stack and then go to build the next layer on top (it might be the UI or it might be a service interface or just a higher level abstraction) and realize, crap, it’s all wired wrong. The API isn’t really built the way I like, the components aren’t factored quite right, etc. The result is that i have to write more code at that next layer up than I should have to and the code doesn’t flow very well.

The way I now approach this problem is that I always start at the top level (or a very high level) layer in the system and work down. Specifically before I write any code for a class, API, layer, … I write one or more samples that use the API to to accomplish some purpose. This shows me what I want the flow to be an what the natural abstractions are for the typical use cases of the service that I’m building. After each sample, I go back and visit previous samples and refactor until I get all of the samples using a consistent API/abstraction, resulting in a minimal set of code and clear and easy to understand flow.

For example, when I created the framework I’ve built for managing asynchronous UI in Windows Forms, before I created a line of code, I took the WinForms designer and wrote 6 different dialogs. Each of them demonstrated some important characteristic or extensibility point I wanted to have. The first was to show the bare minimum code one would have to write to get a dialog that would load asynchronously, be cancelable and give the user appropriate feedback. The next showed that I could pass parameters to the background loading process, implement a refresh model, etc. Other samples demonstrated how to coordinate the work of multiple background threads, different ways of displaying progress, different ways of notifying the background thread that it has been canceled, etc. All the dialogs were fully written (and rewritten several times) before I wrote a line of code on the async framework. While I didn’t cover every part of the API, I had a very clear picture of the API/contract/abstractions that I wanted and could begin to conceptualize the design of the async framework. Of course, as I built the framework, I learned even more and went back a few times and refactored my samples but the samples always guided the work.

In a sense, you can think of these samples as test cases – in fact I often use them that way. Sounds a little like TDD, right? It kind of is. It’s also got some characteristics of Behavior Driven Development (BDD) but in a little bit I’ll tell why I see it as pretty different than a literal interpretation of TDD. My first vote of confidence in TDD though, is that I do believe it is a technique that can help you focus on how to use something first and later on what it does.

2) Don’t write code you don’t need (YAGNI) – YAGNI stands for You Ain’t Gonna Need It. Another very common mistake I’ve seen in my career (and, again, made myself many times) is to try to imagine the ultimate end of where a program will go and build an architecture/implementation that sets you up to get there. Good developers are always thinking about all the cool new features/requirements they’d like to add down the road and they’d like to make sure they build their code in a way that enables it.

The problem is that, no matter how hard you try, you can’t predict the future. You can sit here today and imagine what the requirements are going to be 6, 12, 24 months from now. You may believe you see very clearly where it should go but you don’t. Please take my word for that. It’s a very hard conversation to have with an eager developer who really wants to “build it right”. Don’t. Build what you need now and don’t build more. Down the path lies lots of unused code, unnecessary abstractions, complexity that no body understands the need for, etc.

The issue is requirements change. I promise. 6 months from now you will look back and wonder what you were thinking. Because you’ll have people actually using your app and they’ll be giving you tons of feedback on stuff they want and it won’t be the things you thought they’d want. I’ve lived it 100 times at least.

So does that mean that architecture doesn’t matter and you should just put on blinders and build exactly what you need this very moment. No, I’m not quite saying that. Design your code with clear abstractions and generality in mind. Design it in a way that is extensible and composable. Just don’t add requirements that you don’t currently have. If you build a system with a clean, well factored architecture: encapsulation, separation of responsibility, clear contracts, etc, your code will be in a good position to tackle new requirements as they come. But assume no matter what you do, you’re going to be doing some refactoring of that code when you get there. You might as well have less of it to refactor.

Back to TDD. I believe TDD helps you get here. It’s a very rigorous focus on only writing the code that you can concretely identify that you need. I like that.

A note on extensibility – I was discussing this post with a colleague yesterday and he asked me to make sure I made a point about extensibility. Nearly all developers like to make their code extensible. However, many developers believe that their own implementation is “special” and has requirements that can’t be met by the extensibility interfaces. Down that path is a bad extensibility model. If you can’t build your own implementation in the same extensibility framework that you are providing for others to use, I can almost guarantee you they won’t be able to use it either.

OK, so enough about what I like about TDD. Let’s get to the juicy stuff – what don’t I like:

1) I find it inefficient – If you read my last post then you know that I refactor like crazy. The idea of having unit tests that cover virtually every line of code that I’ve written that I have to refactor every time I refactor my code makes me shudder. Doing this way makes me take nearly twice as long as it would otherwise take and I don’t feel like I get sufficient benefits from it.

Don’t get me wrong, I’m a big fan of unit tests. I just prefer to write them after the code has stopped shaking a bit. In fact most of my early testing is “manual”. Either I write a small UI on top of my service that allows me to plug in values and try it or write some quick API tests that I throw away as soon as I have validated them. Once the code has started to settle, then I go back and write the unit tests that I’m going to use to help with regression testing down the road. I don’t mean by this, that I wait until the app is done to build the tests but rather I do it iteratively at a component or requirement boundary.

2) Backing into an architecture – This is probably by biggest issue with a literal TDD interpretation. TDD says you never write a line of code without a failing test to show you need it. I find it leads developers down a dangerous path. Without any help from a methodology, I have met way too many developers in my life that “back into a solution”. By this, I mean they write something, it mostly works and they discover a new requirement so they tack it on, and another and another and when they are done, they’ve got a monstrosity of special cases each designed to handle one specific scenario. There’s way more code than there should be and it’s way too complicated to understand.

I believe in finding general solutions to problems from which all the special cases naturally derive rather than building a solution of special cases. In my mind, to do this, you have to start by conceptualizing and coding the framework of the general algorithm. For me, that’s a relatively monolithic exercise. When I’ve got the basic framework in place (I may still have parts of it still stubbed out), then I start testing to make sure all of the special cases are handled by the algorithm the way I pictured (and of course, as I said in my last post, I do this by stepping through all of my test cases in the debugger to see exactly what it is doing).

I’m not saying that it isn’t possible to build a good architecture following TDD. I’m saying that lots of people are already inclined toward piecemeal architecture and I believe literal TDD enables these natural tendencies too much. I also find the constant moving back and forth between test case and code to be too distracting while I’m trying to hold the design in my head and get the core algorithm fleshed out.

Conclusion

I like many of the goals of TDD but I don’t like some of the mechanism to get there. I suppose we’ll see how many of you are avid TDD proponents and maybe we’ll have vigorous debate about the pros, cons and interpretations of TDD. I look forward to it.

Till next time…

Brian

Programming Practices: Part 1 – Watching from a distance

bharry — Tue, 09 Mar 2010 14:12:15 GMT

I figured I’d start the series with a more abstract post about what watching me code looks like. It was interesting to observe myself doing it because I didn’t really realize the degree to which I do some things. If I were to summarize my overall approach to coding with a simple description, I’d call it “Annealing” – from the Encarta dictionary: “metallurgy craft transitive and intransitive verb to subject an alloy, metal, or glass to a process of heating and slow cooling to make it tougher and less brittle.” Or in more of a software sense, “Simulated Annealing” – from Wikipedia: “a technique for searching for a solution in a space otherwise too large for "ordinary" search methods to yield results”.

What does that mean?

Let me try talking about it as a set of principles and techniques:

1) Working code every few hours – I find I can’t stand to have code that is in pieces all over the floor. I don’t ever like to be far from code that works. My coding is defined by a sequence of “stable” points that are no more than a few hours apart. A “stable point” is a state where all of the code compiles, it runs and it does something useful. It may not be anywhere near doing what the ultimate application is intended to do but it does some fraction of it. A quantum of work transitions from one stable point to the next.

I find that as I approach a problem, I think about how I am going to build the code in bite sized chunks. It’s kind of funny to watch but if I get a few hours into something and I’m not very close to a “stable point”, I actually get anxious. I start getting nervous and looking for ways to stub out or cauterize parts of the application so I can get back to something I can build and hit F5 on. I think part of this is related to why I got into programming in the first place – I’m a huge fan of the “instant gratification” that you get programming. I can think of no other profession where you can start with nothing and in a few short hours have built something really useful. But more practically, it’s an important way to make sure you don’t get lost in the weeds of a solution.

2) Prove the concept – When I’m getting ready to leave a stable point, I find the first thing I want to do is map my path to the next stable point. I choose some specific, containable goal – add a dialog, a menu item, move an operation to a background thread, add a control to a form, something. Before I enter the chaos between stable points I want to prove to myself that I know how to get to the next one. I often start, particularly if I’m working with API surface I’m unfamiliar with, by doing a rapid prototype of the core concepts that I need. I don’t care what the code looks like. I don’t modularize anything. I don’t worry about comments, variable names, code organization, error handling, performance, anything. I just want to touch each of the core APIs that I need to use and prove that I can get access to the information that I need and understand roughly what I need to do with it.

I usually get it all the way to running code and step through it in the debugger so that I can see all of the information flow and ensure that I understand all of the side effects, etc. To a first approximation, I then throw it all away. Sometimes, I’ll just comment out the routine(s) that I wrote and keep them around a while for reference and a source of code snippets. I step back and conceptualize an organization of the code that feels clean and I then start writing the code “for real”.

At some level this might feel like a waste of time but I believe it is a huge time saver for me. It usually doesn’t take me more than 15-20 minutes or so to explore the key concepts of the few hour leap from one stable point to the next and I often learn a ton in the process and make significant shifts in my approach as a result. It saves me from getting an hour or two into something and realizing that some assumption I made at the beginning was invalid and I need to redo everything I just did. I think it also helps ensure that I end up with better organized code when I’m done.

3) Refactor, Refactor, Refactor – I never really realized how much I just naturally do this. I’ll bet the net effect is that I write any given stable point to stable point quantum 2 or 3 times in the few hours I work on it. I start with a conceptual picture of the algorithm but I don’t try to plan out everything. I start writing the code organized in a way that feels the “cleanest” but as soon as I realize something’s not right, I refactor. I’m constantly splitting methods, reordering code, reorganizing data structures, building abstractions, etc. This is the main reason I started by talking about annealing – because that’s what the process feels like to me. I keep jiggling the code, gradually reducing the temperature until all of the crystals line up just right and I have a very clean, maintainable, reusable, fast, robust, … implementation.

I now realize that I used to do this even before “refactoring tools” were invented but I am finding some of the refactoring tools to be very useful in saving me some typing – though they have a long way to go to make me really happy. The VS ones, at least, don’t automatically do everything I want and don’t always have the flexibility for me to control it. Examples – Extract method often leaves me with a lot of clean up to do.

It doesn’t give me the ability to control parameter ordering (and as you’ll see from this series, I’m anal about everything). I am very particular about the ordering of parameters.
It doesn’t allow me to control the types of parameters to the method. Every method should have an abstraction or contract of what it operates on and what it does. I might want to type a parameter as a base class of the passed object. I might want to pass a one or more members of an object that is used rather than the whole object (because the type of the object is not part of the method’s contract).
It doesn’t allow me to extract to a different class.
It rarely puts the method where I want it in the class (more on this in future posts).
Lastly, I find that before I extract the method, I actually want to type the call to the extracted function. It’s part of making sure I understand the factoring of the code and what the contract is. I wish I could type the call site, then select the code I want to extract and say – extract it such that the call matches what I just typed. But instead, of course, it extracts it, adds another call site, which I immediately delete and then go fix up the parameter types and order, etc.

As I write the code, I comment lightly. Because I refactor so much, I don’t want to waste time writing and rewriting comments, method contract descriptions, etc. But once I’ve gotten the code just right, I polish it. I go back over all of it making sure I like the abstractions and the flow, I comment everything and I move all of the methods that I’ve written to their permanent resting place in the class – I’m very particular about the order of methods in a class (did I mention I’m anal about everything? :)).

4) Step through everything in the debugger – Before I start polishing a quantum of work, I walk through everything in the debugger. I conceive and write or manually execute test cases for every interesting scenario and I step through all of them in the debugger. It’s not sufficient that the code works. I’m a firm believer that you don’t actually understand your code if you don’t understand exactly how and why it works and the only way to do that is to step through it in the debugger and see what it is actually doing.

You’d be stunned to realize how often the results of code match what you expect but the execution path is nothing like what you expect. This is one of my greatest secrets to getting high quality, high performance code that I never have to come back and revisit again. When it’s done, it’s done done :)

5) Paper and pencil – The last thing that I’ll mention that’s perhaps a bit odd and I think you’d notice if you sat and watched me code is that I always have a pencil and paper in front of me. As I’m coding, I’m constantly drawing pictures of data structures, writing out sample data, hand walking through the algorithm on paper to see how things work. I suspect it’s just a quirk of mine but there’s no better way for me to think through the algorithms as I go. When I’m done with a quantum of work, I always have a sheet of paper full of scribbles. I generally extract some of the value and then just throw the paper away. Some of the scribbles become part of the documentation – pictures, algorithm descriptions, etc. Some become the source of test cases that I keep to serve as regression tests in the event that I ever need to come back to the code.

Summary

At a very high level, that’s what watching me code looks like. Some of what I’ve written here, I think of as quirks of my personality – heavy use of pencil and paper, for example. But most of it I consider important practices to produce high quality code efficiently. I can imagine a lot of people looking at this and saying, “wow, that sounds expensive” and if you are banging out a one off project with a short lifetime, it’s really not worth it. But if you are writing code that is part of a significant application, is going to live for years and potentially have other people needing to understand it, I believe these practices are invaluable.

I’m not sure I’ve captured everything. Perhaps in the discussions that follow and subsequent posts I’ll think of a few more “high level” things. We’ll see.

Brian

Series on Programming Practices

bharry — Mon, 08 Mar 2010 15:24:44 GMT

This is the first post in a series I’ve decided to write on my Programming Practices. I’m not trying to say everyone has to do it the way I do it but I figured it might be interesting to talk about how I do it and have some fun, if sometimes controversial, discussions about it.

A little before Christmas, when I decided that I really wanted to understand the Beta 2 performance issues first hand, I picked up a programming project that I’d been kicking around and started to get serious about it. My job doesn’t really afford me the opportunity to spend a lot of time writing code any more but I’ve gone out of my way to really set aside some time to do it. Over the past few months, I’ve probably averaged 10-20 hours a week of dedicated coding time.

As I was coding I decided to watch myself closely and try to observe what practices I naturally follow with the goal of eventually sharing them more broadly. I’ve generally always been very proud of the productivity, organization, performance and quality of my coding. Once you see it, you can decide for yourself whether you like it, dislike it or just think it’s stupid :) I’m sure the practices don’t apply to everyone or every application type. I have always done commercial software and much of it at a fairly low level “systems” level. I’m not sure how much of what I’m going to describe will apply to someone who is primarily a jscript/html coder. You can judge for yourself.

The project I picked up is a new version of TFSServerManager. It’s particularly interesting because it has many components. It has a client GUI, written in WinForms (I’ve played with WPF but I can’t say I’m proficient at it enough to feel particularly competent – once I finish this project, I think I’m going to try a full WPF/Silverlight app). It also has a web service that runs on the TFS server and augments TFS with a few capabilities that aren’t available “out of the box” – doing some SQL access. There’s some ASPX pages for lightweight user interaction for a few things (more on that later). And lastly there’s a command line installation utility. A fairly diverse technology set in all.

I also took this project as an opportunity to explore asynchronous rich client programming a bit more. It pains me that the TFS client makes so many web service calls on the UI thread causing the IDE to “pause” if the server is ever slow to respond. It ended up this way because we didn’t lay out a great pattern for all of the developers to follow up front and stuff just kind of unfolded the way it did because it’s easier to put all the logic on the UI thread than it is to partition it. So as part of this project I set out to have every single server call occur on a background thread and create an architecture that would make it easy to do. My goal is to make it no harder to program this way than putting all the logic on the UI thread. That goal is a bit harder to achieve with WinForms because it does not lend itself to good presentation/computation separation (e.g. MVC – Model View Controller or one of the variants). When I start my WFP project, I’m going to adjust the pattern for MVC and I think it will get even better. Anyway, through the course of this series, I’ll share with you the architecture I created.

I won’t be surprised if it takes me weeks, or even months, to get through the whole series. I’ve got a lot of thoughts and I think it’s going to be a pretty big investment for me to make them all intelligible :)

I hope you find it useful,

Brian

VS 2010 RC Patch available for the # 1 Connect bug

bharry — Sat, 06 Mar 2010 13:21:00 GMT

The most commonly reported/voted for Connect bugs in the Release candidate had to do with the ASP.NET designer not auto generating controls properly - it would sometimes just omit them. Very frustrating if you are trying to use it. We've just release a patch (the 3rd RC patch in total) to address this set of issues. You can read more about the patch here: http://blogs.msdn.com/webdevtools/archive/2010/03/05/hotfix-for-issue-with-auto-generated-designer-files-not-adding-controls.aspx

And you can download and install it here: http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=27117

Hopefully this will address this issue and get you moving forward again.

Thanks,

Brian

Next Generation Testing with Visual Studio 2010 – Additional Events

bharry — Fri, 05 Mar 2010 17:53:11 GMT

A few days ago I posted a schedule of upcoming events in the Midwest focusing on Visual Studio 2010. That list represented only a small subset of the events planned for VS2010. There have been events all over North America and I suspect around the world. As these events are managed by the individual regions in which they are located I do not have one comprehensive list available--I'm posting them as people in the field organizing the events send them to me. I presented at events in Boston, Wash DC, Reston VA, Durham NC and Chicago IL, but I've only been involved in a fraction of the full event schedule. There is also a ton of online content which you can check out channel9.msdn.com

Here are details I have just received on events planned in Switzerland for those of you in that locale:

· Microsoft is sponsor at the Swiss Testing Day on March 17, 2010 in Zurich/Switzerland (www.swisstestingday.ch); and Bj Rollins from Microsoft Corp will give one of the keynotes (by the way: the other one is given by James Whittaker who moved from Microsoft to Google…)

· At the Swiss TechDays on April 6 – 7, 2010 in Basle/Switzerland, Brian Keller will have two sessions on Testing (www.techdays.ch; day 2). This is THE event to attend in Switzerland to learn more about Visual Studio 2010 and .NET FW 4.0!

Second Intellisense patch for the 2010 RC

bharry — Fri, 05 Mar 2010 15:46:00 GMT

We had a number of reports about Intellisense crashes soon after the RC was released. After much investigation, the vast majority of reports have boiled down to two issues. We released a patch for the more common of the two a week or so ago. We've just released a patch for the second and customers who have tried the two patches are reporting that all of their Intellisense crashes are gone.

Try them out and let us know if you are still seeing any IDE instability.

Brian

Optimizing Visual Studio 2010 and WPF applications for Remote Desktop

bharry — Fri, 05 Mar 2010 15:39:00 GMT

As part of our work to improve VS performance after VS 2010 beta 2, we've done a ton of analysis of VS in various scenarios. One of them is VS over remote desk top. We've made a number of fixes to improve the performance but there are also some things you can do to configure remote desktop in ways that are significantly less bandwidth intensive and will make your experience better. Jossef wrote a blog post about this recently that you might want to check out if you use RDP a lot: http://blogs.msdn.com/jgoldb/archive/2010/02/27/optimizing-visual-studio-2010-and-wpf-applications-for-remote-desktop.aspx

Brian

VS 2005 support for TFS 2010 coming soon

bharry — Fri, 05 Mar 2010 14:19:00 GMT

I know many of you have been waiting patiently for our update to Team Explorer 2005 that will enable it to interact with TFS 2010. In the past I've said it would be available by the 2010 launch. I just wanted to give you a status update and let you know that we are still hard at work on it and are almost done. We are just doing final QA validation and will be releasing it shortly. Right now it looks like it should be available by March 19th. As with all dates, don't take that as a hard and fast commitment but rather a target we are shooting for and believe we can make. Stay tuned and I'll let you know when the download is available.

Brian

MSDN Forum for TFS + Eclipse and other platforms

bharry — Fri, 05 Mar 2010 13:24:00 GMT

As of today, we now have a new MSDN forum dedicated to discussion of heterogeneous development using Visual Studio ALM products. If you've got questions or want to learn more please check it out. Our good friend Martin Woodward will be your host and make sure you get answers to your questions.

Brian

Microsoft Visual Studio Team Explorer 2010 codename “Eaglestone”

bharry — Thu, 04 Mar 2010 18:06:30 GMT

This morning, we are announcing the beta release of Microsoft Visual Studio Team Explorer 2010 codename “Eaglestone”, the Eclipse plugin and cross-platform command line assets that were acquired from Teamprise back in November. You can download the bits here, and participate in the associated Microsoft Connect community here. I want to use this post to provide some detail on what we’ve released here and a little information on where we’re taking the new heterogeneous client for TFS.

The beta release contains what we consider to be the essential features necessary to claim that we’re a client for TFS 2010. We’ve been trying to strike a balance between including 2010 features, and getting the product to market, so you won’t see everything here yet. But it’s coming… with time… more below.

So, what’s in this release? Well, in addition to the work needed to make it a Microsoft product (modifying assembly/namespace names, updating branding and artwork, running through some compliance tools to ensure the product meets Microsoft standards), you’ll primarily find the following:

1. We’ve reacted to all of the architectural changes in TFS 2010, which primarily shows up in our support for Team Project Collections but it also means that the Eclipse plug-in supports all the configurations for project portal and reporting services that are possible (including not having any configured at all)

2. We’ve added the enhanced work item linking and hierarchy capabilities. You can now define typed links, query for work items based on links, and work with work item hierarchies.

3. We’ve added support for the new WF-based team build. We don’t have full team build support, but the basic scenarios of defining a build, launching a build, and monitoring your builds work well.

4. We’ve reacted to a lot of underlying changes in the source control version model with respect to how branching, merging, and renames happen. History now follows branches and merges. Branches are proper first class citizens in the source control explorer.

The team build features are a little special here because the download site doesn’t include everything you’ll need to use them. You may recall that Teamprise shipped a set of msbuild extensions under the Teamprise Labs brand that allowed Team Build to invoke Java build tools like Ant and Maven. Our analog for Teamprise Labs is our power tools, and we’re currently working on incorporating those extensions into the next TFS 2010 power tool release. In the meantime, our fantastic community has stepped up and you can already find a TFS 2010 compatible version of the old Teamprise Build Extensions from MVP Steve St. Jean’s blog. The Microsoft release will include both MSBuild tasks as well as workflow activities for the TFS 2010 version of the build extensions.

So, what isn’t in this release? Well, the 2 biggest missing 2010 features are gated checkin and branch visualization. You can do gated checkin with this release, but the experience isn’t as nice as what you get in Visual Studio 2010. In particular, you don’t get proactively notified of your checkin completing with an opportunity to quickly reconcile changes in your workspace with changes that just got committed to the server. Instead, your committed changes will remain pending in your workspace, and you’ll encounter conflicts the next time you do a get latest or attempt a subsequent checkin. The changes are then reconciled as you deal with these conflicts. On branch visualization, we don’t have anything yet. We love the feature and are excited about bringing it to Eclipse, but it’s going to take some time.

If you look hard enough, you’ll also find that we cut a few corners to save time as we were implementing these features. We hope you won’t notice, though, so I’m not going to tell you where they are.

This is a heterogeneous client, so it probably makes sense to discuss what environments it supports. The download site spells this out in great detail, but essentially it works on Windows, Mac, Linux, Solaris, AIX, and HP-UX. The Eclipse plugin supports Eclipse versions back to 3.0 as well as several IDEs built on Eclipse such as Rational Application Developer, Adobe Flex Builder, and Aptana Studio.

As with the Visual Studio 2010 release, this client supports TFS 2010 and TFS 2008. We also made the decision to support TFS 2005 since the Teamprise company will be removing their 3.x client from the market when we RTM. We didn’t want TFS 2005 customers to be without a solution for Java development. That said, we’ll likely drop support for TFS 2005 in the next release as customers will still be able to get this release if necessary, and it already contains full TFS 2005 feature support.

This is an English-only release. That is another corner we cut to get this to market quickly. Teamprise had never localized their product in the past, and there’s going to be a decent amount of work necessary to get it there. We plan to do this for the next release, and localize it into the same set of languages that VS is localized into.

Those of you who are familiar with the Teamprise product line are likely asking what happened to the Teamprise Explorer. If you aren’t already familiar, Teamprise offered a stand-alone client for TFS called “Explorer” that was popular for non-Windows users who weren’t building Java apps, and weren’t friendly with the command line. The Explorer is an asset that we acquired, but there are issues with how it is built that require us to do some deeper thinking before we can ship it. In particular, because the Explorer client redistributes components of Eclipse, we have to deal with security, servicing, and intellectual property concerns that we don’t have to worry about with the Eclipse plugin. We are committed to shipping this client, but we didn’t want to hold up the plugin and command line while we figured out these issues.

We are aggressively moving towards an RTM by the launch of Visual Studio 2010 next month. We will also announce final details on the product branding and pricing at that time. After that, we’ll turn the crank again to add missing features, languages, etc. and hopefully release again in the fall. Eventually, we plan to sync the release of these tools with the release of Visual Studio and ensure that we’ve got appropriate feature parity with the latest version of the server when it releases. We are also going to keep up to speed with the new releases in the Eclipse community and ensure that we are compatible with the latest release there.

I’m very keen to hear what you think of our first plug-in for Eclipse so please give it a try and let us know. For existing Teamprise customers who wish to try out this beta release we would recommend that you use a separate Eclipse instance, Eclipse workspace and TFS workspace. That way you can run the different versions side-by-side without any problems. For more information on installing the plug-in, see the download site.

Next Generation Testing with Visual Studio 2010

bharry — Mon, 01 Mar 2010 14:55:43 GMT

Join us for a sneak peek at some of the new capabilities in Microsoft® Visual Studio® 2010, a landmark release of the premier development and testing toolset for Windows®, Web, and cloud development.

Microsoft has made significant investments to improve the testing/QA tools in Visual Studio 2010. The Next Generation Testing Event is your exclusive opportunity to experience the incredible power and capabilities these new tools bring to the QA and testing process. At this event, you'll get a comprehensive overview, as well as a deep dive, into the range of new tools and how they can enable you to improve the way you develop and test software on the Microsoft platform.

This will be an invaluable opportunity to learn how to take software development to the next level with the new testing features in Visual Studio 2010.

EVENT AGENDA:

Registration, Welcome, Refreshments - 30 min.
The QA Challenge - 30 min.
Taking Testing to a New Level - 3 hours
Making It Real - 30 min.
Prize Drawing - 15 min.
Please feel free to forward to a co-worker you think would
benefit from attending this event.

AUDIENCE:

Software testers
QA professionals
Developers

PRIZES AND GIVEAWAYS:

Attendees will have a chance to win a new Zune HD!

Register for a date and location near you! Follow the appropriate registration link below OR call (877) 673-8368 and reference the event ID.

Date	Location	Time	Event ID & Registration Link
3/2/2010	Memphis	5:30-8:30pm Central Time	1032441935
3/2/2010	Dallas	12:00-5:00pm Central Time	1032441937
3/3/2010	Nashville	5:30-8:30pm Central Time	1032441936
3/3/2010	Houston	12:00-5:00pm Central Time	1032441938
3/4/2010	Cincinnati	5:30-8:30pm Eastern Time	1032441934
3/12/2010	Bloomington	12:00-5:00pm Central Time	1032442187
3/12/2010	Southfield	12:00-5:00pm Eastern Time	1032441932
3/15/2010	Milwaukee	12:00-5:00pm Central Time	1032441929
3/15/2010	St. Louis	12:00-5:00pm Central Time	1032441930
3/15/2010	Columbus	5:30-8:30pm Eastern Time	1032442186
3/16/2010	Kansas City	12:00-5:00pm Central Time	1032441931
3/16/2010	Cleveland	12:00-5:00pm Eastern Time	1032441933
3/18/2010	Indianapolis	12:00-5:00pm Eastern Time	1032441928
4/13/2010	Chicago	12:00-5:00pm Central Time	1032442250