But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

At last, my creature it lives……..

I have at last worked all the way through setting up my portable end to end demo of  testing using Windows Test and Lab Manager. The last error I had to resolve was the tests not running in the lab environment (though working locally on the development PC). My the Lab Workflow build was recorded as a partial success i.e. it built, it deployed but all the tests failed.

I have not found a way to see the detail of why the tests failed in VS2010 Build Explorer. However, if you:

  1. Go into MTLM,
  2. Pick Testing Center
  3. Select the Test Tab
  4. Pick the Analyze Test Results link
  5. Pick the test run you want view
  6. The last item in the summary is the error message , as you can see in my case it was that the whole run failed not any of the individual tests themselves

image

So my error was “Build directory of the test run is not specified or does not exist”. This was caused because the Test Controller (for me running as Network Service) could not see the contents of the drop directory. The drop directory is where the test automation assemblies are published as part of the build. Once I gave Network Service read rights to access the \\TFS2010\Drops share my tests, and hence my build, ran to completion.

It has been a interesting journey to get this system up and running. MTLM when you initially look at it is very daunting, you have to get a lot of ducks in a row and there are many pitfalls on the way. If any part fails then nothing works, it feels like a bit of a house of cards. However if you work though it step by step I think you will come to see that the underlying architecture of how it hangs together is not as hard to understand as it initially seems. It is complex and has to be done right, but you can at least see why things need to be done. Much of this perceived complexity for me a developer is that I had to setup a number of ITPro products I am just not that familiar with such as SCOM and Hyper-V Manager. Maybe the answer is to make your evaluation of this product a joint Dev/ITPro project so you both learn.

I would say that getting the first build going (and hence the underlying infrastructure) seems to be the worst part. I feel that now I have a platform I understand reasonably, that producing different builds will not be too bad. I suspect the next raft of complexity will appear when I need a radically different test VM (or worse still a networks of VMs) to deploy and test against.

So my recommendation to anyone who is interest in this product is to get your hands dirty, you are not going to understand it by reading or watching videos, you need to build one. So find some hardware, lots of hardware!

ASPNETCOMPILER: error 1003 with TFS2010 Team build

I have been looking at TFS 2010 Lab Manager recently. One problem I had was that using the sample code from the Lab Manager Blog Walkthru the building of the CALC ASP.NET web site failed on the build server, I got an error

ASPNETCOMPILER: error 1003 The directory ‘c:\build\1LabWalkthru\Calculator –Build\Calc’ does not exist.

and the build service was right it didn’t exist; it should have been ‘c:\build\1LabWalkthru\Calculator –Build\Source\Calc’.

This was due to a problem detailed here. The Solution file had the wrong path in the Debug.AspNetCompiler.PhysicalPath property. It was set to “..\Calc” when it should have been “.\Calc”. Once this was altered the build could find the files.

Problem creating workitems on TFS2010 in the morning

I recently been working with a client who has been seeing strange problems when they try to create new workitems via a SharePoint portal site on a TFS2010 Beta2 installation. They appeared to have a fully working TFS2010 installation, but when they came in on a morning they found that even though they could login to the TFS created SharePoint team site they could not create a new workitems, they got an “Error 403 Access Forbidden”.

If they logged into SharePoint as a user with system administration rights it all worked fine. Now here is the strange bit, if they then logged in the user who got the 403 error it all worked fine, but when they came in the next morning it all happened again.

Turned out the issue was due to underling file access rights, once these were fixed all was OK. basically only the admin user had enough rights to populate a cache. Why this had occurred was still a bit of a mystery, but it is something you might see on any SharePoint installation. If you see a issue similar to this, the best option is to use Process Monitor to see if there are any file IO problems. This should point you in the right direction

So you want to demo VS2010 Lab Manager…….

I recently decided to build a demo system for VS2010 Lab Manager. This was for a number of reasons, not least I just wanted to have a proper play with it, but also that I was hoping to do a session on Microsoft Test and Lab Manager at DDD8 (as it turns out my session did not get voted for, maybe better luck for DDS, you can still vote for that conference’s sessions).

