TFS 2017 test task run fails on VS 2017 build machine if code coverage is enabled

We are running a series of tests on a build machine with VS 2017 Enterprise where we have enabled code coverage in a Visual Studio test task. However, the TFS 2017 console does not have this error:

##[section]Starting: Test Assemblies **\*test*.dll
Preparing task execution handler.
Executing the powershell script: d:\builds\4\_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\1.0.60\VSTest.ps1
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\TestPlatform
Working folder: d:\builds\4\3\s
Executing C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\TestPlatform\vstest.console.exe "d:\builds\4\3\s\Source\u.a.testassembly.dll"  /Settings:"C:\Users\username\AppData\Local\Temp\tmp9CCF.tmp" /EnableCodeCoverage /logger:trx /TestAdapterPath:"d:\builds\4\3\s"
Microsoft (R) Test Execution Command Line Tool Version 15.0.0.0
Copyright (c) Microsoft Corporation.  All rights reserved.

##[error]The test source file "/EnableCodeCoverage" provided was not found.

      

        
        
        
      

    

In Visual Studio 2015, tests ran with code coverage without errors.

We supply the path for the vstest.console.exe file as a custom path.

If I turn off code coverage in the check box for the TFS 2017 Visual Studio Validate task and use a runsettings file that does not have code coverage collectors specified, tests run, but no code coverage information is reported.

I also tried to disable the code coverage checkbox and

/EnableCodeCoverage

      

        
        
        
      

    

specified as a command line parameter for test cases. This provides the same error as above.

I've found a lot of people having code coverage issues in VS 2017, but is this mostly similar to the main .NET project?

Thanks for the help!: -)

UPDATE 1

If I try to run vstest.console.exe through the developer command line, I cannot successfully determine the parameter /EnableCodeCoverage

. It contains the following error message:

Microsoft (R) Test Execution Command Line Tool Version 15.0.0.0
Copyright (c) Microsoft Corporation.  All rights reserved.

The test source file "/EnableCodeCoverage" provided was not found.

      

        
        
        
      

    

This errormessage does not appear if I run the same command without the above switch.

Update 2

If instead I use the Runsettings file where I specify datacollectors, I get a JSON related error:

Cannot deserialize the current JSON object (e.g. {"name":"value"}) 
into type 'System.Collections.ObjectModel.Collection`1 Microsoft.VisualStudio.TestPlatform.ObjectModel.AttachmentSet]' 
because the type requires a JSON array (e.g. [1,2,3]) to deserialize correctly.

      

        
        
        
      

    

If I use the / Diag switch, I get the following stacktrace in the log file:

Stack Trace:
ved Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
ved Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
ved Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
ved Newtonsoft.Json.Linq.JToken.ToObject(Type objectType, JsonSerializer jsonSerializer)
ved Newtonsoft.Json.Linq.JToken.ToObject[T](JsonSerializer jsonSerializer)
ved Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.JsonDataSerializer.DeserializePayload[T](Message message)
ved Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.DataCollection.ProxyDataCollectionManager.<>c__DisplayClass6_0.<AfterTestRunEnd>b__0()
ved Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.DataCollection.ProxyDataCollectionManager.InvokeDataCollectionServiceAction(Action action, ITestMessageEventHandler runEventsHandler)

      

        
        
        
      

    

Update 3

Our build server is a standard Windows 2012 server. We were able to install VS 2017 without any errors except for installing the Windows SDK payload. We had to manually install the Windows SDK for Windows 8 after the Windows SDK payload included in VS 2017 Enterprise was not installed on the Windows 2012 server.

I just noticed that Windows Server 2012 is not included in the list of supported operating systems for VS 2017? ...

Update 4

Verbose output from vstest.console.exe /? when running from VS 2017 developer command line:

Microsoft (R) Test Execution Command Line Tool Version 15.0.0.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Usage: vstest.console.exe [Arguments] [Options] [[--] <args>...]]
Description: Runs tests from the specified files.

      

        
        
        
      

    

Then it lists all the arguments.

/EnableCodeCoverage

      

        
        
        
      

    

not found anywhere. The Developer Command Prompt is opened from a shortcut in the Start Menu.

I tried to run a test suite where datacollector was defined in the .runsettings file instead of using / enablecodecoverage, but this results in the JSON error mentioned above.

Update 5

After updating our TFS on-premise upgrade to 2017 1, we can successfully run our unit tests and get code coverage.

However, we are using SonarQube and apparently at this time of writing the SonarQube scanner presented in Marketplace Extension v. 3.0.0 incorrectly finds the Code Coverage Report due to registry key changes made in VS 2017.

A bug report was posted by SonarQube for this issue.

You can work around this limitation by manually creating a registry value named "ShellFolder" in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0

      

        
        
        
      

    

The string value "ShellFolder" should be:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise

      

        
        
        
      

    

I left the above information here in case anyone else is looking for similar issues we had.