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?

Sometimes you need to do a “deployment” that doesn’t involve a build of source code – for example, I have been working at a customer in gorgeous Durban and they’ve got some Dynamix AX scripts that they need to source control – no problem for TFS. The “deployment” involves simply copying the entire source folder to a secure share.

This week, Darshan Desai published a post about a build-deploy-test workflow for Physical environments. The solution is entirely XAML based – you don’t need any custom assemblies. However, the design-time experience is not as rich as the wizard that you get when you do a Lab workflow for build-deploy-test using the LabDefault.xaml template.

The Database Professional tools in VS 2010 allow you to create a project that encapsulates the schema of a SQL database. You can also use this project to create unit tests for stored procs or functions – and create test data for these database unit tests.

You’ve seen the indexing and symbol publishing options when you set up a Team Build – but have you ever tried to debug and application that has symbols? How do you get VS to use the published symbols? What are these settings for anyway?
Source indexing and published symbols make possible to debug an application without shipping symbols. Source indexing produces pdb files during a build – essentially mapping the binary to the source code. During a team build, extra information is wrapped inside the pdbs – like the Team Foundation Server URL where they were built and version control paths to and versions of source code. This allows VS to download source code for debugging – and since there’s security involved (to access the TFS server) – source server support is disabled for debugging by default.
Fortunately enabling it is quite easy – especially if you read your Kindle copy of Inside the MS Build Engine (2nd edition) on the plane!
Open VS and go to Tools->Options->Debugging->General settings and tick the “Enable source server support”.

TeamBuild in TFS 2010 is an incredibly powerful engine – it’s based on Windows Workflow 4 (WF4). Once you get over the initial learning curve of WF4, you can get your team builds to do some impressive stuff.

Data-driven unit tests are a great way to run lots of tests. You define a test harness (or method) and tie it to a spreadsheet in an Excel file to “drive” the test – each row in the spreadsheet is one iteration of the test case. I am not going to go into any more detail here – there are plenty of examples about how to set these up. Another advantage of using Excel for data-driven tests is that testers love Excel. They can open and edit the spreadsheet and add / edit / remove test cases at will.