Experiences using Team Build to build WebService and Setup (.vdproj) projects

  • [アーティクル]

I've been in the UK this week visiting several of our partners who are already using Team System for live projects. It's been an enlightening experience, and I'll probably be blogging more about things I've learnt/seen in the near future.

Yesterday I was working with a customer who has been trying to get Team Build working to create daily builds for their solution, and we hit a couple of problems along the way that I thought might be worth sharing

Issue 1: Done executing task "SGen" -- FAILED

The first problem we found was pretty tough to diagnose and we had to rely on the help of the Team Build developers in India to work us through the issues. First step was to get better error logs to help us diagnose the issues - simply seeing "Done executing task "SGen" -- FAILED." in the build log wasn't much help

To get better logging, we went to the build machine itself, opened up a command prompt and ran MSBuild from the command line against the project that had been copied onto the box. The best tip we had was to run msbuild with the " /v:diag " switch to generate diagnostic output. This helped us see the full output from the SGEN tool, which in this case told us that we had two different webservice proxy being generated which exposed two types of the same XML type name - evidently this is an issue in Beta 2 because it didn't repro for our devs on internal post Beta 2 bits. We fixed this issue by using a different the WebService namespace attribute for one of the Types.

We then hit another similar SGEN issue with another class exposed in both proxies - but this time we couldn't persuade SGEN to work around it by simply using a different namespace - it seemed to be permantly confused. Our workaround was ultimately to create an inelegant wrapper class around one of the classes to give it a different name. A hack, but at least it has unblocked the team.

Issue 2: Setup project wasn't built by Team Build

We had a moment of elation when we thought we'd cracked it, but it was short lived when we discovered that the setup project wasn't being built. We tried to debug into this and ended up with a very misleading error:

Could not find a part of the path 'c:\bldloc\tfproj\bldtype \BuildConfiguration\setupproj\setupproj.vdproj

I've replaced the actual project names, paths etc. but the interesting point was that the path didn't make any sense - there were no folders underneath the BuildConfiguration value. It turns out that this is a bug in the error message, and when we used verbose logging again with the /v:diag switch we got the following error

warning MSB4078: The project file "setupprojectname\setupprojectname.vdproj" is not supported by MSBuild and cannot be built.

Unfortunately, this is a big deal and something I hadn't realized: MSBUILD does not support building .vdproj projects in VS 2005. Clearly this is a big deal for Team Build, because we depend on MSBUILD, so we were stuck

Fortunately, there is hope. Team Build supports custom tasks, and vdproj setup projects can be build from the command line using "devenv /build". The Team Build team are putting together a blog article/whitepaper to explain precisely how to do this, but for the time being all I can provide you here with is the summary:

Team Build or MsBuild cannot build deployment projects as of now. You need to invoke Visual Studio to do the same. What that means is that you would have to install Visual Studio on the build machine.

Add a Team Build custom task to compile your solution. A sample call would be : E:\aagrawal\code\winhello>"C:\Program Files\Microsoft Visual Studio 8\Common7\Ide\devenv" MyApp.sln /build "Debug|Win32" /project Setup\Setup.vdproj /projectconfig "Debug", please see the above sections on how to write the task. One can use the $(SolutionRoot) property of TeamBuild.proj to figure out the path to the solution.

There are some instructions on how to create a Team Build custom task on MSDN. In this case, we'd implement the custom task Execute() method to call Process.Start() with the command line above. My partner customer hasn't yet done this step, but fingers crossed they'll now be able to start generating regular daily builds for their QA team to pick up

Comments

  • Anonymous
    June 10, 2005
    I'd rather use WIX through a custom task on the build manchine than install VS just for building setup packages.
  • Anonymous
    June 12, 2005
    Good suggestion, Shawn, thanks.

    Plenty of users have investments in VS setup projects already and possibly wouldn't want to be forced to switch to WIX, but for others WIX is definitely an alternative approach that could work nicely.

    Has anyone already written any custom Team Build Tasks to launch WIX?

    (I don't think installing devenv on the build machine is a major deal, but it would be nice to avoid it if possible.)
  • Anonymous
    June 12, 2005
    Visual Studio 2005 Team Foundation Server Beta 2 Known Issues
  • Anonymous
    July 04, 2005

    Abhinaba Basu on marking required fields in work items ⊕ and build types ⊕
    Adam Singer on the latest...
  • Anonymous
    August 18, 2008
    PingBack from http://devio.wordpress.com/2008/08/18/building-visual-studio-solutions-from-batch-file/