4

I have some problems with app.config file in unit tests. It seems that it is ignored by vstest.console.exe. When I run my unit test using MStest, there is no problem with app configuration file.

Configuration file has to resolve some assembly issues (Redirecting Assembly Versions). Here is the content of this file:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="RhinoCommon"
          publicKeyToken="552281e97c755530"
          culture="neutral" />
        <bindingRedirect oldVersion="5.1.30000.4" newVersion="5.1.30000.14"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

When I move this code to machine.config, my unit tests are successfully redirected to use another version of assembly. But this way to solve my assembly issue is unsuitable. The unit test project has to be run on build server, and it is necessary to solve this problem on app level.

In the Internet there are no information about such kind of issue. Based on this answer vstest.console.exe with /EnableCodeCoverage just "hangs"... how debug, and how to fix? the app configuration can be added to vstest.executionengine.config (because this is the exe actually running), but it doesn't work for me, and as I said before this issue should be solved on app level.

With MStest.exe there are no problems with app.config, but it is unsuitable in my situation.

Has anybody seen such issue? Any help would be appreciated.

Community
  • 1
  • 1
Valeria Klimenko
  • 89
  • 8

1 Answers1

1

By adding a legacymode.runsettings file containing:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <MSTest>
    <ForcedLegacyMode>true</ForcedLegacyMode>
  </MSTest>
</RunSettings>

You'll force Mstest to run in legacy mode, but it will also return the old behavior of the assembly loading and picking up the settings from the app.config of the test project.

You can configure legacy mode for your build server as well by specifying the .runsettings path in your source control repository in your Build Definition:

Setting a .runsettings file in your Build definition

Image source

jessehouwing
  • 96,701
  • 20
  • 235
  • 310
  • Thanks a lot. I will check this solution. – Valeria Klimenko Jul 25 '15 at 15:04
  • When I specified settings for MStest adapter, my test were executed by mstest.exe, that I tried to avoid. Because using the MStest as test executor cause problem with loading c++ dll. For running tests some c++ dlls have to be near the test assembly. After I deployed this dll into deployment folder, all test failed with exception System.DllNotFoundException: Unable to load DLL 'rhcommon_c': Invalid access to memory location. (Exception from HRESULT: 0x800703E6). Such a problem appears only when used MStest. And it seems to be very complicated to solve it.. Maybe you have any ideas? – Valeria Klimenko Jul 26 '15 at 10:59
  • That's why I prefer to use vstest.console.exe. Issue with application config could be solved at least by moving all configurations to machine.config.. – Valeria Klimenko Jul 26 '15 at 11:07
  • The last things would be solved by setting the c++ libraries as content items for the test assemblies and adding the `[DeploymentItem("clibrary.dll")]` attribute on the test method or class requiring the item. I'd expect the new test runner to have the exact same issue, as under the hood it still runs the same mstest infrastructure. Or could it be that these libraries are platform (x86\x64)dependent and require a specific platform version of mstest? – jessehouwing Jul 26 '15 at 11:56