Last week I was helping a customer get up and running with Lab Management. In an effort to make sure they’re up to date, I installed TFS and VS 2010 SP1 on their TFS machine as well as in all the Lab machines.

Notion Solutions is part of Imaginet, and last week Microsoft announced that Imaginet had won the Microsoft Partner of the Year in the inaugural Application Lifecycle Management category.

I was at a customer recently who have a small test database – around 120MB in size. I had encouraged them to use the DB Professional tools in VS 2010 to track their schema – that way they could deploy the database (as well as the latest schema) and some test data (through INSERT statements or even better, data generation plans). However, their developers didn’t have the time or skills (yet) to do this.

So you’ve got your virtual environment running and you’re deploying your application using the Lab Default Workflow. Only, you have a config file and you need to update a connection string or something in the config file for automated tests to run properly.

If you’re running Lab Management with lab machines with XP SP3, you may run into a problem where the Test Agent is never ready for running tests.

I am preparing for the demo at DevDays, and we wanted to run a Load Test using our Lab environment. However, when trying to access the performance counters on the lab machines, I got “Access Denied” errors. That lead to some searching on why this is the case.

I am going to be co-presenting with Ahmed Salijee (a Development Solution Specialist) from Microsoft South Africa at DevDays later this month. We’re going to be showing off a ton of TFS and VS 2010 capabilities around testing applications. Here’s the official blurb for our sessions:

I was working on a TeamBuild that doesn’t compile code – this build checks out a number of MS Word documents from source control, converts them to PDF and then uses PDFSharp to merge them all into one PDF document. I started with the DefaultTemplate.xaml and ripped out the compile / test tasks. I then created a Powershell script that would do the heavy lifting. So all the build does is check out the doc files in the workspace, invoke the powershell script and then copy the final file to the drop folder. Seems pretty simple, right?

I have been setting up a TFS for demos and web training. Since TFS installation is now really easy, I got it up quickly and configured Lab Management. Everything was plain sailing until I tried to deploy a stored environment. The SCVMM job failed and provided this rather unhelpful message (where host.com is my host server):

I’m often asked by customers why there is no way to prevent check-in policy overrides in TFS. Usually I respond along the lines of, “Well, it should be a really rare occurrence (otherwise why have the policy?) and besides, every action against TFS is tracked, so you can monitor overrides and beat ‘chat nicely’ to the developer who is overriding the policies”. Which is all well and fine, but exactly how do you monitor policy overrides?