I'm on a client site this week upgrading TFS 05 to TFS 08 and unlike my previous installation, this one has not been quite as smooth. 

Server Setup

A brand new shiny server was proived for the update (dual quad core with 4Gb of ram).  Initially we had tried to install on another similar server that had some other software on it for their helpdesk.  Unfortunately, the install of TFS 05 or WSS 2 or both screwed this software and we had to restore the server and leave it alone.  Not good!

Lessons learnt 

1) don't expect any useful support from Symantec - Support guy:  "Sorry but that is not one of our products", Me: "Ahhh, but I downloaded a trial version from your web site!".

2) don't install TFS (05) onto a server running anything that uses SQL Reporting or the default web site or WSS (2 or 3).  I fact, it's way simpler to have a clean server.

Moving

I neglected to check that TFS SP1 was installed on the old server before configuring the new server with SP1 so I had to update the old server then redo the backups.  No biggy, but it meant sitting arond for an hour.

Then the fit hit the shan.  After 3 hours trying to figure out why the restorative move process was giving me stupid TFS errors I realised the TFS 05 installation media I was using was for the Workgroup edition.  Dur!  Luckily, it was a simple matter of removing WSS2 and TFS 05 then running through the process again (for the 4th time) with the correct installation.

At the end of this everything was working apart from SQL Reports - which I ignored as it was late in the day.

I then upgraded TFS 05 to TFS 08 which tool another hour, tested and I was done!

Lessons learnt

1) Make sure the source and target TFS installations are patched to the same levels.  Same goes for WSS.

2) Make sure the installation media is the correct version/edition!

3) Create and save the DB restore scripts the first time you do it - it gets borng very quickly having to redo the restore 4 times using the SQL Management Studio GUI.

SharePoint

Thanks to a useful blog post I felt a lot more comfortable about attempting a SharePoint upgrade.  The customer had not done any customisations to the project portal site so the prescan ran without issue and the upgrade comlpeted without errors.

Lessions learnt

1) An inplace upgrade is ok if the prescan is completely clean and you have experts available to help (or google).

Other Tips

I had made a binder with all the documentation I needed, including the Move instructions from MSDN, the TFS P&P Guide (all 500 pages), the licensing white paper, my upgrade plan - including the steps, servers, logins and other site relevant information - and a DVD with the software I needed in case the client could not find something (next time I'll check the DVD works tough as the TFS 08 iso was corrupt - thankfully the client had this).  I'll leave this binder with the client as a parting gift :)

I'm not quite done yet, I still need to configure some build scripts.. will update this post later.

A couple of weeks ago I upgraded our Team Foundation Server from 2005 to 2008.  This is my story…

I was very nervous about upgrading the server as the installation procedure requires un-installation of the existing TFS2005 version and an install of TFS 2008 over the top.  The source code and work items are very important asset for us and loosing them, even for a day, would cost us a lot of money (and be somewhat embarrassing).  So, I was very careful about the process. 

Preparation

I needed to ensure that I could recover our current TFS installation should the upgrade go pair-shape so I created a Virtual Server image on our main domain with a clean install of TFS 2005.  I then restored the TFS setup to this new server, which had a new name.  Microsoft provide detailed instructions on how to move a TFS install here:  http://msdn.microsoft.com/en-us/library/ms404860(VS.80).aspx. This process also taught me how to do a disaster recovery – a very useful and necessary skill!

The creation of the VM, getting it on the domain, installing TFS, migrating the databases and reconfiguring the server took me the best part of 3 days.  I took my time and followed the instructions precisely.  If I had to do this again it don’t think it would take more than a day.

I also migrated the SharePoint content to the new server.  This is documented in the above MSDN article.

I tested this new install, and while it was slow, it all worked and developers could connect and do work.

The testing highlighted a couple of issues.  I had installed Conchango’s Scrum Template on TFS but it was not being used so I had uninstalled it. Unfortunately it had made some changes to the TfsWarehouse database that did not get removed during uninstall.  The test scrum projects were deleted but I didn’t want to futz with the database directly so the scrum stuff had to stay.