Anyway if any of you have looked at the Lab Manager side of MTLM you will know that getting it going is no quick task. Firstly I cannot recommend highly enough the Lab Management Teams’ blog posts ‘Getting started with Lab Management’ Parts 1, 2 ,3 and 4. This type of walkthrough post is a great way to move into a new complex product such as this. It provides the framework to get you going, it doesn’t fix all your problems but gives you a map to follow into the main documentation or other blog posts.

The architecture I was trying to build was as below. My hardware was a Shuttle PC as this was all I could find in the office that could take 8Gb of memory, the bare minimum for this setup. Not as convenient as a laptop for demos, but I was not going to bankrupt myself getting an 8Gb laptop!

image

As I wanted my system to be mobile, it needed to be it’s own domain (demo.com). This was my main problem during the install. MTLM assumes the host server and all the VMs are in the same domain, but that the domain controller (DC) is on some other device on the domain. I installed the DC on the host server; this meant I had to do the following to get it all to work (I should say I did all of these to get my system running, but they may not all be essential, but they are all sensible practice so probably worth doing)

  • Run the VMM Host as a user other than the default of Local System (this is an option set during the installation). The default Local System user has reduced rights on a domain controller, and so is not able to do all that it needs to. I create a new domain account (demo\VMMserver) and used this as the service account for the VMM.
  • The ‘Getting Started’ blog posts suggest a basic install of TFS, this just installs source control, work item tracking and build services using a SQL Express instance. This is fine, but this mode defaults to using the Network Service account to run the TFS web services. This has the same potential issues as the Local System account on the DC, so I swapped this to use a domain account (demo\TFSservice) using the TFS Administration console. 
  • AND THIS IS THE WIERD ONE AND I SUSPECT THE MOST IMPORTANT. As I was using the host system as a DNS and DHCP the VMs needed to be connected to the physical LAN of the host machine to make use of these services. However as I did not want them to pickup my office’s DHCP service I left the physical server’s Ethernet port unplugged. This meant that when I tried to create a new lab environment I got a TF259115 error. Plugging in a standalone Ethernet hub (connected to nothing else) fixed this problem. I am told this is because part of the LAN stack on the physical host is disabled due to the lack of a physical Ethernet link, even though the DNS and DHCP services were unaffected. The other option would have been to run the DNS, DHCP etc on Hyper-V VM(s).
  • When configuring the virtual lab in TFS Administration console the ‘Network Location’ was blank. If you ignore this missing Network location or manually enter it you get a TF259210 error when you verify the settings in TFS Administration. This is a known problem in SCVMM and was fixed by overriding the discovered network and entering demo.com.

So I now had a working configuration, but when I try to import my prepared test VM into Lab Center, I got an “Import failed, the specified owner is not a valid Active Directory Domain Services account, Specify a valid  Active Directory Domain Services account and try again” error. If I check the SCVMM jobs logs (in SCVMM Admin console) I saw this was an Error 813 in the ‘create hardware setup’ step. However, the account the job was running as was a domain user, as was the service account the host was running on (after I had made the changes detailed above) as I was confused.

This turns out to be a user too stupid error; I was logged in as the TFS servers local administrator (tfs2010\administrator) not the domain one (demo\administrator), or actually any domain account with VMM administrator rights. Once I logged in on the TFS server (where I was running MTLM) as a domain account all was OK. Actually I suspect moving to the VMMService and TFSService accounts was not vital, but did not harm.

I could now create my virtual test environment and actually start to create Team Builds that make use of my test lab environment. Also I think having worked though these problems I have a better understanding of how all the various parts underpinning MTLM hang together, a vital piece of knowledge if you intend to make real use of these tools.

Oh and thanks to everyone who helped me when I got stuck

Problems installing TFS Proxy

