But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Presenting at the first meeting of the Peterborough VBug group

I enjoyed presenting on TFS at the inaugural meeting of the Peterborough VBug group last night. Thanks to Jyoti Majithia (VBug regional administrator) and Andy Westgarth (VBug chairman) for organising it. Hopefully this will be the start of another thriving user group community.

If anyone wants a copy of the slide stack, there were no major changes between the one I used last night and the DDD5 one our main web site. There is also a screencast of demo of eScrum in the same archive.

I was asked a couple of questions that I could not fully answer off the top of my head:

  • If you have a Novell NDS based LAN how can you install TFS? The answer is TFS does not support NDS or LDAP for authentication. Also you cannot do a Dual Server TFS install as this requires an Active Directory. However a Single Server install will work if all the PCs (clients and servers) are in a Windows Workgroup (as well as the NDS domain).
  • Can I access TFS from inside the Microsoft Expression products or Macromedia products such as Dreamweaver ? For Microsoft Expression the answer is strangely no - this seems a big oversight. User would have to check files out via Team explorer then load Expressions. There is the MSSCCI add-in to allow third party tools to connect to TFS, but this does  not appear to work with DreamWeaver as it has its own means of connection to source control such as VSS.

Fun upgrading from Visual Studio TFS 2008 Beta2 to RTM

A while ago I made the classic mistake of installing the Beta2 of TFS on our live servers after seeing posts that it was reliable enough for production use. I had stupidly assumed that there would be an upgrade path to the RTM; there usually is from the last beta, but not this time.

TIP: Don't ever do this yourself, only use beta's in places you can throw them away without any issues.

So to fix this problem you have to remove the beta before you can install the RTM. We run a dual server configuration with the application tier on a VPC so I backed up the TFS DBs on our central SQL server, made a copy of the VPC and enabled the undo disk. I then tried to remove the beta 2, and it failed with a message DepCheck indicates Microsoft Visual Studio 2008 Team Foundation Server Beta 2 - ENU is not installed.

I had a search and found some similar reference to the error in http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2048187&SiteID=1 that suggest running

"C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Microsoft Visual Studio 2008 Team Foundation Server Beta 2 - ENU\GetCurrentTfsProperties.exe" "%TEMP%\TfsProperties.ini" "Config"

Which as expected reported it could not find all the properties required.

So I had a problem, I could not de-install the old version to put the new one on. But then I got to thinking - I am trying to get this server back to a clean empty state - why not just create a new one? Just like a disaster recovery situation.

So I...

  • Built a new server and added to our domain.
  • I install WSS3 manually so that I could set the DB location to our dedicated SQL server.
  • I installed SQL reporting services and patched it, again pointing it to our SQL server.
  • I then ran the TFS 2008 installer, giving it the location of our DB server, as if just adding a new application tier.

The problems then started. I got a TF220065 RS WMI RPC Server is unavailable error - which sounds like a reporting server install problem (which it is I suppose). When you check the logs it turns out the installer has looked on the db tier for the URL of the AT reporting services location. The db still thought I was using the old AT server, so was getting an error the old server could not be found (because it was off). You can this fix by hand by editing the entry in the tfsintergration.tbl_service_interface table on the DB server. Once this is done the install runs OK until you get TF53007 & TF50801 errors. I guess there is a manual fix for this, but the better solution is to use the proper tool for registering the new server name, which fixes the follow-up errors as well. You can run this from the old TFS AT server, or I guess any PC.

TfsAdminUtil activateAT <New AT COMPUTERNAME>

Once this was run the setup ran to completion.

Now this meant I had a new AT pointing at our old DBs, so I could see all our old team projects, I could access work items,reports and source control. However, for each team project I could not access the site portals or document repositories, but I expected this as I had recreated the whole of the WSS system with a new content DB. This was not an issue for us as we had chosen to use our main company MOSS 2007 system for documents, not the WSS install within TFS (the main reason for this choice being for TFS2005 the portal was a WSS2.0 install and we had already moved to SP2007).

If you want to recreate the TFS portal sites go into the WSS Central Admin and create a site with the right name e.g. http://mysserver/site/project1 and an appropriate template. You then have to give the new site appropriate user rights and all will be OK i.e. you can see the portal and documents from within team explorer. Of course you could also restore a backup of your old install if you had important data.

So I was quite pleased with myself by this point, I had worked all this out by myself. I thought it was all working until I tried to create a new Team project, this failed at creating the SharePoint site point of the wizard. It failed irrespective of the template chosen. The error on the wizard dialog was TF30217 but checking the detailed log it showed the real error was

TF30267: Exception: System.Web.Services.Protocols.SoapException: Exception of type 'Microsoft.SharePoint.SoapServer.SoapServerException' was thrown.Event Description: TF30162: Task "SharePointPortal" from Group "Portal" failed
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: The Project Creation Wizard encountered an error while uploading documents to the Windows SharePoint Services server on [my server]
Exception Details: The Project Creation Wizard encountered a problem while uploading documents to the Windows SharePoint Services server on [my server]. The reason for the failure cannot be determined at this time. Because the operation failed, the wizard was not able to finish

Now this proved to be a nightmare to fix involving many hours of fiddling and calls to Microsoft support. As with so many of this type of problem the fix was trivial when we spotted it. The problem turned out to be due to alternate access mappings in SharePoint. In effect when TFS creates a new site this is equivalent to the STSADM command