Doing it for real

After all the preparation, the upgrade process was somewhat anti-climatic.  It took an hour and half to uninstall TFS 05 and install TFS 08.  Again, the instructions provided my Microsoft are precise and simple to follow.

I next updated Team Build and Web Access with the latest versions,  Again, this was very simple and painless.

Problems

On the Monday morning following the upgrade I found that the Warehouse cube was not being updated.  In fact, some of the dimensions were empty.  It turned out there was a permissions issue with the analysis services. The error in the event log was :

Some or all identity references could not be translated.

A bit of Googling around quickly solved that one: http://blog.salvoz.com/2008/01/26/TFSWarehouseIssues.aspx

During my test run I had a lot of trouble with the SharePoint Services upgrade.  As we don’t use the project portals very much. I made the decision to stick with WSS2 for now.  Next time one of our SharePoint config guru’s is in town I may get it updated, or we might just switch to using the corporate MOSS platform.

I’ve now also notices that some Team Builds are failing.  It appears that projects using our custom Work Items are having a problem building.  I haven’t had time to investigate this yet, but I don’t expect it will be too hard to solve.

Recommendations

If you need to do any work with TFS read the MSDN documentation first – it’s exhaustive and complete. For any issues or problems Google first then post a message on the MSDN TFS forums – you will almost always get a quick answer from a Microsoft expert, MVP or other similarly brainy person.

Put your hand up if you can afford to lose all your source code – for even a day.   Hmmm, I thought so.  Create a disaster recovery plan and test it.  Yet again, Microsoft provide all the documentation you need for this on MSDN, but here’s what I did:

1. Create a VM with Windows Server installed on it.
2. Add the server to the same domain as your current TFS install.
3. Install TFS and all the same bits you have on your production system.
4. Backup the VM.
5. Now test the DS plan on the VM using the move instructions from MSDN (above).
6. If you update your production server then remember to update and test the DS system again.  In fact, test the DS system regularly - once a year or more often.

In summary I found the upgrade a very pleasant experience, aided greatly by the detailed and copious documentation from the tireless TFS team at Microsoft and the large volume of community blogs and forums.

It never ceases to amaze me how hard it can be to sell good software development practices to business people.  All they see is the dollars or increased delivery times.  As a 20 year veteran(vintage?) programmer, analyst and amateur architect I like to think that I know a little about creating good software and how to do it well.  However, I'm not so good at creating a business case for this.

I'm now working for a company that care about doing things the 'right way', or at least the Intergen way.  We care passionately about professionalism and doing what is right for the customer - even if that means saying no occasionally.  This is an ongoing battle however, we are not perfect at it.  We are still subject to the whims of business requirements and real world financial constraints. 

I'm currently assigned to a customer with a team of about twenty internal and contract developers.  The code base for the current systems is being migrated to an SOA model using .Net 3.0 and some external components from 3rd parties.  The business is driving hard for delivery on critical requirements, some of which are driven by regulatory agencies. 

There are a number of issues with the project that I'm sure are common to a lot of other businesses.  The existing code that I am working on is, shall we say, challenging, very challenging.  It was created rapidly with little care for future requirements or expansion and has been patched by many developers for about three years.  There is little or no documentation.  Teams working on similar projects are separated physically and logically.  There is no real architecture plan that I have seen.  Testing is at the bottom of the cliff.  There is only lip service paid to agile practices.  The list goes on but despite the issues, the team still produces quality solutions that service the business requirements, to a certain degree at least.

As a fan of Team System I am very keen to see this introduced but I understand that it's a big task and may not offer a speedy fix to these issues.  It's also hard to sell.  Why is this? I think there are several reasons:

