testfx icon indicating copy to clipboard operation
testfx copied to clipboard

Test Explorer fails to show tests. Tests output: "The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)"

Open daiplusplus opened this issue 7 years ago • 100 comments

Description

I cloned a private Git repo on my local machine. The solution comprises of several projects all targeting .NET 4.6.2. I built the solution which pulled-in some NuGet packages, including MSTest.TestAdapter, 1.1.18 and MSTest.TestFramework, 1.1.18. There is a test project in the solution with several [TestClass]/[TestMethod] tests. The solution builds successfully, however the Test Explorer window is empty. On a coworker's machine running VS2015 the Test Explorer is populated correctly.

In the Output window's Test output I see the following:

------ Discover test started ------ The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047) ========== Discover test finished: 0 found (0:00:00.1886778) ==========

Steps to reproduce

I have no specific reproduction steps - it happened spontaneously on my machine. Restarting VS, cleaning the project output and TestResults directory, and closing+reopening the Test Explorer window has no effect.

Expected behavior

The tests in the project should appear in Test Explorer.

Actual behavior

No tests appear in Test Explorer, and an error message in the Output window.

Environment

Please share additional details about the test environment. Operating system, Build version of vstest.console, Package version of MSTest framework and adapter

  • Windows 10 x64 Enterprise, Creators Update
  • Visual Studio 2017 Enterprise, 15.2
  • MSTest package version 1.1.18
  • Projects targeting .NET 4.6.2
  • I have two copies of vstest.console installed:
    • C:\Program Files (x86)\Microsoft Visual Studio 15.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe - 15.0.26228.0 - 142KB
    • C:\Program Files (x86)\Microsoft Visual Studio 15.0\Common7\IDE\Extensions\TestPlatform\vstest.console.exe - 15.0.0.0 - 117KB

daiplusplus avatar Aug 13 '17 12:08 daiplusplus

@jehoel: Sorry you are running into this. Few queries:

  1. Are the test projects targeting x64 architecture? If yes, is Test -> Test Settings -> Default Process Architecture set to x64?
  2. Can you set a system wide environment variable VS_UTE_Diagnostics to 1, restart VS and run through the scenario again please? This will output diagnostic logs in Output -> Tests pane in VS. Please do share that.

Edit by @smadala See following two comments.

https://github.com/Microsoft/testfx/issues/241#issuecomment-375278449 https://github.com/Microsoft/testfx/issues/241#issuecomment-378622443

AbhitejJohn avatar Aug 14 '17 04:08 AbhitejJohn

  1. All projects are configured to build for AnyCPU. The "Prefer 32-bit" checkbox is greyed out. 1.1. I changed "Default process architecture" to "x64" to see what would happen, and after building I see this in the Test Output window:

     ------ Discover test started ------
     Test run will use DLL(s) built for framework Framework45 and platform X64. Following DLL(s) will not be part of run: 
     MyAssembly.exe is built for Framework Framework45 and Platform X86.
      Go to http://go.microsoft.com/fwlink/?LinkID=236877&clcid=0x409 for more details on managing these settings.
     The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)
     ========== Discover test finished: 0 found (0:00:00.2255871) ==========
    

    (MyAssembly.exe is a 4.6.2 AnyCPU project that does have "Prefer 32-bit" checked) (Interesting that it says Framework45 instead of Framework461, or is that irrelevant?)

  2. I opened the VS2017 command-prompt and did this:

     **********************************************************************
     ** Visual Studio 2017 Developer Command Prompt v15.0.26430.16
     ** Copyright (c) 2017 Microsoft Corporation
     **********************************************************************
     C:\Program Files (x86)\Microsoft Visual Studio 15.0>SET VS_UTE_Diagnostics=1
     C:\Program Files (x86)\Microsoft Visual Studio 15.0>devenv
    

    When VS opened and I rebuilt the solution, there was no additional output in the Test Output window, only the same message as before:

     ------ Discover test started ------
     The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)
     ========== Discover test finished: 0 found (0:00:00.19589) ==========
    

