No Free Time

I’ve spent the last couple of days trying to get IronRuby running Cucumber on my Win7 machine. I’ve hit a wall with it and I’m appealing to anyone who can help me.

I followed this tutorial: http://blog.webintellix.com/2009/10/how-to-use-cucumber-with-net-and-c.html

And when I reached step 5 and executed ‘icucumber features’ (in my case I called the batch file icuc.bat for brevity) I get this result:

Fail. Incidentally I’m using Ruby 1.9.1 and IronRuby 1.0 RC 1 which at the time of writing are the latest versions. I updated the paths given in the tutorial to match the appropriate paths on my machine.

Because I’m waaaaay interested in logging, tracing, diagnostics, analytics – basically, what’s going on with my shit – I spent some time today tweaking our log4net configuration here at work. The actual motivation for sitting down and doing this was that I wasn’t getting any notification from uncaught exceptions in our sites, and I saw a couple in the event log on our live box. Naturally I flew into a blind rage and immediately set up an SmtpAppender for the existing log4net config for that site. After an hour or so I have a configuration that I like, so here it is.

I added two things:

• Split configuration files so we can drop a new log4net configuration into a site without worrying too much about the main web.config
• SmtpAppender for any log messages at WARN level or above

Here’s the template web.config file with the log4net configSource attribute:

The debug log4net config file:

And the release log4net config file:

I’ll be suggesting that this configuration is adopted as standard for all new builds and I’ll go and reconfigure a few of our other active sites too.

No dice. Can’t be done. Here’s why.

To track an action you need to invoke the trackPage() function defined in ga.js. The function must be invoked from the same domain registered in your Google Analytics account, in my case that’s “andrewmyhre.com”. So in order to track events from my Silverlight app I need to call up to the parent frame and invoke a function to track the event. Unfortunately, because my Silverlight application is running on an entirely different domain (something like “silverlight.services.live.com”) the browser throws a “Permission denied” error when I try to invoke parent.trackPage().

There is no way around this. That behaviour is by design, in order to prevent cross-site scripting attacks.

So I’ve moved the Silverlight and media files to my hosting account where I can load everything under my own domain. That’s cool because I have 1gb of space there and the total media payload is around 500mb. It’s also a real shame, it was cool to be using a new beta service like Silverlight Streaming, but unfortunately event tracking is a deal breaker for me.

Maybe there are some coders out there who know how to get around this, or maybe the Silverlight Streaming team have a workaround… I can’t really see it happening though. Shame.

On the bright side though, the videos seem to be streaming much more quickly now! :/

I wrote a post earlier this year about how difficult it was to get VS 2005 Web Deployment Projects and Team Build 2005 to play nicely together. Well in the 2008 versions it looks like they put some effort into removing a lot of the friction, so I want to explain how it works now and shout out that it’s much, much better than it used to be.

For the purposes of this example I created a simple website project, a web deployment project, and a basic build definition. There is a lot of information about how to create a team build definition in TFS 2008 so I’ll just gloss over that. The important points here are: a) the inputs (a website and a web deployment project) and b) the outputs.

The Build

1. The sample solution

2. Creating a build definition

3. Select the solution to build

4. Select the platform and configuration (Mixed Platforms and Release)

5. Finish

6. Create a build agent and enter the drop/staging location for the build

Next I ran a build, and here’s what came out:

The result of the build

Notice that within the _PublishedWebsites folder are two folders: ‘Website’ and ‘Website_deploy’. In this example they are identical; if I had set up custom web config replacements then in the ‘Website_deploy’ folder would be a customised web.config file.

If I hadn’t created a web deployment project, the Team Build would still create the ‘Website’ folder and deploy a compiled website. This is important because I believe that didn’t happen with Team Build 2005, it just dumped the compiled assemblies into the Release folder. (Please correct me if I’m wrong).

Deploying where you want

The next thing you (probably) want is to have the deployable website copied from the timestamped drop location to a static location for an IIS website. Here’s how to modify your build script to do this:

1. In the solution explorer, right-click on the build definition and select View Configuration Folder.

Select View Configuration Folder to see where the script is stored in source control

