But it works on my PC!

There is a call for speaker for DDD in Dublin on the 9^th of October, that is not that far away is it!

[Updated 1 Sep 2010] The link would help http://developerdeveloperdeveloper.com/dddie10/

Test Professional, after the Lab Management update, now uses Expression Encoder 4.0 to create it video of screen activity. This means that when you run a test and record a video you end up with an attachment called ScreenCapture.xesc.

Now my PC did not have the Expression Encoder 4.0 installed, so did not know what to do with an .xesc file created within our Lab Management environment. To address this the answer is simple. On any PC that might want to view the video either:

1. Install the Expression Encoder 4 
2. or install just the Screen Capture Code

Once either of these is done, Media Player can play the .xesc file.

Interesting user too stupid error today whist adding some CodeUI tests to a Lab Management deployment scenario.

I added the Test Case and associated it with Coded UI test in Visual Studio

I made sure my deployment build had the tests selected

I then ran my Lab Deployment build, but got the error

Build directory of the test run is not specified or does not exist.

This normally means the test VM cannot see the share containing the build. I checked the agent login on the test VM could view the drop location, that was OK, but when I looked for the assembly containing my coded UI tests was just not there.

Then I remembered……..

The Lab build can take loads of snapshots and do a sub-build of the actual product. This all very good for production scenarios, but when you are learning about Lab Management or debugging scripts it can be really slow. To speed up the process I had told my Deploy build to not take snapshots and the use the last compile/build drop it could find. I had just forgotten to rebuild my application on the build server after I had added the coded UI tests. So I rebuild that and tried again, but I got the same problem.

It turns out that though I was missing the assembly the error was before it was required. The true real error was not who the various agents were running as, but the account the test controller was running as. The key was to check the test run log. This can be accessed from the Test Run results (I seemed to have a blind spot looking for these result)

This showed problem, I had selected the default ‘Network Service’ account for the test controller and had not granted it rights to the drop location.

I changed the account to my tfs210lab account as used by the agents and all was OK.

I have been using the ExternalTestRunner 2010 Build activity I wrote. I realised that at least one of the parameters I need to set, the ProjectCollection used to publish the test results, was hard coded in my sample. It was set in the form

http://myserver:8080/tfs/MyCollection

This is not that sensible, as this value is available using the build API as

BuildDetail.BuildServer.TeamProjectCollection.Uri.ToString()

It makes no sense to hard code the name of the server if the build system already knows it.

This simple change means that the build templates can be fair easier past between Team Projects Collections

Access MVP Ben Clothier has posted an article and video on Going beyond Web Macros: Using Event Receivers & .NET with Access Services. This takes some of the techniques I was proposing for .NET/Access integration and added to them using Ben’s extensive experience in the Access space.

Well worth a look if you want to make Access a RAD front end to legacy systems.

Just spent a while battling a problem whilst install the TFS 2010 Test Controller. When I launched the install setup program off the .ISO  I could select the Test Controller installer, but then a command prompt flashed up and exited with no obvious error. If I went into the TestControllers directory on the mounted .ISO and ran the setup from a command prompt I saw the error "program too big to fit in memory".

As the box I was trying to use only had 1Gb of memory (below the recommended minimum), I upped it to 2Gb and then to 4Gb but still got the same error.

Turns out the problem was a corrupt .ISO once I had downloaded it again, and dropped by target VM to 2Gb of memory all was fine.

I am very impressed with the iPlayer Media Center Plugin I found on the Australian Media Center Community, I like most people found it installed fine but that it failed to add itself to the start menu. However this was easily fixed using Media Center Studio once I got my head around the Media Center Studio’s user interface. The basic process is:

1. Load Media Center Studio
2. Go onto the Start Menu tab
3. At the bottom of the screen look for the entry points section (needs expanding usually)
4. In here you should find the iPlayer application (has a red’ish pay button logo)
5. Drag it onto whichever part of the start menu you want, but be aware there are some limitation as to where it can go, Extensions worked fine for me
6. Save the changes
7. Restart Media Center

Once this is done you should be able to view WMV based iPlayer content from within Media Center. I have seen it take a while to start buffering content, but other than that it seems to work well and certainly looks the part.

Another follow up post, this time to the one on MSDeploy. As I said in that post a better way to trigger the MSDeploy PowerShell script would be as part of the build workflow, as opposed to a post build action in the MSBuild phase. Doing it this way means if the build failed testing, after MSBuild complete, you can still choose not to run MSDeploy.

I have implemented this using an InvokeProcess call in my build workflow, which I have placed just before Gated checking logic at the end of the process template.