daiplusplus avatar Aug 14 '17 10:08 daiplusplus

Thanks @Jehoel.

  1. Yes, Framework45 is irrelevant.
  2. You would need to set it for all applications, run
setx VS_UTE_Diagnostics 1

Looking at your issue again and the fact that this is working in VS2015, I suspect this could be because of a missing assembly(possibly in GAC in VS2015). Could you please turn on fusion logs and look for any assembly load failures? Here is how you could turn them on. You could zip the logs and share them over here as well.

AbhitejJohn avatar Aug 14 '17 12:08 AbhitejJohn

I now see more output in the Test window, it contains data I'd rather not publish publicly - can I message you on Skype-for-Business?

Here's the tail end of the output that seems the most relevant - no obvious errors though:

PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 
PowerShellTestContainerDiscoverer:IsTestFile - 

(etc - including more PowerShellTestContainerDiscoverer:IsTestFile - lines, some of which have valid filenames, others are empty)

PowerShellTestContainerDiscoverer:OnTestContainersChanged - FindPs1Files
test container discoverer executor://powershelltestexecutor/v1, discovered 0 containers
No containers found from 'PowerShellTools.TestAdapter.PowerShellTestContainerDiscoverer' :
test container discoverer executor://nodejstestexecutor/v1, discovered 0 containers
No containers found from 'Microsoft.NodejsTools.TestAdapter.TestContainerDiscoverer' :
test container discoverer executor://orderedtestadapter/v1, discovered 0 containers
No containers found from 'Microsoft.VisualStudio.MSTest.TestWindow.OrderedTestContainerDiscoverer' :
test container discoverer executor://generictestadapter/v1, discovered 0 containers
No containers found from 'Microsoft.VisualStudio.MSTest.TestWindow.GenericTestContainerDiscoverer' :
test container discoverer executor://webtestadapter/v1, discovered 0 containers
No containers found from 'Microsoft.VisualStudio.MSTest.TestWindow.WebTestContainerDiscoverer' :
DiscoveryOperation<DiscoverAllOrRunOnInitializeOperation> FinishedChangedCotainers, changed container count is 7
VirtualReadOnlyTestDataStore.OperationStateChanged State=ChangeDetectionFinished, operationInProgress=False
TestDiscoveryStats.OperationStateChanged State=ChangeDetectionFinished, InProgress=False
Discovering the following containers :
	C:\Git\MyProject\MyProject.CloudService\MyProject.FooWorkerRole\bin\Debug\MyProject.FooWorkerRole.dll
	C:\Git\MyProject\MyProject.Bar\bin\Debug\MyProject.Bar.exe
	C:\Git\MyProject\MyProject.Baz.Packager\bin\Debug\MyProject.Baz.Packager.dll
	C:\Git\MyProject\MyProject.Baz.Tests\bin\Debug\MyProject.Baz.Tests.dll
	C:\Git\MyProject\MyProject.Baz\bin\Debug\MyProject.Baz.dll
	C:\Git\MyProject\MyProject.SharedConfiguration\bin\Debug\MyProject.SharedConfiguration.dll
	C:\Git\MyProject\MyProject.StorageCli\bin\Debug\MyProject.StorageCli.exe
VirtualReadOnlyTestDataStore.OperationStateChanged State=DiscoveryStarting, operationInProgress=False
TestDiscoveryStats.OperationStateChanged State=DiscoveryStarting, InProgress=True
------ Discover test started ------
VirtualReadOnlyTestDataStore.OperationStateChanged State=DiscoveryStarted, operationInProgress=False
TestDiscoveryStats.OperationStateChanged State=DiscoveryStarted, InProgress=True
***    Discover TestCase using 'InMemoryUnitTestWriter' ***
RunSettings Content:
<RunSettings>
  <RunConfiguration>
    <ResultsDirectory>C:\Git\MyProject\TestResults</ResultsDirectory>
    <SolutionDirectory>C:\Git\MyProject\</SolutionDirectory>
    <TargetPlatform>X86</TargetPlatform>
    <TargetFrameworkVersion>Framework45</TargetFrameworkVersion>
  </RunConfiguration>