2. The files will not be downloaded to your machine yet – highlight them, right-click and select Get Latest Version. Now double-click the TFSBuild.proj file to open the build script.

Open the build script file

3. Now paste the following into the script, just before the closing </Project> tag:

What this will do is copy each of the deployment folders in the _PublishedWebsites folder directly into the drop location you specified in step 6 of creating the build definition (above). You don’t need to add anything specific to do with the project (other than the Mixed PlatformsRelease path, but this won’t change between build projects). If you set up deployment projects for staging and production you will end up with 3 deployed websites (development, staging and production). Nice!

Obviously for the build to include the script changes you just made you need to check the file back in to source control.

Hope this clears things up.

I’m working on a website with a large design aspect, so we have a lot of .psd files (about 200mb) kicking about the place. We want them source controlled, so they live in the TFS 2008 team project folder in source control. But then our Team Build includes them when downloading the source files, so that quickly fills up our build server’s drive and makes a single build take up to 11 minutes, which is far too long for a basic eCommerce website.

So I trimmed these files from our build process. Here’s what I did:

1. Copy the .psd files and any other files that aren’t required for a build into a seperate folder in the root of the team project. (All our website/source files are in another folder called ‘Current’, as in the ‘current version’, as opposed to ‘Phase 1′, ‘Phase 2′)
   
2. In Team Explorer, right click the build you want to edit and selected Edit Build Definition…
3. In the Workspace tab, enter the path within source control where you want to start downloading files from. In our case I chose the $/[project]/Current folder, so the /PSDs folder will be ignored and not downloaded.
   

Now, thanks to the above steps my build history folders are 1/10th the size they were to begin with, and the build process takes less than half the time!

I created a Silverlight-enabled WCF service which worked perfectly when running my Silverlight app from Visual Studio, but as soon as I deployed to IIS 7 on my machine and opened it outside of VS I received the following error:

Unhandled Error in Silverlight 2 Application Exception has been thrown by the target of an invocation. at System.RuntimeMethodHandle._InvokeMethodFast
…… (there was more

I couldn’t be sure whether this was a Silverlight or a WCF issue so I opened the SVC url in my browser and received a (405) Method Not Allowed response. I checked IIS and discovered there was no HTTP Handler set up for WCF services.

I then managed to find this very helpful post about setting up WCF HTTP Handlers in IIS 7, and the solution described worked perfectly for me. Here are the steps:

1. Open a command prompt as administrator
2. CD to c:WindowsMicrosoft.NETFrameworkv3.0Windows Communication Foundation
3. Type ServiceModelReg -i and press return
4. A whole load of lines like “Installing: HTTP Handlers” will print out to the console. When it’s finished go into IIS 7 and open the HTTP Handlers list for your website. You should see a couple of new ones for the *.svc extension

Also, another issue I came across while trying to track down how to set these up was where people were deploying their WCF/Silverlight project to IIS 7 without updating their web.config to change the server binding reference. When you add a service reference to your Silverlight project the url is stored in the ServiceReferences.ClientConfig file, but if the WCF project is defined in the same solution then the URL will point to the local Cassini server, which means the service call will fail when you deploy the app to IIS.

One solution to the issue is to override the service URL in code, so that you don’t have to keep updating the .config file when you deploy to a web server.

TFS 2005/2008 both ship with the TfsDeleteProject.exe utility.

Open a command line on your team foundation server and cd to

%program files%Microsoft Visual Studio 9.0Common7IDE (2008)
%program files%Microsoft Visual Studio 8Common7IDE (2005)

Then:

tfsdeleteproject /q /force /server:<tfs server> "<project name>"

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:

NOTE: This post applies to TFS 2005 and WDP 2005 only. For TFS 2008 and WDP 2008 the below does not apply. It’s much, much easier to work with Web Deployment Projects in Team Build in 2008 – you can read about it in my updated post.

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)_PublishedWebsitesWebApplication1</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!

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>\engelbartwwwrootprojectstequiladigital playgroundbuildteststaged</DeployLocation>

    <!-- don't worry about this -->
    <WebBinariesLocation>$(SolutionRoot)..BinariesMixed PlatformsRelease_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…..