I recently saw an interesting problem install a TFS proxy (in my case it was on an existing TFS 2005 system using Window Server 2003 for the proxy host, but the problem could be seen on any version f TFS). The installation appeared to go fine, and when a Visual Studio client requested files, via the proxy, files appeared in the cache directory, however the client reported it was not using the proxy.

When I tried to look at the proxy statistics using http://localhost:8080/VersionControl/v1.0/proxystatistics.asmx I was shown a standard IE login dialog, not what expected as I was logged in as the administrator. No credentials were found that could get past this dialog.

I started looking a firewall settings, anti virus port blocker, and local loopback settings, but it turned out the problem was far more fundamental. The IIS6 installation was corrupted. When I dropped test files into the proxy server virtual directory I found I the server could render an HTML page but not an .ASP or ASP.Net ones.

So I removed IIS from server, then put it back and on the problems went away. All I can assume is some IIS/.NET installation/patching order issue. I bet it would not have happened with I had started with Server 2003 R2 with .NET already on it.

TFS 2010 Build Service Configuration Wizard fails with TF255425 error

I have at last got round to setting up a full installation VS 2010 Test and Lab Manager using the excellent notes from the Lab Management Team. Whist installing the build server portion I got a strange set of errors.

TF255425: An error occurred while installing the following Windows service: TFSBuildServiceHost.exe. For more information, open Event Viewer and review the application log.

Error

TF255070: Configuring services for Team Foundation Build failed with the following exception: TF255425: An error occurred while installing the following Windows service: TFSBuildServiceHost.exe. For more information, open Event Viewer and review the application log..

Further investigation found the installer was claiming it could not find required files and so could not complete the install.

After a good deal of ineffective fiddling I cam to the conclusion the issue must be user access. I was using the trial Windows Server 2008 R2 vhds as the basis of my TFS server and test VMs, now these default to US region and keyboard. This had gotten on my nerves and I thought I had changed it to UK settings. However, I must have done it wrong as I had a UK keyboard in WinForm application but not in a Command Prompt. Once I made sure that my region, keyboard (and associated defaults) were all set to UK (and were working as expected in all locations) I tried the wizard again and it worked.

So it seems the issue was an incorrect password being passed to the installer. Some how the @ in Pass@word1 was being translated behind the scenes I guess to “ and causing the wizard to fail, though it always passed the verify stage of the wizard.

So the technical tip is to make sure the keyboard and region are right before you start, bit of a newbie error there!

Making a TFS2010 Beta2 server use SSL Ports

There any many good document on how to migrate a TFS server from it’s default ports of 8080 (tfs) and 80 (Sharepoint/Reports) to 8443 and 443, usuall to allow Internet access. A good place to start is Aaron Block’s post on the subject

I did find a problem whist sorting this on a system today, this was that although we had modified all the services to operate on the SSL secured ports the vaious TFS team project WSS sites were still trying to access reports on http://servername/reports not the new https://tfs.mydoman.com/reports url. The reason for this was that the tfsredirect.aspx cache needed to be cleared, WSS did not know we had updated the server.

Again I found a few posts on this, but they all seem to date from the Beta1 era and had the same problems i.e. an error was returned. Turns out that the URL to clear the cache is

http://servrname/sites/MyCollection/Project1/_layouts/TfsRedirect.aspx?tf:Type=ReportList&tf:ClearCache=1&tf:Test=1

Note the tf:Type parameter is ReportList and not ReportLists as most blog posts state. Once this clear cache was run the WSS Reports leapt into life.

A busy week of presenting

The interest in Visual Studio 2010 is growing, I am presenting at two events this week and have another day of less formal meetings on the subject.

The event on Thursday is the Architecture Forum in the North we are hosting with Microsoft, there are still a few spaces available is if you are interested in the learning more about new techniques and tools why not come along. You even get to hear me talking about using TFS as a Java developers via Teamprise.

Hope to see you there.

Notes on TFS2010 Beta1 to Beta 2 Upgrade