The if statement is there so I only deploy if a deploy location is set and all the tests passed

BuildDetail.TestStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded And
String.IsNullOrEmpty(DeployLocation) = False

The InvokeProcess filename property is

BuildDetail.DropLocation & "\_PublishedWebsites\" & WebSiteAssemblyName & "_Package\" & WebSiteAssemblyName & ".deploy.cmd"

Where “WebSiteAssemblyName” is a build argument the name of the Project that has been publish (I have not found a way to automatically detect it) e.g. BlackMarble.MyWebSite. This obviously as be set as an argument for the build if the deploy is to work

The arguments property is set to

"/M:http://" & DeployLocation & "/MSDEPLOYAGENTSERVICE /Y”

Again the “DeployLocation” is a build arguement that is the name of the server to deploy to e.g. MyServer

The Result property is set to an Integer build variable, so any error code can be returned in the WriteBuildError

This seems to work for me and I think it is neater than previous solution

I posted a while ago on using my Typemock TMockRunner Custom Activity for Team Build 2010. I left that post with the problem that if you wished to customise a template after you a had added the custom activity you had to use the somewhat complex branching model edit the XAML.

If you just followed the process in my post to put the build template in a new team project and tried to edit the XAML you got the following errors, an import namespace error and the associated inability to render part of the workflow

The best answer I have been able to find has been to put the custom activity into the GAC on the PC what you wish to edit the template on, just there nowhere else the method in the previous post is fine for build agents. So I strongly signed the custom activity assembly, used GACUTIL to put it in my GAC and was then able to load the template without any other alterations. I as also able to add it to my Visual Studio toolbox so that I could drop new instances of the external test runner onto the workflow.

The last of the recent batch of  announcements is that of the first official release of the TFS Integration Platform. This provides tools to allow synchronisation between TFS 2010 and …..

• TFS 2008
• TFS 2010
• ClearCase
• ClearQuest
• File System

Again more details on Brian Harry’s blog.

Another recent announcement from Brian Harry’s blog was about the release of the Microsoft Team Foundation Server 2010 MOSS Configuration Tool. I had a look at this tool during it’s beta testing and it certainly can help to get all the setting right to allow Excel Services to provide your charting for TFS projects, it worked for us.

In the VSLive! keynote Microsoft made announcements about Lab Management, it will be RTM’d later this month and best of all it will be included as part of the benefits of the Visual Studio 2010 Ultimate with MSDN and Visual Studio Test Professional 2010 with MSDN SKUs. You can read more detail on Brian Keller’s blog

I think this is a great move on licensing, we had expect it to be purchasable addition to Visual Studio. With this change it now is consistent with TFS i.e. if you have the right SKU of Visual Studio and MSDN you get the feature. This greatly removes the barrier to entry for this technology.

I look forward to have a forthright discussion with our IT manager over Hyper-V cluster resources in the near future

[Also see Running MSDeploy to a remote box from inside a TFS 2010 Build (Part 2)] 

A fellow MVP Ewald Hofman wrote a great post on getting an Web Application to deploy as part of a TFS 2010 build. I have been using this technique but found a few points that were not right in the original post, I assume these are down to RC/RTM issues and the fact I was trying to access a remote system.

This is what I had to do

1. Follow the details referenced by Ewald in the post to create a MSDeploy package, for me the default setting were fine as all I wanted to deploy was a basic web site that had no need for any SQL
2. Test that this package is works from your development PC to the target web server. If I viewed this publish profile in VS2010 I see the following
   
   
3. Now all these details are stored in a <ProjectName>.Publish.xml file in the project root directory. However, this file is not source controlled. It is only for use on the development PC.
4. You need to set the Site/Application name that will be used when the build server rebuilds this file. This is done by going into the project properties and onto the Package/Publish Web tab. At the bottom of the page set the IIS web application. If you don’t set this the package built will default to the Default Site/<Project Name> Deploy virtual directory, In my case I just wanted to point to the root of a dedicated II6 hosted web site called Test3.
   
   
   
    
   