stsadm -o createsite -url https://<server>/sites/projectsite -ownerlogin DOMAIN\user -owneremail user@domain.com -sitetemplate _GLOBAL_#1

The key issue was if I used the url https://realservername/sites/projectsite it work, but if I use the full alias url (which I need so the correct SSL wildcard certificate can be used) e.g.  https://tfs.domain.co.uk/sites/projectsite it failed even though tfs is a cname alias for the host realservername on our DNS server. They should be equivalent.

Now I knew SharePoint/IIS needs to know about any extra names you give to servers. I had put an alternate access mapping in SharePoint to cover just this issue (via Central Admin, Operations), but I had made a mistake. I had added the alternate mapping as http://tfs.domain.co.uk - oops should have been https. Once this tiny change was made it leapt into life.

I have to say the error in the TFS create log were not that helpful, neither was the output of the new TFS Best Practice Analyzer. In the end it was found by creating many sites with STSADM.

I must say thanks to the persistence of Microsoft Developer Support in both India and the USA in getting this last issue sorted.

So now I have a fully working TFS 2008 install, I can start to have a look at the TFS to Project Server connector.

SharePoint, TRACE.WriteLine and DebugView

I have been debugging some SharePoint 2007 webparts and have had to resort to TRACE output and the SysInternal DebugView; it is like ASP pages in the 90s all over again!

Anyway had a weird problem that only alternate TRACE.WriteLine commands were appearing in the view. I have not found a reason why or a solution as yet, I suspect a buffer flushing issue, but you can work round it once you know it is happening.

Update : Trace.Autoflush= true is the fix - another user too stupid error!

Running the TFS Best Practice Analyzer and 2005 Team Explorer

If you run the 2008 Power Tools BPA against a TFS 2008 install that has the 2005 Team Explorer also installed on it you will get virtually no reports generated. It runs to completion but the reports are empty.

This is due to some clash between the BPA and the TFS 2005 DLLs (V8.0). Removed the 2005 Team Explorer and it works as expected.

Now you are probably asking why would I have 2005 Team Explorer on a 2008 install? It is because a number of the third party TFS add-ins, such as eScrum, require the 2005 DLLs either to install or to run. As in theory the 2005 and 2008 installs are site side by side so it should not be an issue - but it is for the BPA.

In the case of eScrum the answer is to place the 2005 DLLs in the eScrum web site bin directory (as opposed to the GAC) and all seems to be fine - the BPA works and so does the eScrum web site.

CCNet WebDashboard getting assembly does not allow partially trusted callers exception

Whilst installing a TFS & CCNet demo system I got an exception

System.Security.SecurityException: That assembly does not allow partially trusted callers

when I tried to load the CCNet WebDashboard.

The problem was that default CCNet installer had created the WebDashboard on the default web site as the virtual directory

http://localhost/ccnet

As this was also a TFS server the default web site was a WSS3 server. Bascially the SharePoint did not like (trust) the CCNet virtual directory's DLLs.

The fix I used was to create a new website and point it as the WebDashBoard directory so it could be accessed without effecting the SharePoint e.g.

http://localhost:81

I could also have edited the SharePoint's web.config to trust the CCNet DLLs

TF220066 Error installing TFS

I was installing a Dual Tier Team Foundation Server 2008 at a clients today and got a problem that when installing the Application Tier (AT) I entered the name of the Data Tier server (DT) and it said the server could not be found.

Unlike TFS 2005, 2008 does not require you to to do a separate install on the DT to create the empty DBs, so I assumed it was just a connectivity problem. However there was none to be found, so I checked the detailed TFS install error log and saw I had a TS220066 error that also mentioned SQLRS - I guessed at a reporting services issue.

I turns out, stupidly, I had forgotten install SQL Reporting Services on the AT - after all I have previously posted about following the walk-thru for the install!

Once this was installed all was OK; so if you cannot see the DT during the AT install it may not be the remote connectivity issues the dialog says, check the error for more details.

TFS WebParts in a 64bit SharePoint environment

In my post on using TFS WebParts in Sharepoint I provided a proof of concept set of source to allow work items to be viewed and edited within 32bit SharePoint 2007. However I hit a problem that our live SharePoint is running 64bit and the TFS API is only available for 32bit, so the WebParts  could not be loaded.

To get round this problem I have built a version of the WebParts that move all the 32bit TFS API calls into a separate web service. This allows the web service to be hosted on a 32bit box whilst the WebParts are still run within the 64bit SharePoint environment.

I have used a simple design model in that I just move all the TFS based methods in my previous example to the WebService and passed all the URLs, authentication details and other parameter each time a WebMethod is called. It does the job to show how the system can work, but there are many other options depending on how you want to manage the user IDs the SharePoint users authenticate to TFS as, see my previous posts for a longer discussion of the authentication issues.

In addition to the WebPart setting detailed in the previous post, there is one additional parameter, this is the web service URL e.g.

http://www.domain.com:8091/TFSWrapperWS.asmx 

This should point to wherever you have installed the web service (using standard means of publishing web sites). The web service does not have to be on the TFS server, as this web service only acts as a pass through. Also so there is no need to edit any details in the web service's web.config.

The revised source can be found at in the files section of this blog