• It's hard to describe.  Business doesn't want to hear about improved source control, work item tracking and unit testing.  They want to know about reduced cost and increased profits.  Describing how Team System aids in these areas is hard.  The intangible benefits, like improved communication, are hard to estimate because they are very subjective.
• The perception is that it's expensive.  This is clearly crap and I'm sick of people saying that it's expensive.  What is the real cost of a software defect that takes eight passes through QA to be fixed?  What is the cost of a defect in a shared library that stops twenty devs from working for three hours?  What is the cost of not tracking defects at all?  These are things that are easily measured.  A few thousand dollars per developer is NOT expensive.  If you think it is then you are in the wrong business.
• Developers don't want to work in a factory.  We like to be creative and have freedom to work on what we want, when we want and how we want.  The thought of being controlled by a large system and spoon fed tasks to complete on the production line is disturbing.  Some developers take this to extremes and refuse to follow any common best practice such as writing comments, documenting systems or proving their code works. This attitude is not prevalent but it is something I encounter occasionally.  It is very naive and must be stamped out!  If you want to be that free, go work for yourself.  Most businesses demand that you work at work and deliver something occasionally.  Team System helps you focus on the work without dictating how to do it.  You can configure as many or as few rules are you like.

I'm not saying that Team System is the only solution to bad practices, far from it, but it's one solution that I have seen work and feel passionate about.

So, if you've read this far then I'm hoping you agree with me, at least in part.  What can we as developers do to sell good software practices?  Like any expense or investment, it must be justified.  You need to make a case for it.  Show the bottom line.  Record and measure the failures and use these as weapons.  Set good examples by following good practice - unit testing & TDD does not reduce productivity, it increases it. Read and learn.  Talk to your managers - if they don't listen, look for a new job - if they don't care about losing your skills then you are better off somewhere else.  There are plenty of great companies out there and some of them even respect your opinion!

Here's the code for the tasks from my Team Build pressie at Code Camp.  JonesieMSBuildTasks.zip (7.64 KB)

There's 4 custom tasks in the zip.

• CreateVDir: Create a Virtual Directory in IIS.
• ModifyXMLNode: Modify an element or attribute in an XML (.config) file.
• AddListItem: Add an item to a sharepoint list.
• ExecuteSQL: Execute some SQL.
  

If you find any bugs or make some enhancements then please send then to me and I'll incorporate the changes for all.

And here's the references from the slide deck.

TS Home:   http://tinyurl.com/n5zf5
TN_1600:   http://tinyurl.com/mxqpj  The TechNote detailing how to alter you SLN files.
TF Blog:   http://tinyurl.com/ryp52
MSBuild Blog:  http://tinyurl.com/pv9z9
ScottGu:   http://tinyurl.com/syjcw 
Forums:   http://tinyurl.com/n8shm

• Launch of Team System is March 16 in the US.  RTM will follow very shortly after this.  Michael wouldn't give us a date - even off the record - but I'm guessing you can start looking for a download about the end of next week.
• In April (I think) there will be a truck load of training material for TS released on the web site - 150 videos, labs, white papers etc. 
• In June, at TechEd US they will release the timeline for TS 2 and also the way that future version of the individual roles of Team Suite will be release.  Currently all edition are released together but this may change.  There's also some other big announcement scheduled at the same time but again, Michael could not be bribed or threatened into revealing the details of this.
• They are looking at producing new roles such as an edition for DBA's and database designers.
• Michael did a nifty demo of using Workflow Foundation to trigger some Team Build activities.  It's quite trivial to hook into TFS events to fire off a workflow.  I thought this was a great idea and can't wait to put this to use.
• Michael also has a MSN style popup message that fired off when a TFS build event happened.  The code for this will be posted shortly.

Here's a few notes and tips from my TFS Server Upgrade experience.

