But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Visual Studio 2010 Lab Management released announced

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

Running MSDeploy to a remote box from inside a TFS 2010 Build

[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

    image
  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.


    image
     
  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


    image
  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

Getting a ,NET 4 WCF service running on IIS7

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.

Getting code coverage working on Team Build 2010

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

image

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.

image

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.

image

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.

image

 

 

 

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

image

Easy wasn’t it!

Next weeks Agile Yorkshire meeting: Some things about testing that everyone should know, ...... but were afraid to ask, in case somebody told them.

It is Agile Yorkshire time again, it is a real shame that due to the move of the meeting from the 2nd Wednesday to the 2nd Tuesday I really struggle to make the events. Particularly irritating this month as this one look really interesting and the speaker, Ralph Williams, from past evidence always is entertaining. To quote the Agile Yorkshire site the session will..

“The presentation will focus on the techniques that testers use to identify their tests, whether working from a requirements specification or on agile teams.

Agile testing books mostly focus on the agile aspects or the technology so this area often gets glossed over. The main sections would be:

    • Equivalence Classes and Boundary Conditions
    • Decision Tables
    • Classification Trees
    • User Focused Testing

There will be a group exercise looking a how these techniques can be applied to the testing of a well known website.

As a group we will go through the process of identifying the testing that is required and in the process explain various test techniques that might be useful to people back in their day jobs.”

For full details see http://www.agileyorkshire.org/event-announcements/10Aug2010