</RunSettings>
The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)
========== Discover test finished: 0 found (0:00:57.5407445) ==========
VirtualReadOnlyTestDataStore.OperationStateChanged State=OperationSetFinished, operationInProgress=False
TestDiscoveryStats.OperationStateChanged State=OperationSetFinished, InProgress=False
	Provider 'GroupByClassProvider' found 0 groups.
VirtualReadOnlyTestDataStore.OperationStateChanged State=DiscoveryFinished, operationInProgress=False
TestDiscoveryStats.OperationStateChanged State=DiscoveryFinished, InProgress=False
Pausing Queue..., current operation is: no current operation
About to Enqueue operation 'WaitForBuildOperation', hashcode:34282735 
Enqueue operation 'WaitForBuildOperation', hashcode:34282735 
Operation left in the the queue: 1
	'WaitForBuildOperation', hashcode:34282735


Processing Queue .....
Operation Dequeue : 'WaitForBuildOperation'
VirtualReadOnlyTestDataStore.OperationStateChanged State=OperationSetStarted, operationInProgress=False
TestDiscoveryStats.OperationStateChanged State=OperationSetStarted, InProgress=False
Firing BuildCompleted event...
Container Discoverer 'Microsoft.VisualStudio.TestWindow.VsAdapters.VsProjectOutputContainerDiscoverer' has container changes
VirtualReadOnlyTestDataStore.OperationStateChanged State=OperationSetFinished, operationInProgress=False
TestDiscoveryStats.OperationStateChanged State=OperationSetFinished, InProgress=False
test container discoverer executor://vsprojectoutputcontainerdiscoverer/v1, discovered 7 containers
Containers from 'Microsoft.VisualStudio.TestWindow.VsAdapters.VsProjectOutputContainerDiscoverer' :
	C:\Git\MyProject\MyProject.CloudService\MyProject.FooWorkerRole\bin\Debug\MyProject.FooWorkerRole.dll:executor://vsprojectoutputcontainerdiscoverer/v1
	C:\Git\MyProject\MyProject.Bar\bin\Debug\MyProject.Bar.exe:executor://vsprojectoutputcontainerdiscoverer/v1
	C:\Git\MyProject\MyProject.Baz.Packager\bin\Debug\MyProject.Baz.Packager.dll:executor://vsprojectoutputcontainerdiscoverer/v1
	C:\Git\MyProject\MyProject.Baz.Tests\bin\Debug\MyProject.Baz.Tests.dll:executor://vsprojectoutputcontainerdiscoverer/v1
	C:\Git\MyProject\MyProject.Baz\bin\Debug\MyProject.Baz.dll:executor://vsprojectoutputcontainerdiscoverer/v1
	C:\Git\MyProject\MyProject.SharedConfiguration\bin\Debug\MyProject.SharedConfiguration.dll:executor://vsprojectoutputcontainerdiscoverer/v1
	C:\Git\MyProject\MyProject.StorageCli\bin\Debug\MyProject.StorageCli.exe:executor://vsprojectoutputcontainerdiscoverer/v1
Container discoverer 'Microsoft.VisualStudio.TestWindow.VsAdapters.VsProjectOutputContainerDiscoverer' has no containers

daiplusplus avatar Aug 14 '17 17:08 daiplusplus

Thanks @Jehoel. As I suspected, these logs do not seem to be giving us much. Could you turn on fusion logging instead following the instructions above.

Looking at your issue again and the fact that this is working in VS2015, I suspect this could be because of a missing assembly(possibly in GAC in VS2015). Could you please turn on fusion logs and look for any assembly load failures? Here is how you could turn them on. You could zip the logs and share them over here as well

On

can I message you on Skype-for-Business?

