4

All,

I'm currently in the process of attempting to create a repeatable process for the upgrade of a TFS 2008 installation to new hardware in what Microsoft call a migration upgrade, but am experiencing issues when building the VS 2008 projects on the new hardware.

Our TFS 2008 installation consists of two machines; one which houses the SQL databases and Application Tier, and the other which acts as a dedicated Build Server.

The new hardware for our TFS 2010 installation consists of two machines; one which houses the SQL databases, Application Tier, SharePoint and the Reporting Services.

So far, I have managed to successfully repeat the backup of the necessary TFS databases from the original server to the new server and restore them, followed by the 'tfsconfig import' command to successfully import and upgrade the databases to a Team Project Collection. The Team Project Collection appears correctly, and it is immediately usable. All security settings, shelvesets, workspaces etc. are intact.

Our issues start when we begin trying to build solutions. We are initially trying to build these solutions without upgrading them to the VS 2010 format, nor modifying the target Framework of any of the projects.

We get the following errors when various projects build:

  1. < filename>.resx(x,y): error RG0000: Could not find a type for a name. The type name was 'System.Collections.Generic.List`1[[< class>, < assemnbly>, Version=a.b.c.d, Culture=neutral, PublicKeyToken=9557797252b44220]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Line x, position y. [< projectfilename>]

  2. ResGen : error RG0000: Could not load referenced assembly "< filename>.dll". Caught a FileNotFoundException saying "Could not load file or assembly '< filename>.dll' or one of its dependencies. The system cannot find the file specified.". [< projectfilename>]

  3. Various 'ambiguous' MSBuild target references when compiling workflow-related projects:

    C:\Program Files (x86)\MSBuild\Microsoft\Windows Workflow Foundation\v3.5\Workflow.VisualBasic.Targets (153): 'GeneratedCodeAttribute' is ambiguous in the namespace 'System.CodeDom.Compiler'.

There are various suggestions about how to eliminate these issues, including modifying the 32-bit support flag on ResGen, or forcing the use of the 64-bit ResGen, and upgrading projects to VS 2010 format and changing them to target Framework 4.

Issue 1. can be fixed by changing the offending projects to target Framework 4, however this particular project cannot be upgraded yet due to compatibility issues, and I have not yet found a solution for issues 2. & 3.

We have upwards of 20 Team Projects, with multiple branches in each, and would therefore (due to the amount of work involved) like to avoid manually changing all projects/solutions (especially as some products cannot be upgraded to Framework 4 yet for compatibility reasons, and building Framework 3.5 targeted projects in Framework 4 MSBuild does not appear to be as compatible as Microsoft would have us believe).

If anybody has any ideas which may prove helpful, then please let me know.

Cheers,

Antony

EDIT:

Issue 1 has been seen by other people, and relates to resource files referencing generic lists of a custom type. As it turns out, these were superfluous in our project, so I simply removed them, and that build issue was history.

Issue 2 seems to have dissappeared all by itself, possibly as a result of fixing issue 1.

Issue 3 relates to building VS2008 Workflow projects in MSBuild 4, when they target Framework 3.5. Microsoft, in their infinite wisdom, have apparently chosen to not address this issue (Link to Connect site), and there are several ideas to fix it (referencing specific versions of the Framework, changing the build workflow to use MSBuild 3.5), none of which work.

So our upgrade to 2010 is on hold it would seem, until either the products for which we build the 3.5 workflows (CRM 4.0 and SharePoint 2007/2010) support Framework 4, or until Microsoft fix the issue.

EDIT:

Microsoft have admitted that there is an issue, and have released the following information relating to the above KB number: http://support.microsoft.com/kb/2023579

Jonathan Nixon
  • 4,940
  • 5
  • 39
  • 53
Antony Gibbs
  • 3,300
  • 1
  • 17
  • 12
  • Have you installed VS2008 on your build server? – MrHinsh - Martin Hinshelwood Aug 17 '10 at 08:29
  • I can't tell from your question whether you upgraded your Build server to the TFS 2010 Build server. Has it been upgraded? Also, which server is your Build Controller installed on? Build Controller is a new concept in TFS 2010. Read more here: http://msdn.microsoft.com/en-us/library/dd793166.aspx. I've recently upgraded from TFS2008 to TFS2010. I'm using the new Build Agents compiling .NET3.5 code (with MSBuild4) without any issues. – LordHits Aug 18 '10 at 21:23
  • Thanks MrHinsh and LordHits for your comments. Both the TFS and Build servers are full brand spanking new installs, and yes, VS2008 has been installed on the Build server. The installation is not in question, only the behaviour of MSBuild 4.0. I have been in contact with Microsoft about the remaining issue, namely the building of VS2008 projects which are Workflow related, when they target Framework 3.5, and this is a known issue (for which we have been given access to an as yet unreleased hotfix (KB2023579) which we are in the process of testing. I will update you when we know more. – Antony Gibbs Aug 23 '10 at 13:08

2 Answers2

0

As stated in my commented addition on my original post, this issue relating to the workflows not building is indeed resolved by a patch for the Microsot .Net Framework 4 Extended, which is outlined in KB2023579, which has not yet been made public (at the time of this post).

This solution was provided by Microsoft through a support call, and as such I am bound by the terms and conditions of that call, which prevent me from distributing a link to the patch until the official KB article is made available, at which point I will post the link. Sorry.

Antony Gibbs
  • 3,300
  • 1
  • 17
  • 12
0

Hotfix that worked for us: http://support.microsoft.com/kb/2249629

riezebosch
  • 1,950
  • 16
  • 29
  • Hehe, that's the new Hotfix for the same problem that superceeds the one I mentioned! You can even find a reference to our Hotfix later on in the article! :) – Antony Gibbs Jan 24 '11 at 08:20
  • Still not publicly available though, and the work-around is no help. We'll have to wait for SP1 of .Net 4.0 for this to be fixed properly. – Antony Gibbs Feb 14 '11 at 15:46