All geek questions in one place

TFS2008 migration upgrade to TFS2010

All,

I am currently trying to create a repeating process for upgrading a TFS 2008 installation to new hardware in that Microsoft is causing the migration upgrade, but I am having trouble creating VS 2008 projects on new hardware.

Our TFS 2008 installation consists of two machines; one of which contains SQL databases and the application tier, and the other as a dedicated build server.

The new equipment for our TFS 2010 installation consists of two machines; which hosts SQL databases, application tier, SharePoint, and Reporting Services.

So far, I have been able to successfully repeat the backup of the necessary TFS databases from the original server to the new server and restore them, and then the tfsconfig import command to successfully import and update the databases in the Team Project Collection. The project project team displays correctly and can be used right away. All security settings, shelves, workspaces, etc. Not damaged.

Our problems begin when we start trying to create solutions. Initially, we try to create these solutions without updating them to the VS 2010 format and without changing the target structure of any of the projects.

When creating various projects, the following errors occur:

  • <filename> .resx (x, y): error RG0000: Could not find the type of name. The type name was "System.Collections.Generic.List`1 [[<class>, <assemnbly>, Version = abcd, Culture = neutral, PublicKeyToken = 9557797252b44220]], mscorlib, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089 '. String x, position y. [& L; ProjectFileName>]

  • ResGen: error RG0000: Failed to load assembly reference "<filename> .dll". I got into a FileNotFoundException, which said: "Could not load file or assembly '<filename> .dll' or one of its dependencies. The system cannot find the specified file.". [& L; ProjectFileName>]

  • Various "ambiguous" MSBuild target links 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 on how to fix these problems, including changing the 32-bit support flag in ResGen or forcing the use of 64-bit ResGen and updating projects to VS 2010 format and changing them in the target Framework 4.

Problem 1. can be fixed by changing offensive projects for target platform 4, however this specific project cannot yet be updated due to compatibility issues, and I have not yet found a solution for questions 2. and 3.

We have more than 20 project projects with several branches in each, and therefore (due to the amount of work) to avoid manually changing all projects / solutions (especially since some products cannot be updated to Framework 4 for compatibility reasons, and creating targeted Framework 3.5 projects in Framework 4 MSBuild doesn't look like Microsoft compatibility if we believed).

If anyone has any ideas that might be helpful, please let me know.

Greetings

Anthony

EDIT:

Problem 1 has been noticed by other people and is related to resource files referencing generic custom type lists. As it turned out, this was redundant in our project, so I just deleted them, and this build problem was history.

Problem 2 seems to have completely disappeared on its own, possibly as a result of fixing problem 1.

Problem 3 is related to creating VS2008 workflow projects in MSBuild 4 when they are targeting Framework 3.5. Microsoft, in its infinite wisdom, apparently chose not to solve this problem ( Link to the Connect website ), and there are several ideas for resolving it (link to specific versions of the Framework, changing the build workflow to use MSBuild 3.5), none of which does not work.

Thus, our upgrade to 2010 will be suspended until all products for which we create workflows 3.5 (CRM 4.0 and SharePoint 2007/2010) support Framework 4, or until Microsoft fixes the problem.

EDIT:

Microsoft acknowledged that there was a problem and released the following information regarding the above KB number: http://support.microsoft.com/kb/2023579

+4
source share
2 answers

As pointed out in my comment on my initial post, this problem related to work process inoperability is really resolved by the patch for Microsot.Net Framework 4 Extended, which is described in KB2023579, which has not yet been published (at the time of publication).

This solution was provided by Microsoft using a support call, and therefore I am bound by the conditions of this call, which prevents me from distributing the link to the patch until the official KB article on which I will send the link is available. Unfortunately.

0
source

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

0
source

Source: https://habr.com/ru/post/1312861/

More articles:


All Articles