Sure, you can send a mail to [email protected] with any other details you might have.

AbhitejJohn avatar Aug 16 '17 06:08 AbhitejJohn

@AbhitejJohn - what was the resolution for this?

Half of my tests are getting ignored in both VS and TFS.

StingyJack avatar Sep 07 '17 12:09 StingyJack

I generated the fusion logs - I had a quick look but I couldn't see any errors.

I do have another test project that works fine and its tests do appear in the Test Explorer window - so I compared the two projects. I noticed they're both .NET Framework 4.6.2 projects, however the working project has a reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework which is being pulled from C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll - whereas the non-working project has a reference to Microsoft.VisualStudio.TestPlatform.TestFramework which is being pulled from (solution root)\packages\MSTest.TestFramework.1.1.18\lib\net45\Microsoft.VisualStudio.TestPlatform.TestFramework.dll.

Indeed, the working project is using a standard Visual Studio Test project which came with its own VS-coupled references, while the non-working project is using the NuGet "MSTest V2" assemblies instead.

So why is MSTest V2 not working all of a sudden?

TL;DR Workaround:

  1. Remove the NuGet package references and project assembly references to Microsoft.VisualStudio.TestPlatform.TestFramework.
  2. Replace them with a reference to your Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll assembly instead, which is located inside your Visual Studio installation directory (Common7\IDE\PublicAssemblies).

daiplusplus avatar Sep 07 '17 23:09 daiplusplus

I've emailed [email protected] with my fusion logs.

daiplusplus avatar Sep 08 '17 00:09 daiplusplus

My email to [email protected] was rejected by the Microsoft e-mail server with this message:

Your message to [email protected] couldn't be delivered.

The group VSADepT only accepts messages from people in its organization or on its allowed senders list, and your email address isn't on the list.

I see that VSADepT is not the same thing as VSTestSup - but I'm not sure if the intended recipients receive it or not - @AbhitejJohn did you get it?

daiplusplus avatar Sep 08 '17 00:09 daiplusplus

TL;DR Workaround:

That may work locally, but won't fly on our CI server. A real proper resolution would be real nice :(

josteink avatar Sep 08 '17 08:09 josteink

I found the reason for the failure on my end.

Basically some of my projects are really old, and have slowly been migrated to newer .NET-versions and test-frameworks.

Turns out that the app.config in my project I had the following section still having around, despite the project being "upgraded" to .NET 4.5.1 and latest MSTest:

  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="4">
        <providerOption name="CompilerVersion" value="v3.5"/>
        <providerOption name="WarnAsError" value="false"/>
      </compiler>
    </compilers>
  </system.codedom>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1" appliesTo="v2.0.50727">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions.Design" publicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Removing these made test-explorer able to discover and run my tests.

josteink avatar Sep 08 '17 08:09 josteink

@jehoel: Yes, Replied. @josteink: Thanks. <providerOption name="CompilerVersion" value="v3.5"/> would probably be the culprit. @StingyJack: I suspect this would be a different issue. Could you please raise a new one with details?

AbhitejJohn avatar Sep 11 '17 09:09 AbhitejJohn

Just want to report that I had the same problems in a newly created project. The app.config used to be empty, but after installing some packages assemblybinding's must have gotten added, which was causing the problem.

The solution was simple - I deleted the whole runtime section and cleared the output folders (bin, obj and TestResults), then it was working again. Tried adding the assemblybindings again and got the same error.

MartinF avatar Sep 21 '17 16:09 MartinF

Just wanted to comment that I too am having the same issue with newly created projects. I'm on:

Microsoft Visual Studio Professional 2017 Version 15.3.4 VisualStudio.15.Release/15.3.4+26730.15 Microsoft .NET Framework Version 4.7.02046

Update: I just took that test project, added the .Net standard library through NuGet and it worked. Strange!

yesitspeter avatar Sep 21 '17 16:09 yesitspeter

@StingyJack: I suspect this would be a different issue. Could you please raise a new one with details?

