(Here’s the link to Part 2)

I’ve just spent 4 days in Seattle at my first Global MVP Summit – it’s been great meeting a lot of the other ALM MVPs and putting faces to email addresses! It’s also been great getting an “inside scope” on some of the strategic directions that the TFS and VS product teams are taking.

Visual Studio 2010 has some amazing features for Sharepoint development, like project templates, server explorers, feature and package GUIs to name a few. So you’re tasked with creating a WebPart or a Workflow – no problem, fire up VS, create a new project and you’re coding.
However, just because you’re up and coding quickly, doesn’t mean you’re being productive (necessarily). What about requirements management? Testing? Source control? And if there’s more than 1 of you coding, what Sharepoint site do you code against? Oh wait, I forgot to mention that you need to install Sharepoint on the same machine that you have VS on to actually get the Sharepoint projects to work.

Recently we changed our internal domain. It was a little bit of a pain, since I had to migrate my setting and preferences. One “snag” I hit was reconnecting to TFS once I had changed my primary login from the old domain to the new domain.

Responding to TFS events can be done in (at least) 2 ways: create a SOAP webservice and register with bissubscribe (this works in a “client” fashion) or implement the ISubscriber interface (in the Microsoft.TeamFoundation.Framework.Server namespace).

As a follow on from my post yesterday about some of the intricacies of using Coded UI testing on WPF applications, I wanted to give some details about using the WpfCell class to automate validation and updates into DataGrids.

Sometimes you’ll write an WPF application that has some sort of “dynamic” way of loading portions of the UI (think: Prism). Sometimes entire frameworks are too much, so you’d prefer something a bit simpler – like, say, a TabControl with a data template. Bind the ItemsSource of your TabControl to an ObservableCollection (where T is some model) and you’ve got a “dynamic” interface.

Using the TFS API to display results of a flat query is fairly straightforward – once you have the WIQL you just execute the RunQuery() method and voila – a nice WorkItemCollection for you to enumerate over. However, if you try to execute RunQuery() on a tree or one-hop WIQL, you’ll see this error message:

This week I got an email congratulating me on becoming an MVP for Application Lifecycle Management. This is a huge honour! Thanks to all involved in this – including the community!

It’s a little over 3 weeks until Tech Ed Africa 2011 starts (it runs from 17 to 20 October). I’ll be presenting a two topics on the Development Track