I have recently upgraded my dual tier TFS 2010 Beta1 instance to Beta2. This is not an officially supported migration but it is certainly possible. The basic process of the update is straight forward:

  • Remove Beta1 from the AT
  • Install Beta2
  • Run the configuration wizard in upgrade mode (this took a few hours for DB upgrades)

Once this was complete I had what I thought was a working Beta2 server (I saw no errors), but there were problems.

Firstly for some reason the upgrade had lost the binding of port 8443 on the TFS web site (we use this to talk to the TFS server over Internet using SSL). This was fixed by rebinding the port and certificate in IIS manager. Now I could access the version control and work items both inside and outside our firewall.

The more major problem was when I tried to load the SharePoint sites associated with the Team Projects. I always got the error

Parser Error Message: Could not load type 'Microsoft.TeamFoundation.SharePoint.Dashboards.ApplicationMasterModule' from assembly 'Microsoft.TeamFoundation.SharePoint.Dashboards, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. (C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config line 94)

I had to comment out this HTTP MODULE at line 94 in the web.config. The reason for this error was that this module was a Beta1 assembly and not present at all in the Beta2 release. This edit meant I could now load the SharePoint sites for the TFS collections e.g. http://tfs2010/sites/DefaultCollection but when I tried to open a project site e.g. http://tfs2010/sites/DefaultCollection/Project1 I still got an error. The basic problem was that the SharePoint templates (created from TFS Process Template) were of the old Beta 1 type, which pointed to all the wrong reports and work item types.

Grant Holiday has written a great post on what needs to be done to start to address this problem. Following his process to change the template I got rid of the main of the error (due to wrong master page), but not all the problems. The page loaded but many of the webparts failed to render. As most of the errors were now related to reports before this could fix SharePoint I had to fix the reporting services.

The reports did not work as the TFS Warehouse schema is different between Beta1 and Beta2. I got the new Beta2 reports out the the zip file C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Deploy\ProcessTemplateManagerFiles\MsfAgile\Template.zip. I then replaced the existing reporting on the AT’s reporting services instance for each team project. When doing this, watch out that some of the reports have changed their names, so it is best to deleted any old reports you are not replacing to avoid confusion. Also remember that you have to reconnect all the data sources in the report properties before they can be run.

Now the reports worked in Reporting Services (and Team Explorer) I could now return to the SharePoint site. The main problem was that I was getting TF262600 errors, stating that the SharePoint site was not linked to a TFS project. This was easily fixed, in Team Explorer right click on a Team Project and select the Portal Site menu option. You see the dialog

image

It looks and reports that it is correctly configured, but it is not. The answer is to uncheck the ‘Reports and dashboards refer to data for this team project’ press OK and then open the dialog again and recheck it. This re-establishes the link between the portal site TFS. If the site is now reloaded the webparts that show work items now work and the TF262600 errors at the top of the page have gone.

The final step is to fix the reports in the dashboards web pages. The problem here was purely the names of the reports were wrong. A simple edit of the report viewer webparts fixed this and all the dashboards worked.

So now the sever was working and clients could access all the sub parts of the TFS instance.

There remained a related job and that was to fix the builds box. Again I uninstalled Beta1 and reinstalled Beta2. When I ran the configuration tool it picked up the old configuration without a problem for the agent and controller. However, when I tried to queue a build it errored, Again the problem was the template had changed. For each project I replaced the XAML template file with the equivalent one from C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Deploy\ProcessTemplateManagerFiles\MsfAgile\Template.zip\Build\Templates. I then had to edit each build to set the revised properties. I could then run a build. Again it did initially fail as TFS claimed there were workspace map conflicts. To get around this I just deleted all workspaces for the TFSbuild user and let them be recreated, and then all worked.

So now I had an error free Beta2 system, there was a good deal of manual work to do to sort out SharePoint, but it is all fairly easy once you work though it step by step.

Next I need to look at our main TFS 2008 instance