Where to manage the build location in TFS 2008

Until now I’d been confused between the agent working directory, the build service accounts’s temp folder, and the workspace created by Team Build. Do I have to manage all three settings? Do they have to be different? Today I discovered there’s just one location I need to manage for each build agent.

In my efforts to clean up and standardise where projects are being downloaded and built on our build server I discovered that the workspaces automatically created by Team Build don’t actually determine where the build happens. This is because every time TFS performs a build it deletes and recreates a workspace for that build. The source directory path it uses comes from the Build Agent definition:

C# Debug/Release and Performance

I’ve been listening to this webcast today:

GDC 2008: Understanding XNA Framework Performance

I learned an interesting little fact:

“Debug vs Release setting in the IDE when you compile your code in Visual Studio makes almost no difference to performance… the generated code is almost the same. The C# compiler doesn’t really do any optimisation. The C# compiler just spits out IL… and at the runtime it’s the JITer that does all the optimisation. The JITer does have a Debug/Release mode and that makes a huge difference to performance. But that doesn’t key off whether you run the Debug or Release configuration of your project, that keys off whether a debugger is attached.”

Incidentally RoeCode’s XNA game engine series is now at part 18 and is looking pretty nice. I’ve totally slacked off of looking at XNA but I’m totally going to start playing with this again now.

More on WAPs and WDPs

Here’s a very interesting post: http://undocnet.blogspot.com/2007/12/web-application-project-2008-still-not.html

Currently I’m having trouble with MVC projects. I’ve given up trying to use a WDP so I’ll have to write my own /rip off a web.config replacement task.

Right now I’m getting a weird error though:

(CoreTestConfiguration target) ->
TESTTOOLSTASK : warning VSP2013: Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.
TESTTOOLSTASK : warning VSP2013: Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.
MSBUILD : warning MSB6006: “MSTest.exe” exited with code 1.

Bizarre! Interestingly this error happens when I run the team build project using msbuild on my development desktop.

Making Team Build and Web Deployment Projects play nice: Part 2

Right, so yesterday I figured out how to make ASP.Net 2.0/3.5 Website projects work in a Team Build environment using Web Deployment Projects. Today I figured out how to get Web Application Projects to work.

The problem is explained in this thread - take a look at maharik’s post and BradleyB’s reply. maharik was having the same problem I was having, where the Web Deployment project was trying to build the wrong path. At this stage I still don’t fully understand what’s going on (why does the web deployment project need to be pointed to the compiled website?) but I know that it works.

So as background, I’m talking about a .Net 2.0 solution containing a Web Application Project, a Web Deployment Project and zero or more class libraries. The solution is part of a Team Project and I want to set up a Team Build to build the solution.

The Team Build must be set up using the Mixed Platforms as the platform (contrary to what the article I linked to yesterday said - but that article is still correct as far as Website projects are concerned). Choose a configuration (Release/Debug) and make sure your Web Deployment project is configured to build under the same configuration.

Try running the Team Build now. Everything but the WDP should build fine, and you should get errors like this:

error ASPPARSE: Could not load type 'masterpages_default'.

Now you need to follow the directions posted by BradleyB. Find the <SourceWebPhysicalPath>…</SourceWebPhysicalPath> element in your Web Deployment Project file. Comment it out and replace it with:

<SourceWebPhysicalPath Condition=”‘$(OutDir)’ != ‘$(OutputPath)’”>$(OutDir)_PublishedWebsites\WebApplication1</SourceWebPhysicalPath>
<SourceWebPhysicalPath Condition=”‘$(OutDir)’ == ‘$(OutputPath)’”>..\WebApplication1</SourceWebPhysicalPath>

Where ‘WebApplication1′ is the name of your website. Now check in the WDP file.

Now when you run the Team Build again you should find that everything runs successfully, and in your release folder there’ll be a deployment folder with the same name as your Web Deployment Project. Great! Now you can follow the last step from yesterday’s post to add the AfterCompile step to copy the website to your deployment folder.

Nice!

DDD Scotland

This evening I head to Glasgow for Developer Day Scotland. Looking forward to it! Wondering if there’s a Twitter feed for it…

Make Team Build and Web Deployment Projects play nice

Update: Part 2, Web Application Projects.

