But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

What is an .xesc file?

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.

Cannot run CodeUI tests in Lab Management – getting a ’Build directory of the test run is not specified or does not exist’

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

image

I made sure my deployment build had the tests selected

image

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)

image

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.

image

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

image

Don’t hardcode that build option

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

"Program too big to fit in memory" when installing a TFS 2010 Test Controller

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.

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!

All Leds flashing on a Netgear GS108 Switch

I came back form holiday to find a Netgear GS108 switch with all it leds flashing and it passing no data. This is exactly the same symptoms as this post. My fix did not involve the use of a soldering iron as detailed in the post, I just swapped the PSU and it started working fine. I have seen this before, the PSU shows it’s age before the device itself. Good job I have a big box of misc PSU from devices down the years

Update 22 July 2010: I spoke too soon, came in today to the same problem. Time to swap the capacitors

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.

How little do you have to do to run a VS/TFS2008 build on a TFS2010 server?

As do many people I have a good number of TFS2008 style builds for legacy applications. I will, in the end, move these over to VS2010 and hence upgrade their build formats to the new 2010 workflow based one, but for now it would be nice to be able to run them with the minimum of effort. To this end I have done some work to see the minimum I can get away with to allow these builds to run, the aim being to leave the build box as close to a virgin TFS2010 one as possible.

Basic Setup
My basic build system was

  • Windows Server 2008 32bit with SP2
  • TFS 2010 build

A VS2010 Test
Just to make sure all was OK, I created a basic VS2010 MVC2 project with it’s default tests. I then create a default build for this. This failed as my build machine did not have the targets to build a web application. I copied the directory

C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications

up from a development PC to the build box and tried again. The build still failed as it was missing MVC2 assemblies, I downloaded the AspNetMVC2_VS2008.exe installer to get these assemblies on my build box. Once this was all done the build worked and the tests passed

A VS2008 Test
So I knew I had a 2010 build system that could build and test a 2010 solution. I next took an existing VS2008 solution’s build, this build had been upgraded as part of the TFS2008->2010 server upgrade. The build failed completely. This was not surprising as as well as being for a different version of VS I knew that was missing a number of custom build tasks.

First I had to install all the custom tasks, for me this was

Once all these imports were present the build tried to compile, and failed with the error.

C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets(133,11): error MSB4064: The "Retries" parameter is not supported by the "Copy" task. Verify the parameter exists on the task, and it is a settable public instance property.
C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets(131,5): error MSB4063: The "Copy" task could not be initialized with its input parameters.  [c:\builds\Moorcroft Website\Debt Collection

I spent a lot of time fiddling here, if I replaced my

C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets

with one form my PCs V9.0 directory all was OK, but then I found this post that sugested to just removed the offending parameters in the targets file, they are just retry and timouts! Once I did this the build attempted to compile the solution (and I checked it still worked for my VS2010 MVC2 solution).

I now got another set of missing assemblies errors. This was due to the lack of MVC1 on the build box, this was downloaded and installed

So now my MVC1 web site built, but the associated test project failed. This was because the V9 of Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll could not be found, the build box had V10. To address this I changed the assembly reference in the test project from the GAC to a copy of the assembly I included under source control, so it could be pulled to the build server.

Everything now built. However the tests did not run. There was an error that MStest could not be found. I edited the tfsbuild.proj to add the path to the MSTest file

PropertyGroup>
    <!-- TEST ARGUMENTS
     If the RunTest property is set to true, then particular tests within a
     metadata file or test container may be specified here.  This is
     equivalent to the /test switch on mstest.exe.

     <TestNames>BVT;HighPriority</TestNames>
    -->
    <TestToolsTaskToolPath>C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE</TestToolsTaskToolPath>
  </PropertyGroup>

If I looked at the build log I could see that MSTest now ran, and I could see all my 100+ test, but they all failed and were not published to the TFS server. I copied the .TRX results file local from the build box and opened it in VS2010. I could then see that all the test failed because the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll could not be seen. I am not sure it is great solution but I just dropped a copy into the same directory as MSTest.exe C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE. The other option I could think of would be to put it in the GAC.

Once this was done most of the test executed and passed Ok, but some still did not. Again checking the .TRX file, as it still did not publish the results, was due to problems with TestContext. It seems the V9 assembly passes TestContext parameters in a different way to the V10 one. The test that passed did not have any TestContext declared. So as I did not need TestContext for these tests I just commented them out.

All my test now ran, past, and the results were publish. The problem was if a test failed the results were not published, but this seems to be a know issue so nothing I can do about that now.

So I now have build that mostly work, probably well enough for now. I have not need to install VS2008 or VS2010 on the build box which is nice. Just have to see how well the build holds up in production.

TF31002: Altering the URL that your TFS 2010 Web Client uses to talk to the AT

The Web Client for TFS 2010 (what was called Team System Web Access TSWA) is now installed as a core part of the Application Tier. It is no longer a separate install as it was in previous versions. This means it is easy to implement, it is just there by default. However, this can raise some problems if intend to expose to TFS AT via a firewall to the Internet, or use an alias for your TFS AT. This is because, by default, the Web Client uses it’s host server name as the AT name to connect to, it assumes the AT is local.

So for example, if you install your AT on SERVER1 you can set the server so that it responds to calls to the name TFS.DOMAIN.COM (after suitable DNS registration and disabling of local loopback checks on the server). So all your TFS clients should be able to access the server via http://tfs.domain.com:8080/tfs. However if a user tried to access the sever via Web Client URL of http://tfs.domain.com:8080/tfs/web they will get an error that that the inferred local AT (http://server1:8080/tfs) cannot be resolved (from where they are outside the firewall.

image

TF31002: Unable to connect to this Team Foundation Server: https://server1/tfs. Team Foundation Server Url: https://server1/tfs. Possible reasons for failure include: - The name, port number, or protocol for the Team Foundation Server is incorrect. - The Team Foundation Server is offline. - The password has expired or is incorrect. Technical information (for administrator): The request failed with HTTP status 404: Not Found.

This is easily addressed edit the C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Access\Web\web.config file and explicitly name the AT to be used for the web client. This is in the block

<tfServers>
     <!-- <add name="
http://server:8080" /> -->
</tfServers>

Note here the sample URL is wrong, when you are done it should look something like

<tfServers>  
  <add name=
http://server1:8080/tfs /> -
</tfServers>

Interestingly this fixes the issue on the screen shot above for the lower instance of the error, but not, the upper one. However that is enough to get you into the client and you don’t see the error after that.