You can connect a Visual Studio 2008 IDE instance to a TFS 2010 server, as detailed in Martin Hinshelwood’s blog, but I cannot stress enough you have to have VS2008 SP1 installed. If you don’t, you get an error dialog when you enter the URL for the TFS server saying the URL contains invalid characters.
This seems a simple rule, but as I found today it is easy to not realise your PC is not patched. You look in the about dialog for Visual Studio and it says SP1 installed, but the Team Foundation Client has not been. This was because the following installation order was followed:
- Install VS2008
- Patch with SP1
- Install Team Foundation Client
The SP1 needed to be run again to patch the client then all was OK
VS2010 has excellent new features to assist the tester in general, and specifically in the area of manual testing. One of these is the ability to video a manual test run; to get this to work you have to have the Windows Media Encoder 9 installed as well as the VS2010 Test Runner . If you don’t have it installed and try to use the video feature you get a dialog that warns you this component is missing and would you like to either download it or disable video recording feature for this test run.
The problem is the warning dialog has a link that takes to you the Windows Media Encoder 9 homepage. This gives you the option to install either the 32bit or 64bit version. I mistakenly assumed that I needed the version for operating system I have i.e. 64bit as I run 64bit Windows 7. THIS IS WRONG.
VS2010 Test Runner only seems to work if you have to install the 32bit and the hotfix the Test Runner dialog mentions. Once I installed the 32bit video recording of the test worked perfectly.
I have posted in the past about the TFS 2005 and 2008 Process Template eScrum from Microsoft; a template we use internally for a number of Agile projects. Well today it has been removed from the Microsoft download sites.
It was decided a while ago that it would not be updated to support TFS2010 and has been removed to avoid any confusion over whether it is support or not by Microsoft (FYI it was never officially supported anyway as it did not originate inside the TFS team)
So are we at Black Marble going to miss it? Well the main reason we had used it in the past was the web interface that gave a single point for updating the status of work items without the need to enter Visual Studio, it was our project wallboard. With the much enhanced Office integration with TFS2010 I think we are not going to miss eScrum. We can now provide an easy way with Excel or Project for any team member (developer or not) to update their work status and also Excel Services to provide a information radiator showing the overall project status.
If you do need a strict Scrum implementation template for TFS then have a look at Conchango’s Scrum for Team System which is going to be updated to make use of all the new features of TFS2010
To have a good look at TFS2010 I have migrated some existing VS2008 projects to VS2010. This has meant they are now being built using a new TFS 2010 build server. Now I wanted to make sure everyone still knew what was building and what was not, so I updated the configuration on our build wallboard to get the status from both the older 2008 and the new 2010 server – and it did not work. I fiddled around, upgraded the build wallboard to use the TFS2010 assemblies, all to no avail, the application just exited when I tried to get a reference to the build service.
Then I had another think, the Url of the TFS server has changed format in 2010. It used to be http://my2008server:8080 it is now http://my2010server:8080/tfs. I had been leaving off the trailing /tfs, an easy mistake to make. Once this was corrected my old build wallboard worked without a problem, there was no need to use the TFS2010 assemblies in the project.
After I upgraded an ASP.NET Web Application VS2008 solution to VS2010 I found a strange problem. When I build either the whole solution or the test project in the solution the test assembly gets copies to Web Applications bin directory. However if I build the solution from the command line with MSBUILD they are not copied (so MSBUILD behaves as VS2008 used to).
Turns out it is easy to repeat, the process is as follows:
- Open Vs2008 SP1
- Create an empty solution
- Add a C# Class library project (targeted on .NET 3.5)
- Add a C# ASP.NET Web application (targeted on .NET 3.5)
- Add reference from the web application to the class library
- Build the solution, note that we see the class library and web application assemblies are in the web application bin directory
- Add a C# Test project 3.5 (targeted on .NET 3.5)
- Add reference to the Web application project
- Build the solution, note that we still just see the class library and web application assemblies are in the web application bin directory – there is no test assembly
- Exit VS2008 and load VS2010
- Load the solution and allow it to be upgraded. On the dialog about .NET versions say to leave the projects on .NET 3.5.
- Rebuild the solution and note that now in the Web Application bin directory we have the class library, web application and test assemblies
- Do a clean of the solution, note that in the Web Application bin directory the test assembly is not removed.
So why is this a problem? .NET 4.0 is a replacement for previous .NET version not an extension as 3.0 and 3.5. were for 2.0. This means basically that in any given deployment you need to have all 4.0 assemblies or all 2.0, 3.0, 3.5 ones. However, under VS2010 a test project must target .NET 4.0 (to get all the new cool testing features), so the fact at this 4.0 test assembly ends up in a 3.5 based Web Application directory is a problem.
I have no answer to the problem as yet, though I have reported it. At present the workaround is to either
- Delete the test assemblies from the Web Application bin directory. once this is done everything behaves as you would expect.
- Or make sure you only target .NET 4.0, though I suspect this might be an issue for some people developing web applications as it will be a while before we see ISP deploying .NET 4.0
If you apply the TFS2008 SP1 to a system that has been upgraded from TFS 2005, but the WSS was not upgraded from 2.0 to 3.0 you can get a problem that you cannot access the SharePoint portal sites due to WebPart load errors (you get an Event ID: 1000 error in the Windows event logs). This is because the TFS 2008 SP1 installs .NET framework 3.5 SP1 which causes some problems for WSS 2.0. Note this is not usually a problem for new installs of TFS 2008 as these use WSS 3.0 by default, but the upgrade of TFS from 2005 to 2008 does not force the upgrade of WSS 2.0 to 3.0 so sites that upgraded are susceptible.
Most of the blog posts suggest a removal of .NET 3.5 and reinstall of 2.0 with service packs, this is not an option for a TFS 2008 installation. Luckily there is a solution, the .NET framework family update. Once these patches are installed for the historic versions of .NET all seems OK
Thanks to Wes MacDonald for pointing me at this fix, saved me no end of headaches
Whilst upgrading a single server TFS 2005 to a dual server 2008 install I hit a problem. I had installed the new 2005 Data Tier (DT) and patched it without issue. However then I tried to apply the patch VS80-KB19156-v2-x86, the Quiescence GDR patch, on the Application Tier (AT) I got the 29109 error: SQL Reporting Services configuration encountered an unknown problem. A search on the web found this is a common issue usually fixed by repeated retries! This did not work for me.
After much fiddling, I started again and cleaned down both the DT and AT. This time I made one change from the process detailed in the TFS dual server installation walkthrough – I DID NOT patch the SQL 2005 instance of Reporting Services on the AT prior to installing TFS. This time the TFS patches applied OK, I then patched SQL at the end of the installation process to bring it in line with the DT SQL patch level.
This would suggest the problem is that the TFS 2005 patches are checking for something that was set in a default SQL 2005 install but not present in one that is patched to SP3.
Anyway hope my experience saves you some time.
I posted yesterday about problem creating a new team project if you had missing templates on your Sharepoint server. This problem could of course be avoided if you had installed the TFS Sharepoint Extensions onto your Sharepoint server as your are meant to. However, as I have discovered it is not that easy to do if your chosen Sharepoint system has network load balanced front ends.
The problem is that Sharepoint will replicate your MSFAGILE30.STP template between the various servers, but it will not move other TFS artefacts such as the TFSREDIRECT.ASPX in the 12 hive or setting to point to the reporting service instance in the registry. To add these other items you need to install the extensions an then run the TFSConfigwss.exe tool to edit the registry. The problem is the Extensions MSI will not complete if it detects the STP already in place (which as I said will that have been replicated by Sharepoint). The only solution I found was to cheat a bit:
- Run the Extensions MSI until you get the warning dialog it cannot complete
- In c:\program files copy the 'Team Foundation Server 2008 Sharepoint Extensions x64 Power Tool' directory
- Let the MSI finish, it will remove the directory, but you have a copy with the TFSconfigwss.exe tool which is probably the only thing you need.
- Run TFSConfigwss.exe to setup the registry.
Or you could just copy the files you need from your original Sharepoint server where you managed to install the Extensions correctly
Historically we have used the eScrum process template for our TFS team projects. However, with a view to the TFS 2010 future we have decided to moved back to the MSF Agile template. We used eScrum to provide an easy to use web based project dashboard; we now think that we can achieve the same or better in TFS 2010 using Excel’s enhanced links to TFS and Excel Services in Sharepoint.
So when I had to create a new team project today I decided to use the TFS 2008 "MSF for Agile Software Development - v4.2" template, to hopefully ease any upgrade issues. The problem was when I tried to create the team project I got the error TF30227, if I looked in the detailed log I saw:
Event Description: TF30162: Task "SharePointPortal" from Group "Portal" failed
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: TF30272: Template not found on the server
(Note that as is common with TFS the main error reported hides another error code.)
The problem was exactly as the error says, the template was missing on our central Sharepoint farm. We have been through a number of Sharepoint upgrades and relocation of our portal sites. This had meant that the TFS templates had to be reinstalled manually, this was done correctly for the eScrum template but a mistake was made for the MSF Agile one. We had installed the template with the command
Stsadm -o addtemplate -filename MSFAgile30.stp -title VSTS_MSFAgile30
when it should have been
Stsadm -o addtemplate -filename MSFAgile30.stp -title VSTS_MSFAgile
as TFS looks for a template call VSTS_MSFAgile not one called VSTS_MSFAgile30. Once this was correct the new project could be created.
I have been looking at the various install and upgrade stories for the TFS 2010 Beta. I have to say they are very nice compared to the older TFS versions. You now have a SharePoint like model where you install the product then use a separate configuration tool to upgrade or setup the features required. There are plenty of places to verify your setting as you go along to greatly reducing the potential mistakes.
One side effect of this model is that it is vital to get all your prerequisites in place. The lack of these has been the cause of the only upgrade scenario I have tried that has failed. This was on a VPC I used for TFS 2008 demos. This VPC used a differencing VHD using the older 2004 format that had a 16Gb limit and this disk was virtual full. To upgrade to TFS 2010 I needed to upgrade SQL to 2008 and this in turn needed Visual Studio 2008 patched to SP1 which needed over 6Gb free space, which was never going to happen on that VHD. So my upgrade failed, but that said this is not a realistic scenario, who has servers with just 16Gb these days!