Automating Office Tasks in a TeamBuild

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?

Monitoring Check-in Policy Overrides

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?

Using Indexed Published Symbols from TeamBuilds

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”.

Running Data-Driven Unit Tests with SpreadSheets on Sharepoint

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.


© 2021. All rights reserved.