Not without checking these first =D

Some of these are older projects, but not 3.5 old. Something is also broken badly in VS. where running update-package -reinstall on a solution crashes VS halfway through. This leaves us with app.config files for projects displayed in solution explorer as loose files in a solution folder as well as within the projects. Its also forcibly adding assembly binding redirects that are not necessary (internally built dll, only one version ever released even internally). So I think its app.config related for me too, but want to see if fixing them has any effect.

StingyJack avatar Sep 25 '17 11:09 StingyJack

I tried downgrading both the test adapter and test framework packages to an older version (.13) and still got test skippage. The only app config content is an assembly binding for a non-test assembly (the one mentioned that shouldnt be needed).

Only removing these two nuget packages entirely and setting the reference mentioned seems to have corrected this. However its only going to work right if everyone uses the same VS install path due to the HintPath it uses.

    <Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll</HintPath>
    </Reference>

Removing the package also doesnt seem to have completely removed the csproj file contents. I removed the following error conditions and import manually to avoid future errors.

  <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
    <PropertyGroup>
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
    <Error Condition="!Exists('..\..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props'))" />
    <Error Condition="!Exists('..\..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.targets'))" />
  </Target>
  <Import Project="..\..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.targets" Condition="Exists('..\..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.targets')" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>

@AbhitejJohn - the links on the front page list ways to enable additional diagnostics. Which one should be used for the "Visual Studio Test" build task?

StingyJack avatar Sep 25 '17 18:09 StingyJack

The info for enabling diagnostics would be a nice to have at this point. I pulled all the MSTest2 packages and reverted the references, and got all our tests back. Let me know if you need additional info or examples to either reproduce this defect or make sure any proposed correction will work.

StingyJack avatar Sep 26 '17 14:09 StingyJack

@StingyJack: For the test task setting System.Debug="true" on the definition or passing in a /diag switch as an additional argument should provide you with more logs. You might need to add a task to upload these logs if they aren't already.

Let me know if you need additional info or examples to either reproduce this defect or make sure any proposed correction will work.

Yes, a repro would help. The proposed correction takes one back to the old MSTest framework which is not Cross-Plat and does not support the new features MSTestV2 has.

AbhitejJohn avatar Sep 26 '17 20:09 AbhitejJohn

@Jehoel,@StingyJack can you share a repro please.

pvlakshm avatar Nov 02 '17 09:11 pvlakshm

I will try to pare down something for this, I can't publicly share the projects that had this problem.

StingyJack avatar Nov 02 '17 12:11 StingyJack

@pvlakshm I don't have it on my computer anymore, but @AbhitejJohn will have it in the email I sent him.

daiplusplus avatar Nov 02 '17 18:11 daiplusplus

I ran into this issue as well today. I was able to workaround / fix my specific issue by removing all unnecessary assembly bindings in app.config. After doing this, my tests were discovered.

How did I determine my necessary bindings? I commented them all out and repeated these steps: (1) run my tests, and (2) reintroduced the binding hinted in the test failure. Luckily, I only had to repeat these steps for two bindings and not for all of my bindings (30+). /phew

Hope this helps.

scott-lin avatar Nov 02 '17 22:11 scott-lin

I've got a similar issue I upgraded from 4.6.1 to 4.7.1 of the .net framework now my unit test project can't find and tests, I get the message "given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)" I've tried removing the bindings in the web.config, which did nothing and I've taking a look at some of the logs in fusion but there does not seem to be anything obvious there either. I also tried switching on "setx VS_UTE_Diagnostics 1" but nothing extra came through on the output.

Any suggestions?

Davewarner avatar Nov 10 '17 16:11 Davewarner

@AbhitejJohn @pvlakshm

Repro available at https://github.com/StingyJack/testfx241

StingyJack avatar Nov 12 '17 14:11 StingyJack