• Make sure you get the upgrade kit and read the instructions cover to cover before starting. 
• You'll also need the updated install guide.  But be warned, you may not be able to view the contents of this.  See my rant in a previous post.
• The upgrade guide is 43 pages long, but don't panic.  You can ignore some of this.  I have a single server install so I ignored the dual server upgrade instructions.
• Read Rob Caron's blog.  There's a few links there to other peoples upgrade experience.
• During the upgrade you need to create and delete Team Projects.  I found that TFSDeleteProject would not work on my client machine.  It kept telling me it could not find the server.  I suspect this was due to my TFS permissions or something funcky with our domain/AD setup.  I copied TFSDeleteProject to the server and, using remote desktop, logged in using the TFSService account and it then worked just fine.
• You need to uninstall Beta 3 during the upgrade.  I have the Team Test Load Controller on our single server so I uninstalled that first just to be safe.  I didn't have Team Explorer on the TFS server so I didn't need to uninstall this.
• After you install the TFS RC, you need to execute a web service method on http://localhost:8080/services/v1.0/Registration.asmx  and verify that the returned XML is correct.  This seems daft to me.  It should be something that is built into the install.
• To upgrade the build types, you have to run the upgrade tool TFSBuildUpgrade on a machine that has the Team Explorer installed.  I didn't have this installed on my TF Server so I tried to run this on my build server but I got the same error as TFSDeleteProject - it could not see the TFS Server.  So, I installed the Team Explorer on the TF Server and ran the upgrade there without issue.
• You have to install the Team Explorer on client machines. This sounds obvious but when you are working through the upgrade instructions it's not easy to spot when you should do this.  You should do it after you have installed all the servers.  If you try to use Visual Studio with the Beta explorer (like I did) it won't work.

The installation took me about 2.5 hours but I was very careful - this is a production system.  I would expect a full install from scratch (including SQL & Sharepoint Services) would take about the same time - maybe a little longer.  Overall, this was a pretty painless process and I think is more than good enough for a Version 1 product - at least for a single server install.  I'm being deliberatly cautious in my praise here as I have installed TFS a few times already. Someone installing for the first time may not find it as easy as I did.

 

I haven't had much time to play with the client yet, but here's a couple of things I noticed.

• The Security & Permissions dialogs include some more informational tips:   
  
  
  
  This is a nice reminder for people. 
  
• User names are now displayed instead of login names:
  
     
  
• Reports are tidier and much more complete.

<TestDBServer>fred</TestDBServer>
<TestDBName>$(BuildNumber)</TestDBName>
<TestDBCreateConnectionString>
 data source=$(TestDBServer);integrated security=SSPI;Pooling=true
</TestDBCreateConnectionString>

<Message Text="Creating test database " Importance="normal"/>
<ExecuteSQL ConnectionString="$(TestDBCreateConnectionString)"
    Command="create database [$(BuildNumber)]" />

This created an empty database with a name of whatever the BuildNumber is.  Note the [ and ] around the $(BuildNumber). 

Next, I execute the script to create the database objects and populate it with sample data:

<Exec Command="isql.exe -E -S $(TestDBServer) -i $(BuildDirectoryPath)\SUMS3\SUMS3Debug\Sources\Airways.SUMS3\CreateTestDB.SQL -d [$(BuildNumber)]" />

The SQL script is checked in with the solution files, hence the funcky path to it.  I could have had it in the Team Build project folder, but it's more visible in the solution.

So, now my Team Build produces completely isolated instances.  Users can happily compare old versions with the latest and greatest version. 

1. Display a list of Work Items for the project and let users drill down to the details.
2. Let user create new work items.
3. Display a project summary WITHOUT using the icky reporting UI.  This will probably include remaining work, velocity and issues in a composite report.

Windows SharePoint Services (WSS) Joy

1. You would think you need an SDK for doing WSS programming.  When you look at the WSS Site you find a link to download the WSS SDK sure enough but you will also notice the "Sharepoint Products & Technologies SDK" which is a separate download.
2. Both the SDK's are just help files - there is no libraries.  To get Microsoft.SharePoint.dll - the .Net API - you need to download and install the Web Part Templates for Visual Studio.
3. Depending on what you want to do, you probably don't need this either.  You can use the web services directly, which is what I did.
4. You will still need the WSSSDK though as it documents the web service API, CAML and related structures.

MSBuild WSS Task

Viewing the List

