Oh la la! Combining Pex test with Team Foundation Server is indeed a powerful combination, and boy is it easy as hell to setup. The end state of this type of integration is pretty straightforward, we wanted to repeatedly provision Pex tests when executing build events in TFS.
This is a pretty awesome setup because parameterized units tests can be explicitly created, then the Pex tests can provide all the good stuff on build for the test running. Furthermore, we can even have full coverage by allowing Pex to create some of the tests that we space.
The changes required are minimal since in the build events it simply requires wiring some commands. Assuming that the tests are *already* created, you can use the MSBuild Project AssemblyName property or declaratively provide the assembly wiring the following command into your build event:
This is all fine and good, but what is you want complete coverage to ensure your tests exist? Luckily, Pex provides the /erm:wizard switch to generate the parameterized unit tests, and we can call our explicit tests using the /sa switch. This looks like the following:
pex.exe /erm:wizard test.dll /sa:test.tests.dll
Viola! Getting so easy it’s going to be hard justifying not having Unit Tests!
I think I have actually seen this error in other versions of TFS besides 2010, but most recently saw it in 2010 deployment. Post-executing build configuration when running a build for something using Web Application projects you might receive the error:
The imported project “C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets” was not found
To solve this issue, just copy the C:\Program Files\MSBuild\Microsoft\Visual Studio\v10.0\WebApplications directory from a development machine to the build machine. Sucks but it works. Seems sporadic why it happens.
I was at a client today, working on a TFS 2008 cube corruption problem (I hate the super common code churn crap it always throws, requiring weird InstanceInfo and SetupWarehouse voodoo) when the subject of automating BizTalk 2009 projects came up.
The company heavily uses BizTalk, so they threw up a staging server with BizTalk 2009 on it and ran the Team Foundation Server Build Setup. After this, building non-BizTalk projects was working just fine, but BizTalk projects fail to build. After examining the box, they had copied various things from a BizTalk development workstation, but none of the additions had any effect. The rationale behind this was they don’t want Visual Studio on the staging server, but without it when running the BizTalk install the Developer Tools and SDK option is not selectable.
To get around this, look during the installation of BizTalk under Additional Software, and find the Project Build Component feature. While this allows for builds without Visual Studio, it should be noted that you can’t generate MSI packages, just build stuff.