@StingyJack I couldn't repro the issue. I have tried this on two machines(my dev machine and fresh lab machine with >= VS 15.5 preview 3). testfx-241-repro Can you try with latest VS version? Is this repro with vstest.console.exe(command line) too? If Yes, Can you share logs(output and /diag) of vstest.console.exe?

@Davewarner If you are using VS >= 15.3, You can enable logs by Tools -> Options -> Test -> Logging -> Logging level -> Diagnostic (VS_UTE_Diagnostics option removed in 15.3). And Please provide repro project to try out our side.

smadala avatar Nov 29 '17 09:11 smadala

This has been present for several versions of vs15. Can you please try a non-preview version? Preferably one that has had 15, 15.1., 15.2., etc.

It does work in correctly in both vstest.console.exe and mstest.exe console on my dev box, but this was missing tests on the TFS server too. I'll check that later today.

StingyJack avatar Nov 29 '17 13:11 StingyJack

Still misses tests on the TFS build server.

Running this project with the 15.5 preview 5 is more interesting, but also holds the same end result. It compiled the first time, and found only one test in UnitTestProject2. I changed the "keep test execution engine running" to unchecked and compiled and was greeted with errors in the errors list about VS not being able to find the adapter package. Trying to open the nuget package manager ui then pops the warning "No projects supported by nuget in this solution". I reenabled the "keep test exec..." option.

image

Closing the solution and reopening it allows it to build again, and this time it discovers and executes all four expected tests.

Closing all that and reopening the solution in Vs 15 Ent, Vs is immediately able to find the tests and can execute them.

Would the toggling of that "Keep execution engine running" have created some necessary setting?

StingyJack avatar Dec 05 '17 13:12 StingyJack

Closing the solution and reopening it allows it to build again, and this time it discovers and executes all four expected tests.

@StingyJack If I understand correct, test are discovering/executing fine with 15.5. "Keep execution engine running" won't have any effect in 15.5 by default. If you are facing Nuget issue always share repro project and raise issue at https://github.com/NuGet/NuGet.Client.

Still misses tests on the TFS build server.

If locally all tests running fine, then possibly adapters not gettings picked up in TFS, you can determine that by comparing logs files. Collect vstest logs following here from TFS and local vstest logs following here

smadala avatar Dec 05 '17 15:12 smadala

I was happily executing my tests on VS 2017 with the update prior to 15.5 yesterday. Upgraded to 15.5 late yesterday. Tried running tests today. No tests found and I'm receiving the error about the invalid codebase. How do I downgrade back to 15.4?

jemiller0 avatar Dec 06 '17 04:12 jemiller0

Commenting out the bindingRedirects in my test project and then regenerating them seems to have fixed the problem for me. For the time being anyway. The following is what I currently have. The commented out ones are what it sued to be. I used Get-Project -Name OleLibraryTest | Add-BindingRedirect to regenerate the binding redirects.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <!--<dependentAssembly>
        <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Reflection" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.InteropServices" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.Extensions" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Text.RegularExpressions" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.EntityFrameworkCore" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.0.1.0" newVersion="2.0.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.EntityFrameworkCore.Relational" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.0.1.0" newVersion="2.0.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="MySqlConnector" publicKeyToken="d33d3e53aa5f8c92" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-0.33.1.0" newVersion="0.33.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Npgsql" publicKeyToken="5d8b90d52f46fda7" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.2.6.0" newVersion="3.2.6.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
      </dependentAssembly>-->
      <dependentAssembly>
        <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.EntityFrameworkCore" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.0.1.0" newVersion="2.0.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.EntityFrameworkCore.Relational" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.0.1.0" newVersion="2.0.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Npgsql" publicKeyToken="5d8b90d52f46fda7" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.2.6.0" newVersion="3.2.6.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="MySqlConnector" publicKeyToken="d33d3e53aa5f8c92" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-0.33.1.0" newVersion="0.33.1.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Apparently, at least in some cases, the problem appears to have something to do with dependent assemblies.

jemiller0 avatar Dec 06 '17 04:12 jemiller0