1. I execute a Team Build manually.
2. When the project builds successfully, it copies the client and server outputs to a publically visible path.
3. The build configures the web service virtual directory.
4. The build updates the client .config to point to the new web service vdir.
5. The build writes a record to a SQL table.
6. Team build sends me an email alert to tell me the build completed successfully.
7. I manaually edit the log table to release the build and enter a note.
8. The user accesses the launch page and views the build details.
9. The user launches a build for testing via a link on the launch page.
10. I go home happy.

<PropertyGroup>
   ...

  <TestDataUrl>http://blah/SUMSWS $(BuildNumber)/SUMSDataasmx</TestDataUrl>
  <TestSecurityUrl>http://blah/SUMSWS $(BuildNumber)/SUMSSecurity.asmx</TestSecurityUrl>

</PropertyGroup>

<UsingTask TaskName="AirwaysBuild.Tasks.XMLFile.ModifyXMLNode" AssemblyFile="Airways.Build.Tasks.dll"/>

<Target Name="AfterDropBuild">

  ... 

  <!-- update the app.config -->
  <ModifyXMLNode
    Filename="$(ClientDeployDest)\Airways.SUMS.exe.config"
    XPath="/configuration/applicationSettings/Airways.SUMS.Properties.Settings/setting[@name='WSDataURL']/value"
    NewValue="$(TestDataUrl)"
  />
  <ModifyXMLNode
    Filename="$(ClientDeployDest)\Airways.SUMS.exe.config"
    XPath="/configuration/applicationSettings/Airways.SUMS.Properties.Settings/setting[@name='WSSecurityURL']/value"
    NewValue="$(TestSecurityUrl)"
  />
  <ModifyXMLNode
    Filename="$(ClientDeployDest)\Airways.SUMS.exe.config"
    XPath="/configuration/applicationSettings/Airways.SUMS.Properties.Settings/setting[@name='BuildVersion']/value"
    NewValue="$(BuildNumber)"
  />
</Target>

XmlNode node = Document.DocumentElement.SelectSingleNode(XPath);
if (node != null)
{
  node.InnerText = NewValue;
}

  <PropertyGroup>
    <ClientDeploySource>$(DropLocation)\$(BuildNumber)\Debug</ClientDeploySource>
    <ServerDeploySource>$(DropLocation)\$(BuildNumber)\Debug\ PublishedWebsites\SUMSWS</ServerDeploySource>

    <ClientDeployDest>$(DropLocation)\test $(BuildNumber)</ClientDeployDest>
    <ServerDeployDest>$(DropLocation)\test $(BuildNumber)\SUMSWS</ServerDeployDest>
    <ServerLocalPath>D:\devweb\deployment\SUMS3\test $(BuildNumber)\SUMSWS</ServerLocalPath>

  </PropertyGroup>

  <UsingTask TaskName="Airways.Build.Tasks.IIS.CreateVDir" AssemblyFile="Airways.Build.Tasks.dll"/>

  <Target Name="AfterDropBuild">
    <CreateItem Include="$(ClientDeploySource)\*.dll">
      <Output TaskParameter="Include" ItemName="ClientDLLs"/>      
    </CreateItem>
    <CreateItem Include="$(ClientDeploySource)\*.exe">
      <Output TaskParameter="Include" ItemName="ClientEXEs"/>
    </CreateItem>
    <CreateItem Include="$(ClientDeploySource)\*.exe.config">
      <Output TaskParameter="Include" ItemName="ClientCONFIGs"/>
    </CreateItem>
    <CreateItem Include="$(ServerDeploySource)\**\*.*">
      <Output TaskParameter="Include" ItemName="ServiceFiles"/>
    </CreateItem>

    <!-- copy the client filed -->
    <Copy SourceFiles="@(ClientDLLs)" DestinationFolder="$(ClientDeployDest)" />
    <Copy SourceFiles="@(ClientEXEs)" DestinationFolder="$(ClientDeployDest)" />
    <Copy SourceFiles="@(ClientCONFIGs)" DestinationFolder="$(ClientDeployDest)" />

    <!-- copy the web service -->
    <Copy SourceFiles="@(ServiceFiles)" DestinationFiles="@(ServiceFiles->'$(ServerDeployDest)\%(RecursiveDir)%(Filename)%(Extension)')" />
    
    <!-- make the virtual dir -->
    <CreateVDir Server="localhost" Site="BSDTesting" PhysicalPath="$(ServerLocalPath)" VirtualPath="SUMSWS $(BuildNumber)" />

    <!-- create the test db ?? -->

    <!-- update the .config -->

    <!-- update the launcher XML file -->
    
  </Target>

