How little do you have to do to run a VS/TFS2008 build on a TFS2010 server?
As do many people I have a good number of TFS2008 style builds for legacy applications. I will, in the end, move these over to VS2010 and hence upgrade their build formats to the new 2010 workflow based one, but for now it would be nice to be able to run them with the minimum of effort. To this end I have done some work to see the minimum I can get away with to allow these builds to run, the aim being to leave the build box as close to a virgin TFS2010 one as possible.
**Basic Setup
**My basic build system was
- Windows Server 2008 32bit with SP2
- TFS 2010 build
**A VS2010 Test
**Just to make sure all was OK, I created a basic VS2010 MVC2 project with it’s default tests. I then create a default build for this. This failed as my build machine did not have the targets to build a web application. I copied the directory
C:Program FilesMSBuildMicrosoftVisualStudiov10.0WebApplications
up from a development PC to the build box and tried again. The build still failed as it was missing MVC2 assemblies, I downloaded the AspNetMVC2_VS2008.exe installer to get these assemblies on my build box. Once this was all done the build worked and the tests passed
**A VS2008 Test
**So I knew I had a 2010 build system that could build and test a 2010 solution. I next took an existing VS2008 solution’s build, this build had been upgraded as part of the TFS2008->2010 server upgrade. The build failed completely. This was not surprising as as well as being for a different version of VS I knew that was missing a number of custom build tasks.
First I had to install all the custom tasks, for me this was
- Version 4 of the MSBuild extension Pack
- StyleCop 4 remembering to install the MSBuild extensions. Also remember you need to copy the MSBuild.ExtensionPack.StyleCop.dll assembly from the extension directory to the StyleCop one else you get an error.
- Typemock 2010
- My own extensions that stores StyleCop data in the build summary. Note this did not initially work as it needed to be rebuilt against the TFS 2010 API, just upgrading the solution to VS2010 seemed to be enough.
Once all these imports were present the build tried to compile, and failed with the error.
C:Program FilesMSBuildMicrosoftVisualStudiov10.0WebApplicationsMicrosoft.WebApplication.targets(133,11): error MSB4064: The "Retries" parameter is not supported by the "Copy" task. Verify the parameter exists on the task, and it is a settable public instance property.
C:Program FilesMSBuildMicrosoftVisualStudiov10.0WebApplicationsMicrosoft.WebApplication.targets(131,5): error MSB4063: The "Copy" task could not be initialized with its input parameters. [c:buildsMoorcroft WebsiteDebt Collection
I spent a lot of time fiddling here, if I replaced my
C:Program FilesMSBuildMicrosoftVisualStudiov10.0WebApplicationsMicrosoft.WebApplication.targets
with one form my PCs V9.0 directory all was OK, but then I found this post that sugested to just removed the offending parameters in the targets file, they are just retry and timouts! Once I did this the build attempted to compile the solution (and I checked it still worked for my VS2010 MVC2 solution).
I now got another set of missing assemblies errors. This was due to the lack of MVC1 on the build box, this was downloaded and installed
So now my MVC1 web site built, but the associated test project failed. This was because the V9 of Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll could not be found, the build box had V10. To address this I changed the assembly reference in the test project from the GAC to a copy of the assembly I included under source control, so it could be pulled to the build server.
Everything now built. However the tests did not run. There was an error that MStest could not be found. I edited the tfsbuild.proj to add the path to the MSTest file
PropertyGroup>
<!-- TEST ARGUMENTS
If the RunTest property is set to true, then particular tests within a
metadata file or test container may be specified here. This is
equivalent to the /test switch on mstest.exe.
_
-->
_
If I looked at the build log I could see that MSTest now ran, and I could see all my 100+ test, but they all failed and were not published to the TFS server. I copied the .TRX results file local from the build box and opened it in VS2010. I could then see that all the test failed because the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll could not be seen. I am not sure it is great solution but I just dropped a copy into the same directory as MSTest.exe C:Program FilesMicrosoft Visual Studio 10.0Common7IDE. The other option I could think of would be to put it in the GAC.
Once this was done most of the test executed and passed Ok, but some still did not. Again checking the .TRX file, as it still did not publish the results, was due to problems with TestContext. It seems the V9 assembly passes TestContext parameters in a different way to the V10 one. The test that passed did not have any TestContext declared. So as I did not need TestContext for these tests I just commented them out.
All my test now ran, past, and the results were publish. The problem was if a test failed the results were not published, but this seems to be a know issue so nothing I can do about that now.
So I now have build that mostly work, probably well enough for now. I have not need to install VS2008 or VS2010 on the build box which is nice. Just have to see how well the build holds up in production.