Home/ Questions/Q 1047859
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T16:22:01+00:00

All, I’m currently in the process of attempting to create a repeatable process for

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0