• MSBuild Team Blog
• THE Team System Team
• * Udaya Bhaskar Thummala - Software Design Engineer, Microsoft, India
• * Nagaraju Palla's WebLog - Microsoft
• Waaargh.NET - MSBuild & CC.Net

• * MSDN 
• MSBuild Forum
• MSBuild Wiki
• .NET Solution Build, Deployment, Process & Tools Message Board
• VSTS Rocks - Forums & Blogs - not much on Build Extensibility yet

• Yahoo VSTS Group 

• .NET Solution Build, Deployment, Process & Tools - a kit of 100's of MSBuild tasks
• VS2005 Extensibility Kit (SDK) - include TFS API and 1 example of customising a build.
• MSDN: Overview of MSBuild (3 parts)

• Team System MVP's

• The ToolStrip designer is less than stable.  If a ToolStrip overflows to the drop down menu you can add new ToolStrip items but you cant move them or delete them.
• The WebDev.WebServer STILL drops connections which makes it useless for debugging.  I logged this as a bug a while ago.  I also managed to speak to the chap in Redmond who wrote this (or is at least responsible for it) while I was there for the summit.  Sorry, can't remember his name now, but he knew nothing of the issue then.  It may be just an issue on our systems (I've seen it on 2 machines) or with our project.  Has anyone else seen this problem?
• Visual Studio locks up frequently.  Actually, it's not dead, just not responding.  The Task Manager shows about 50% cpu activity on devenv.exe but I have to kill the process.  I'm not sure but I suspect this might be a Team System Source Control issue.
• Help is very slow to load.
• Visual Studio can be very slow to load.
• I had an issue with a solution yestuday that wouldn't let me open the projects in it or re-add them.  I had to create a new SLN and add the projects back in.  I think Team System Source Control is/was caching an incorrect path so even though I had a proejct file in C:\SomePath and I selected the project to add, it would look in a different path (where the project once was). 

Microsoft has published a case system of our Team System implementation. 