5. You now need to got back to Ewalds post. In the build definition you need to add the /p:DeployOnBuild=True MSBuild parameters to cause the package to be created
   
   
   
   
6. As he says this causes the package to be created, but not deployed, to do this you need to add a post build event to the project (Or you could edit the Build Process Template to add a PowerShell step at the end, which might be a better option. I have found as I am using a gated Check-in I get the deployment prior to the build doing testing, so potentially I publish something that builds but the tests fail).
   
   Now this is where I found the most obvious difference in the post, and that is the path. My post build step had the following
   
   if "$(ConfigurationName)" == "Release" "$(TargetDir)_PublishedWebsites\$(TargetName)_Package\$(TargetName).deploy.cmd"  /M:http://hunter/MSDEPLOYAGENTSERVICE  /Y
   
   The first point is that the generated file path and file name is different to that in Ewald’s post. The second point is that he was trying to deploy locally to allow a CodeUI test to run, I wanted the build to be deployed to a simple IIS server (not a clever lab management environment) so I also need the /M: parameter.
   
   Also remember is that the build agent service user (in my case TFSBuild) must have admin rights on the box you are trying to deploy too, esle the process fails
   

Now I know this should be simple and obvious but I had a few problems today publishing a web service to a new IIS7 host. These are the steps I had to follow to get around all my errors:

1. Take a patched Windows Server 2008 R2, this had the File Server and IIS roles installed.
2. I install MSDeploy (http://blog.iis.net/msdeploy) onto the server to manage my deployment, this is a tool I am becoming a big fan of lately.
3. Make sure the MS Deploy service has started, it doesn’t by default.
4. In IIS manager
1. Create a new AppPool (I needed to set it to .NET 4 for my application)
2. Create a new Web Site, pointing at the new AppPool
5. In Visual Studio 2010 create an MSDeploy profile to send to the new server and web site. This deployed OK
6. AND THIS IS WHERE THE PROBLEMS STARTED
7. When I browsed to my WCF webservice e.g.http://mysite:8080/myservice.svc whilst on the server I got a ‘500.24 Integrated Pipeline Issue’ error. This was fixed by swapping my AppPool’s pipeline mode to Classic, as I did need to use impersonation for this service.
8. Next I got a ‘404.3 Not Found’ error. This was because the WCF Activation feature was not installed in the box. This is added via Server 2008 : Server Manager -> Add Features-> .Net Framework 3.x Features -> WCF Activation
9. Next it was a ‘404.17 Not Found Static Handler’. If I looked in IIS Manager, Feature View, Handler Mapping I only saw mention on 2.0 versions of files. So I reran aspnet_iisreg /i from the 4.0 framework directory and both 2.0 and 4.0 versions were shown in the Handler list
10. Next it was a ‘404.2 Not Found. Description: The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server’. In the IIS Manager at the server level I had to enable the .NET 4 handlers in ISAPI and CGI restriction section
11. I could then get to see the WSDL for the WCF service
12. And finally I had to open port 8080 on the box to allow my clients to see it.

Now that was straight forward wasn't;t it.

If you have VS2010 Premium or Ultimate [Professional corrected error in orginal post]  you have code coverage built into the test system. When you look at your test results there is a button to see the code coverage

You would think that there is easy way to use the code coverage in your automated build process using Team Build 2010, well it can done but you have to do a bit of work.

What’s on the build box?

Firstly if your build PC has only an operating system and the Team Build Agent (with or without the Build Controller service) then stop here. This is enough to build many things but not to get code coverage. The only way to get code coverage to work is to have VS2010 Premium or Ultimate also installed on the build box.

Now there is some confusion in blog posts over if you install the Visual Studio 2010 Test Agents do you get code coverage, the answer for our purposes is no. The agents will allow remote code coverage in a Lab Environment via a Test Controller, but they do not provide the bits needs to allow code coverage to be run locally during a build/unit test cycle.

Do I have a .TestSettings file?

Code Coverage is managed using your solution’s .TestSetting file. My project did not have one of these, so I had to ‘add new item’ it via add on a right click in the solution items.

The reason I had no .TestSettings file was because I started with an empty solution and added projects to it, if you start with a project, such as a web application, and let the solution be created for you automatically then there should be a .TestSettings file created.

In the test settings you need to look at the Data & Diagnostics tab and enable code coverage and then press the configure button, this is important.

On the configuration dialog will see a list of your projects and assemblies. In my case initially I only saw the first and the last rows in the graphic below. I selected the first row, the project containing my production code and tried a build.

THIS DID NOT WORK – I had to added the actual production assembly as opposed to the web site project (the middle row shown below). I think this was the key step to getting it going.

The error I got before I did this was Empty results generated: none of the instrumented binary was used. Look at test run details for any instrumentation problems.  So if you see this message in the build report check what assemblies are flagged for code coverage.

Does my build definition know about the .TestSettings file?

You now need to make sure that build knows the .TestSettings file exists. Again this should be done automatically when you create a build (if the file exists), but on my build I had to add it manually as I created the file after the build.

So when all this is done you get to see a build with test results and code coverage.

Easy wasn’t it!