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 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!

Running SPDisposeCheck as part of a 2010 CI Build

SPDisposeCheck is a great tool for SharePoint developers to make sure that they are disposing of resources correctly. The problem is it is a bit slow to run, a problem as this will mean developers will tend not to run it as often as they should. A good solution to the problem is to run it as part of the continuous integration process. There is are posts on how to do this via unit tests and as a MSBuild task, but I wanted to use a TFS 2010 style build. Turns out this is reasonably straight forward without the need to write a custom activity.

  • I created a build template based on the Default one.
  • After the compile and before the test step I added a InvokeProcess activity

image

  • I set the InvokeProcess properties as shown below, the edited settings are
    • Arguments: String.Format(“””{0}””””, outputDirectory) (remember you need the enclosing “ if your path could have spaces in it)
    • Filename: To the location of the SPDisposeCheck.exe file
    • Result: A previously created build variable of type Int32

image

image

  • This is done with a simple if check. If there are any errors found I write a build error message and set the TestStatus to failed. You might choose to set the build status to fail or any other flag you wish. The potential problem with my solution is that the TestStatus value could be reset by the tests that follow in the build process, but for a basic example of using the tool this is fine.

So it is easy to added a command line tool to the build. The key reason it is so easy is that SPDisposeCheck returns a number that we can use to see if the test passed or failed. hence we did not need to parse any text or XML results file. I wish more tools did this.

Using my Typemock TMockRunner Custom Activity for Team Build 2010

[Also see http://blogs.blackmarble.co.uk/blogs/rfennell/archive/2010/08/13/how-to-edit-a-tfs-2010-build-template-when-it-contains-custom-activities.aspx ]

A couple of months ago I wrote and published a custom activity for Team Build 2010 to allow Typemock tests to be run within the build process. Whilst setting up a new build need to use this activity so I though I would see if there was an easier way to use it in a build without all the branch and fuss required for development.

This is what I had to do

  • Get the Zip file what contains all the source and binaries for the custom activity
  • In your Team Project’s Source Control Explorer go to the BuildProcessTemplates folder. You should see (at least) the three standard templates: Default, Upgrade and Lab. Add the TypemockBuildProcessTemplate.xaml template from the \Source\TypemockBuildActivity folder in the zip to the BuildProcessTemplates folder
  • Under the BuildProcessTemplates folder create Custom Activities folder and into this add the TypemockBuildActivity.dll file from the root of the zip
  • Check it all these added files
  • On your Build Controller (login to the build PC and open the Team System Administration console) set its custom assemblies path to point to the folder where the custom activity DLL is stored


image 

  •  

    • You can now edit an existing build, or create a new build, to make use of the new template. You should see the new template in the list of templates, if not just use the new template option then browser to find an existing template. It is up to you of you wish to use the original or make a copy
    • As the template takes the same options as the default template it can be used as direct replacement
    • AND THIS IS WHERE YOU HIT A PROBLEM
    • The process template in the zip has parameters set for the custom activity that were correct for the test harness used for development and the source control system it was mean to upload results to. Even for me, working on the same network, these are wrong for my new project. These parameters need to be edited.
    • Usually editing would be be done using the graphical build editing tool in Visual Studio. However as detailed in my original post, getting the custom assembly in a location so that it is correctly registered with Visual Studio involves some messy branching, and if this is not done you get error block in the graphical editor.
    • There is only one way I know how to avoid this and that is to do the editing in a text editor. The parameters that needed editing for me were
      • ProjectCollection – needs to point to the right TPC
      • TestRunnerExecutable – the location of the Typemock TMOCKRunner program as different on a 32bit PC to a 64bit build machine
    • You may need to edit more, but it is easy to see what is wrong if you try a build and look at the build log, all the parameters passed on the command line are listed, as well as any error messages.
    • Once I had completed my edits I checked the edited build template back into TFS
    • I had one further problem and that was MSTEST reported in the log that it could not run due to a missing /Platform parameter. The custom activity did not pass this parameter to MSTEST as in a default 2010 build it is not set. Once I explicitly set this my build (as shown below) it built, tests ran and results were published

    image

     

  • Hope this post makes adoption of the activity a little easier for you

    TF246062: Two or more database are in conflict when upgrading to TFS 2010

    Whist upgrading a TFS2010 Beta2 server to RTM I saw the following error when I ran the verify step of the upgrade.

    TF246062: Two or more databases are in conflict because they are each designated as the owners of the following schema: Framework. The schema is for the host with the following name and ID: CollectionName, 8aace481-2471-49c8-da74-77ee3da4ce29. The databases with this conflict are: Data Source=SQLInstance1;Initial Catalog=Tfs_CollectionName;Integrated Security=True, Data Source=SQLInstance1;Initial Catalog=Tfs_Production_CollectionName;Integrated Security=True. You must specify one and only one database owner for the schema in the searchable SQL Server instances for this deployment of Team Foundation Server.

    This error is caused because you have two Team Project Collection (TPC) DBs with the same unique GUID. So how can this happen and where do these GUIDs come from?.

    When you create a TPC it gets a GUID. It keeps this GUID if you disconnect it from a TFS server and move it to another server. The only time this GUID can change is if you clone the TPC. When the cloned TPC DB is attached, the TFS spots it is a clone of a TPC is already hosts and issues a new GUID.

    So how did I get two DBs with the same GUID? The answer is that prior to the upgrade some tests had been done using another TFS server to see if the client wished to do an in-place upgrade or disaster recovery style one onto new hardware. When doing a DR style upgrade the server does not issue a new GUID, as the TPC is unique to the new server, this server knows nothing of the original TFS server. This meant, as the two server shared a SQL cluster, that we had two copies of the same DB (but with different names) on the same SQL instance, so when the TFS upgrade program asked for the DBs by GUID it got back two DBs, hence the error.

    The fix was to delete the Db created during the previous tests.

    Note: You can see a similar effect if for any reason you replicate any of the TFS Dbs on a single SQL instance, such as to make a second copy of the warehouse DB for some special reporting purpose.