Team Foundation Server 2015 RC 2 fixed bugs and known issues

• When you upgrade to TFS 2015 RC 2 from TFS 2010 or a earlier version, the upgrade may take a long time to finish. This is caused by the data in the database. This issue is now fixed.
• When you run the same TFS query in Visual Studio client and in Web Access, you may obtain two different results. After TFS 2015 RC2, the results is the same.
• When you open TFS 2015 RC 2, you can see that there is only one "My Queries" folders, as expected.
• You can set a Build Quality and KeepForever flag on an XAML build when you use Web Access.
• When you check the data warehouse in TFS 2015 RC 2, the data in Codechurn cube is correct, as expected.
• When you uninstall TFS 2015 RC 2 and then reinstall it, the Application Tier Only and Upgrade are disabled on Configuration Center dialog box. This issue is now fixed.
• Assume that you have a file that contains a versioned item property. You change the property between labels. In this situation, when you run the Team Foundation Version Control command compareLabels in TFS 2015 RC 2, the command fails to run. This is a common issue for Team Explorer Everywhere that sets a versioned item property on .exe files. This issue is now fixed.
• We have improved the check-in performance in a query plan in TFS 2015 RC2.
• When you upgrade to TFS 2015 RC 2, the upgrade may fail because of some orphaned properties in Version Control tools. This issue is now fixed.
• During you upgrade to TFS 2015 RC 2, when there is a network error, some data will be lost. This issue is now fixed.
• When any Team Foundation Version Control (TFVC) build definition has a Schedule trigger but no Continuous Integration trigger, all Continuous Integration triggers can now queue builds successfully.
• The tbl_file table is saved in tbl_file_Snapshot in TFS 2015 RC 2.
• When you build ASP.NET 5 projects that use Angular and Gulp, you may experience long path issues on the computer. This issue is now fixed.
• Assume that you have Team Foundation Server and a build controller on your computer. You perform an in place upgrade to Team Foundation Server 2015 RC 2 but do not upgrade the build controller. In this situation, builds will queue but stay in the a running for 0 seconds state. After you apply this update, build controllers that are not upgraded to 2015 RC 2 will be in a stopped state until they are upgraded to 2015 RC 2.

• If you have Visual Studio 2015 RC, you should not install Team Foundation Server 2015 RC 2 on the same system. There is a known licensing issue that invalidates the key of either product. That means you cannot use both in the same computer. As soon as Visual Studio 2015 RTM is available you can install it on a Team Foundation Server 2015 RC 2 system.
• For TFS 2015 RC 2, we introduced the concept of an identity field. A field is considered an identity field if it has any rules on it relating to identities, such as <ValidUser />. This enables us to solve the issues around duplicate display names. Previously, if you had two users with the same name, there was no way to differentiate them since DisplayPart in Constants was just display name. Now that we have identity fields, we store the DisplayPart as display name <email or domain\alias>.
  
  When syncnamechanges=true is set for a field, the Constant ID of the value instead of the actual string value for the field is stored. In the case of syncnamechanges=false, the string value is directly stored on the work item. In the case of identity fields, there is an issue with the Client Object Model. Because the string value is stored, it is returned to the client. This causes the client side rule engine to claim the field is invalid.
  
  To work around this issue, use one of the following methods:
  • Before upgrade, update any templates that have syncnamechanges=false and rules that make it an identity field, change them to syncnamechanges=true. This has to be done before upgrade, since the ability to change the state of syncnamechanges has been removed from Visual Studio 2015.
  • Add an <AllowExistingValue /> rule on any identity field that has syncnamechanges=false. This allows the Client Object Model rule engine to accept the existing value, unblocking customers until we can provide a script that can convert their syncnamechanges=false fields to syncnamechanges=true. It is prescribed for any field that is identity related syncnamechanges=true be set.
• If a Build agent is running a job and crashes, it is possible for the agent to effectively be orphaned to a request that will never complete. The job that should be monitoring for requests which have expired is not installed so agents can get stuck reserved for a job that belongs to a build that has completed. The work around for this is to delete the agent and re-register a new agent with the server.
• If you performs a large push (greater than 4 GB) to a repository, then do another push before the repacker has run / completed (a job scheduled immediately after push), overflow can occur in the packfile index that leads to a corrupt repository.

Restart requirement

Supported architectures

• 32-bit (x86)
• 64-bit (x64) (WOW)
• ARM