The thing I like about Web Deployment Projects is the easy configuration of things like compilation (I like to compile to a single assembly), configuration section replacement (so, so much easier than setting this up in NAnt) and deployment. I also really like Team Builds, because they’re so easy to set up (compared to NAnt and CruiseControl.Net). But they don’t have the customisation features of Web Development Projects that I mentioned above. Plus the deployment option in a Team Build is absolutely useless to me, because it deploys the web project to a different folder every time. So I need a way to combine the two configuration features plus make sure the website is deployed to a specific folder on our development web server.

Initially I thought this would be really easy, in fact I expected that the Visual Studio team had specifically designed Team Build and WDPs to compliment each other. Ummmmm not exactly, it seems. I had loads of trouble getting the two to work together, with loads of builds failing due to stupid problems… usually due to the WDP losing its context and building the wrong stuff.

The best guide I found on the subject is this one. It explains that ASP.Net Websites and Web Application Projects are treated differently by Team Build (not why, just that they are) and that you need to use specific, different platform configurations.

To get my ASP.Net Website project (I haven’t tried Web Application Projects yet) working I created a WDP for it. I specified that it should build under the Release configuration, then checked in my solution. I then created a Team Build which targeted the Release|Mixed Platforms configuration. At that point I ran the team build and happily everything came up green, including the WDP.

To my dismay though, although the Web Deployment Project ran, it wouldn’t copy the build to the folder I specified in the WDP configuration. It just wouldn’t do it, and I have a feeling it’s something like the Team Build overriding the drop folder property that the WDP picks up.

The bottom line is that you need to manually override a build task to perform the copy yourself. This isn’t that difficult, and I’m happy to say it’s a step that I can expect other the other developers I work with to perform without needing to know too much about what’s going on.

So the final step was to modify the Team Build project file slightly. First I added the following property group, just below the closing </ProjectExtensions> element:

<PropertyGroup>
    <!-- change this to the name of the Web Deployment Project -->
    <BuildFileName>Engelbart2</BuildFileName>
    <!-- change this to location where you want the website deployed to -->
    <DeployLocation>\\engelbart\wwwroot\projects\tequila\digital playground\buildtest\staged</DeployLocation>

    <!-- don't worry about this -->
    <WebBinariesLocation>$(SolutionRoot)\..\Binaries\Mixed Platforms\Release\_PublishedWebSites\$(BuildFileName)</WebBinariesLocation>
  </PropertyGroup>

Then I added the following below the last </ItemGroup> element (I don’t think it actually matters where you put this):

<!-- deploy the compiled site to where we want it to go -->
  <Target Name="AfterCompile">
    <MakeDir Directories="$(DeployLocation)" />
    <!--<Exec Command="xcopy /y /e '$(WebBinariesLocation)' '$(DeployLocation)'"/>-->
    <ItemGroup>
      <ProjectSourceFiles Include="$(WebBinariesLocation)\**\*.*"/>
    </ItemGroup>
    <Copy
        SourceFiles="@(ProjectSourceFiles)"
        DestinationFiles="@(ProjectSourceFiles->'$(DeployLocation)\%(RecursiveDir)%(Filename)%(Extension)')">
      <Output
          TaskParameter="CopiedFiles"
          ItemName="SuccessfullyCopiedFiles"/>
    </Copy>
  </Target>

This works because your web deployment project is build as part of the team build into it’s own special folder. So for instance I could have team builds called ‘Development’, ‘Staging’ and ‘Production’, each with special web.config settings which the WDP would handle for me. The output from Team Build will be three websites, each in a distinct folder with the correct configuration. It wouldn’t be difficult to modify the above script to copy three seperate releases.

Hope this clears up some mysteries…..

Can’t we just weigh their brains?

I’ve been asked to assemble a list of desired skills for junior and senior developers respectively, in order for the company I work for to update their job specs. Anyone who has any particular insights into this area I would really appreciate your comments!

This is too scary

Man trapped in elevator for 41 hours:
http://disembedded.wordpress.com/2008/04/14/madness-trapped-in-elevator-car-30/

And if you can’t be bothered reading the story, here’s a time-lapse film of the whole ordeal:

http://www.snotr.com/video/1078

Developer day Scotland

Looking forward to Developer Day Scotland! Going to catch up with a few people I used to work with up there, before I fled to London with my tail between my legs.

Weird

I mis-typed and browsed to http://www.silverlight.com/showcase today. That domain is hosted by Apple?