2

TFS2013 update 5, with VS2015 Enterprise update 3 on the dev PC and also the build server (per What is required for doing Unit Tests on a Build Server?).

Project is a standard MVC5 framework with next to no modifications made as of yet. The project compiles but there are 2 major issues.

The first issue:

C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets (1697): Found conflicts between different versions of the same dependent assembly. In Visual Studio, double-click this warning (or select it and press Enter) to fix the conflicts; otherwise, add the following binding redirects to the "runtime" node in the application configuration file: 

This is followed by a series of proposed xml edits for the <runtime> node like this one:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" culture="neutral" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
    </dependentAssembly>
</assemblyBinding>

The other 3 suggestions aren't repeated here because they're basically the same thing. They address respectively Microsoft.Owin, WebGrease and Newtonsoft.Json. But this is confusing because when I check the <runtime> node in web.config, the precise xml elements recommended in the warning message are already in web.config for all 4 items. Plus, the warning speaks about double-clicking or selecting it, but I can do neither.

The second issue:

TF900547: The directory containing the assemblies for the Visual Studio Test Runner is not valid 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow'.

I checked on the build server the location specified, and sure enough the folder tree requested doesn't exist, the tree stops at (x86)\Microsoft Visual Studio 12.0\Common7\IDE\. I checked under (x86)\Microsoft Visual Studio 14.0 and (x86)\Microsoft Visual Studio 14.0\Common7\IDE\\CommonExtensions\Microsoft\TestWindow exists and there's a significant installation present in this entire location.

I also looked at VS2015 build with TFS2013 which suggests a specific MSBuild parameter. Given the path issues above, it seems to make sense, but before I try it, I wanted to get confirmation it makes sense for my set of issues and that the particular parameter would be correct. Plus, would that MSBuild parameter address the conflicts mentioned in the first issue?

Finally, in researching all this, I began to see how massive the build server configuration can be. It's a little intimidating. I would appreciate references or books that I could begin to study to become better educated for this process.

Update: Following the simple MSBuild argument /tv:14.0 from TFS 2013 building .NET 4.6 / C# 6.0, the first issue was resolved. The build now finds the proper assemblies.

Still looking to solve the 2nd issue regarding Test Runner, but some of the posts I'm reading are suggesting this particular VS/TFS combo is unusual. It may be that both VS2015 and VS2013 are required on the build server, VS2013 being required for the testing. Will report back.

Alan
  • 1,587
  • 3
  • 23
  • 43

2 Answers2

2

The solution for the second issue is installing Visual Studio 2013 or the Agents for Microsoft Visual Studio 2013 if you want to continue to use the Visual Studio Test Runner.

Cause there is no way to set the tool version or tool path for "Run VS Test Runner" activity, installing VS 2013 should be the only way to get rid of this error.


This is due to Test Agent 2015 no longer needed a Test Controller, as the agent orchestration now is managed by the server (TFS2015 or VSTS).

If you need your test agent or test controller to work with TFS 2013, use Agents for Microsoft Visual Studio 2013 Update 5 and configure the test controller.

More details please take a look at this tutorial: Install and configure test agents

As for the build sever configuration, you'd better make sure the build agent(build server) environment the same as your local environment, this will highly reduce tfs build issues.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • 1
    I was just coming to SO to post what I suspected and here you confirmed it. I installed VS2013 alongside VS2015 on the build server and presto everything runs just fine. Looking forward to upgrading as soon as I get the chance. Even though I seemed to have solved the problem, I appreciate the confirmation that my solution was correct and not some one-off. Just to confirm, when we say the `same environment`, exactly what details are we referring to? – Alan Jul 10 '17 at 14:15
  • Thanks @Alan, always better when you fix it yourself; as you understand how it works!:) the enviroment usually means IDE, such as VS version, test agent version, .NET Framework. There is a host agent in Team Sevices for you reference, not need to have so much things on your own agent, just a list of which should be installed on a build agent. https://www.visualstudio.com/en-us/docs/build/concepts/agents/hosted – PatrickLu-MSFT Jul 10 '17 at 16:29
1

I'd recommend looking into visual studio online or upgrading to the latest TFS release (2017) if at all possible.

The most recent changes to TFS and build configuration are far superior to what was previously offered. Gone are the days of XAML and workflow. The new interface is really slick and the release management tools they offer are very good.

As far as build agent configuration, my recommendation would be - set it up basically as a clone of your development machine: i.e. have the same tools you use on your development environment installed on the build agent.

Microsoft's Continuous Integration and Deployment and other associated pages contain a TON of good material and should hopefully answer some of your questions

Jeff Woodard
  • 647
  • 8
  • 15
  • 1
    here's a link to the VS/TFS 2013 documentation for the above. The newer stuff has a bit more polish, but this may be more relevant to what you're doing if you're locked into 2013. https://msdn.microsoft.com/library/ms181709%28v=vs.120%29.aspx – Jeff Woodard Jul 10 '17 at 05:37
  • 1
    I actually am planning to upgrade to the latest TFS/VS combo, it's just that I'm in the middle of a project right now on this specific system and wanted to be able to finish it out before upgrading. Those links are great. Even though I posted the question, I continued to research it and did hit those links at some point, but it's that you documented them. – Alan Jul 10 '17 at 14:05