• Source Control is wickedly fast!  Ok, so my database is probably pretty empty but it's at least as fast as Vault - maybe even faster if that is possible.
• Creating a new Team Project is faster - ~30 seconds instead of 2 minutes.
• The Agile process template and process guidance are much improved. 
• The default new tasks for an Agile project - only 14 of them for a new project - include useful details and references to the process guidance (but these are not hyperlinks unfortunately).
• Compiling a project does not check out the project file anymore.
• When I edit a checked in file, focus shifts to somewhere else when it does the check out and I have to click back in the code window.  This may be because I have the tool windows undocked onto my 2nd monitor.  I'll experiment with this and log a bug.
• There's a few new reports with interesting names, eg, "Unplanned Work", "Bugs found without corresponding tests", and "Regressions".
• The Team Build progress & results window is WAY nicer than B2.
• Code Analysis still slows down the build hugely - ~10 seconds without, ~120 seconds with.
• There is a new Task type of Risk for Agile projects.
• Test Controller and Agent setup is confusing - I think it's now part of the Team Suite install because there's nothing in the TFS install that looks relevant.
• You get little pad-locks on the tab pages in VS so you can see if the file is checked in or not.
• Refactor rename still tries to drill into code that it shouldn't. For example, renaming a private variable in a class library searches through web service code that in no way can ever see the var.  It is quicker but could be a lot quicker if it didn't do this.  Another bug to log.
• The command line tools for TFS are simpler and easier to find but there's no project delete tool - maybe this will be in the SDK?
• Despite my problems I think they have got the server install as simple as it can be.  Installing SQL Server is the hardest part really and that take about 5 minutes - not enough time for a game of Spider :{

1. Make sure you have the correct versions of everything - RTM SQL Standard, RTM VS Team Suite, Sharepoint with SP 2 and TFS Beta 3 REFRESH.
2. Read through the TFS Install Guide as thoroughly as you can.
3. Reformat your server, install Windows 2003 Server with SP1, IIS etc as per the TFS Install guide.
4. Make sure your server is joined to the domain and the network configuration is correct (my Compaq DL 380 has dual Nic with separate IP's so I had to create a "Team" using the HP tool and set this as a fixed IP so that Windows Update would work (we block this normally)).
5. Do all the windows updates you can - 18 critical updates for me.
6. Create the 3 required accounts and add them to the machines Administrator group and add your own domain account to this group too (you can remove it later if you have to).
7. Login to the server as TFS Setup.
8. Install SQL, Sharepoint and TFS EXACTLY as the Install Guide says - don't trust your memory, read and follow the instructions a step at a time.

• OU: Our Team System
  • OU: Service Accounts
    • TFSService
    • TFSSetup
    • TFSReports
  • Group: TS Administrators
    • MyLogin
    • MyBossesLogin
    • OurITPeople Group
  • Group: TS Users
    • Group: All Developers Group
  • OU: TS Projects
    • OU: Some Big Project
      • Group: Some Big Project Administrators
        • MyLogin
        • MyBossesLogin
        • etc
      • Group: Some Big Project Contributors
        • UserLogins ...
      • Group: Some Big Project Readers
        • UserLogins ...

I think the source of all the problems with my Team Foundation Server install stem from the fact that I was using Beta 3, not Beta 3 Refresh. I'm very red faced - but in my defence, I must say that the download option from TAP was not that obivous - it is now, but when I downloaded it the only clue was a folder called "vstf.b3.rtm".  Anyways, I'm downloading the correct version now so by this time tommorow it should be working. .. (famous last words?).

On the up side, I'm getting very good at installing SQL Server!

A word of warning.  In VS 05, if you REMOVE a project from a solution, it actually get's deleted from disk and Team System Source Control.  Thank [insert your devine being here] for Undo Pending Changes!

I like IE7, it's clean and fast and seems pretty stable.  HOWEVER, Work Item Tracking in Visual Studio 2005 Team Suite does not like it.  It causes VS to crash.

Luckily it uninstalls nicely and restores IE 6 as it was, so no harm done.

Last week I had a small disaster with the source control in Team System.  I managed to overwrite 3 files and lost about 2 weeks work.  The files has not been checked in correctly since mid June.  This was not a nice thing to happen :{

For some reason known only to - pick your God here - I mucked around with the file attributes on these files and then did a "Get Latest", which of course, overwrote the local versions with the old server versions.  Yes, that was a stupid thing to do!  However, I still haven't a clue why the files where not getting checked in correctly.  It may have something to do with the readonly file attributes being out of sync or something else.

So, a word of warning, don't get too comfortable with the Source Control yet - IT'S A BETA !!!  Go and check now that all your files are being checked in correctly and before doing a Get Latest, backup your local versions.

Roll on beta 3...

Rob Caron has posted that the June CTP of Team System is available for download.

I've got too much on at present to bother with this and we were also asked not to upgrade or patch past Beta 2 as part of some programs we are on with Microsoft.

I'd really like a new cut of Visual Studio though.  Some of the bugs drive me nuts.

I've been having a few problems with File based web projects (probably of my own making) so I switched to using HTTP (IIS) instead.  Unfortunately, this screwed my Team Build.

The solution is to manually edit the SLN file, as per the instructions here:  http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=3968. 

This certainly fixed the immediate problem, now my tests are failing :{  Once I get these passing again I' should hopefully get a published build.  That will be a good achievement for a rainy Friday.

My first Team Build!