7

I'm attempting to configure TeamCity to run my unit tests using VSTest.console.exe for Visual Studio 2015.

The only options that appear valid for the test runner ( even in the .runsettings file ) are:

<!-- Framework35 | [Framework40] | Framework45 -->

My .runsettings file looks like:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- Configurations that affect the Test Framework -->
  <RunConfiguration>
    <MaxCpuCount>1</MaxCpuCount>
    <!-- Path relative to solution directory -->
    <ResultsDirectory>.\TestResults</ResultsDirectory>

    <!-- [x86] | x64  
      - You can also change it from menu Test, Test Settings, Default Processor Architecture -->
    <TargetPlatform>x86</TargetPlatform>

    <!-- Framework35 | [Framework40] | Framework45 -->
    <TargetFrameworkVersion>Framework45</TargetFrameworkVersion>

    <!-- Path to Test Adapters -->
    <TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>
  </RunConfiguration>
</RunSettings>

When I set it to Framework45, it tells me:

[19:17:33][Step 2/2] VSTest executable: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\VSTest.console.exe
[19:17:33][Step 2/2] Command line params: [[Y:\TeamCity\BuildAgent1\work\f1cf88fd0bf6555\Javelin.Identity.Tests\bin\x64\Integration\Javelin.Identity.Tests.dll] [/Settings:test.runsettings] [/Logger:trx] [/Platform:x86]]
[19:17:33][Step 2/2] Starting: C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.NUnitLauncher.exe #TeamCityImplicit
[19:17:33][Step 2/2] in directory: Y:\TeamCity\BuildAgent1\work\f1cf88fd0bf6555
[19:17:33][Step 2/2] JetBrains dotCover Console Runner 10.0.2. Build 104.0.20151218.125453
[19:17:33][Step 2/2] Copyright (c) 2009-2016 JetBrains s.r.o. All rights reserved.
[19:17:34][Step 2/2] [JetBrains dotCover] Coverage session started [3/1/2016 7:17:34 PM]
[19:17:38][Step 2/2] Microsoft (R) Test Execution Command Line Tool Version 14.0.24720.0
[19:17:38][Step 2/2] Copyright (c) Microsoft Corporation.  All rights reserved.
[19:17:38][Step 2/2] 
[19:17:39][Step 2/2] Starting test execution, please wait...
[19:17:39][Step 2/2] Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run: 
[19:17:39][Step 2/2] Javelin.Identity.Tests.dll is built for Framework None and Platform X64.
[19:17:39][Step 2/2]  Go to http://go.microsoft.com/fwlink/?LinkID=236877&clcid=0x409 for more details on managing these settings.
[19:17:39][Step 2/2] Error: None of the provided test containers match the Platform Architecture and .Net Framework settings for the test run. Platform: X86  .Net Framework: Framework45. Go to http://go.microsoft.com/fwlink/?LinkID=330428 for more details on managing these settings.
[19:17:39][Step 2/2] 

When I set it to Framework46, it tells me:

[Step 2/2] Error: An error occurred while loading the settings. Error: Invalid setting 'RunConfiguration'. Invalid value 'Framework46' specified for 'TargetFrameworkVersion'..

Is this even supposed to work with 4.6.1?

Daniel Corbett
  • 255
  • 2
  • 10
  • I do find that when I run vstest.console.exe with this testrunner from a command prompt, so perhaps issue seems to be how it is run from team city. – Daniel Corbett Mar 02 '16 at 15:45

2 Answers2

5

You can set the value for TargetFrameworkVersion in the .RunSettings file to the following:
.NETFramework,Version=v4.6.1

I know this is misleading because of their documentation in here
I discovered this one by looking at the help command for vstest.console.exe

vstest.console.exe /?

Among others this is shown:

--Framework|/Framework:<Framework Version>
  Target .Net Framework version to be used for test execution.
  Valid values are ".NETFramework,Version=v4.5.1", ".NETCoreApp,Version=v1.0" etc.
  Other supported values are Framework35, Framework40, Framework45 and FrameworkCore10.

And then I tried to use any of these values and it worked. In my case it was .NET 4.5.2

An example of .RunSettings file is like the following:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- Configurations that affect the Test Framework -->
  <RunConfiguration>
    <!-- Path relative to solution directory -->
    <ResultsDirectory>.\TestResults</ResultsDirectory>

    <!-- [x86] | x64  
      - You can also change it from menu Test, Test Settings, Default Processor Architecture -->
    <TargetPlatform>x64</TargetPlatform>

    <!-- Framework35 | [Framework40] | Framework45 -->
    <TargetFrameworkVersion>.NETFramework,Version=v4.5.2</TargetFrameworkVersion>
  </RunConfiguration>

  <!-- Configurations for data collectors -->
  <DataCollectionRunSettings>
    <DataCollectors>


    </DataCollectors>
  </DataCollectionRunSettings>

  <!-- Adapter Specific sections -->

  <!-- MSTest adapter -->
  <MSTest>  
    <MapInconclusiveToFailed>True</MapInconclusiveToFailed>  
    <CaptureTraceOutput>false</CaptureTraceOutput>  
    <DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>  
    <DeploymentEnabled>False</DeploymentEnabled>  
    <AssemblyResolution>  
      <Directory path=".\bin" includeSubDirectories="false"/>  
    </AssemblyResolution>  
  </MSTest>  
</RunSettings>
Michael
  • 649
  • 6
  • 9
  • 3
    Didn't work for me. In VS2017 I get the following error in Tests output window: [7/6/2018 9:48:38 AM Error] Failed to configure settings for runsettings plugin 'VSTest Run Configuration' as it threw following exception: 'An error occurred while loading the settings. Error: Invalid settings 'RunConfiguration'. Invalid value '.NETFramework,Version=v4.6.1' specified for 'TargetFrameworkVersion'..' Please contact the plugin author. – Ashar Jul 06 '18 at 13:51
  • Hopefully with the example file provided you won't have that error anymore – Michael Jul 20 '18 at 12:56
0

This is a confirmed known issue in vstest.console. You can try the workaround proposed in the issue (specify framework through runsettings file, and leave 'Framework' parameter value to default)

Oleg Rybak
  • 1,651
  • 1
  • 14
  • 27
  • Unfortunately, I tried this workaround, and it didn't work when running from TeamCity. I added more details to my question above to reflect that. – Daniel Corbett Mar 02 '16 at 14:45
  • 4
    This is why you should always copy the relevant parts of a link and not post a link-only answer: the MS Connect site is retired, and the answer is now unavailable... – thomasb May 31 '18 at 15:47