xUnit skips tests with "could not find dependent assembly" warning - c#

After updating an assembly, my xUnit tests fail to run.
My project was using System.Web.Http version 5.2.3. I replaced this using Nuget with a fork of System.Web.Http version 5.2.4. Inspecting the reference shows the correct path to the new DLL.
When I run xUnit, it discovers the tests, but gives me the following warning:
[11/04/2018 10:43:30 AM Warning] [xUnit.net 00:00:00.9421698] Skipping: API.IntegrationTests (could not find dependent assembly 'System.Web.Http, Version=5.2.4')
It then skips all tests.
I'm at a loss. Any help is very appreciated.

Related

NUnit3TestExecutor discovered 0 of 1 NUnit test cases using Current Discovery mode, Explicit run

When I run my SpecFlow+NUnit tests from Test Explorer, all tests always run, even if I have selected only some of the tests.
I also see this message which I suspect is related:
NUnit3TestExecutor discovered 0 of 1 NUnit test cases using Current Discovery mode, Explicit run
In addition, after the tests run, they are still marked as "Not run", even if they succeeded.
How can I fix this issue?
I fixed it by upgrading all the nuget packages in the solution to the latest version following advice in https://github.com/nunit/nunit-vs-adapter/issues/125. I don't know why that fixed it, but it did.
After upgrading the nuget packages I got an error:
System.IO.FileLoadException : Could not load file or assembly 'nunit.framework, Version=3.13.1.0, Culture=neutral, PublicKeyToken=2638cd05610744eb' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
This was fixed by following advice at https://github.com/SpecFlowOSS/SpecFlow/issues/2387:

xUnit Test- all test not running on Azure when using yml configuration

I have a .NET application using .NET Framework 4.7 that includes the xUnit unit testing framework.
The application and unit test execute as expected from my local dev environment and from Azure using a .net solution build.
I recently added another build based on a yml file to Azure that is building the same code and executing the same unit tests,
however, the number of unit tests being executed with the yml configuration are vastly different and nearly half of the unit test are not executed when using the yml configuration. The yml file is super simple that is the first place I started my troubleshooting efforts and will be glad to share if needed.
Review of the test results between the solution build versus the yml build indicated the following warning that is only in the yml unit test results:
Warning 5/14/2020 1:46:33 PM [MSTest][Discovery][d:\a\1\s\src\OTEMS\packages\MSTest.TestAdapter.2.1.0\build\netcoreapp1.0\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll] Unable to load types from the test source 'd:\a\1\s\src\OTEMS\packages\MSTest.TestAdapter.2.1.0\build\netcoreapp1.0\Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.dll'. Some or all of the tests in this source may not be discovered.
Error: System.TypeLoadException: Method 'get_DataRow' in type 'Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.TestContextImplementation' from assembly 'Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' does not have an implementation.
Note the \netcoreapp1.0\ in the path. This warning only occurs with the yml variation but the project is NOT a .net core build, and I can't seem to find where this is being referenced or if it is the actual problem.

AppVeyor: Build Failed : Cant locate NUnit assembly

I'm having trouble building these simple tests using NUnit. Project passes the build using MStest, but as soon as I switch to NUnit it fails the build.
The error I'm getting during build process is basically:
Could not resolve this reference. Could not locate the assembly "nunit.framework". Check to make sure the assembly exists on disk. If
this reference is required by your code, you may get compilation
errors.
I have NUnit 3.5 downloaded from NUGET and added the .dll to my references, and still nothing. I also have also made sure the properties of that reference have the copy local property set to true.
Here is my build log URL on AppVeyor (https://ci.appveyor.com/project/ReevMich/traviscitest/build/1.0.26)
This is my appveyor.yml contents if that helps.:
version: 1.0.{build}
branches:
only:
- master
- dev
configuration: Debug
before_build:
- nuget restore
build:
verbosity: minimal
project: FizzBuzz.sln
test:
assemblies:
- '**\*.Test.dll'
artifacts:
- path: '**\*.nupkg'
name: NuGet
Remove packages folder from your repository (it doesn't contain assemblies anyway), so it's always re-created during the build with nuget restore.

MS Fakes loading assembly fails only in MSBuild

I have the following setup:
Solution N1 -> .net 3.5, Ninject 2.2
Solution N2 -> .net 4.5.2, Ninject 3.2
I added a project from Solution N1 to Solution N2 and then generated fakes for the project that uses Ninject 2.2.
In vs, the fakes generation succeeds.
In MsBuild (and in TeamBuild) I get the following error:
C:\Somepath\Fakes\SomeProj.fakes: assembly C:\Somepath\SomeProj.dll failed to load properly Could not resolve assembly 'Ninject, Version=2.2.0.0, Culture=neutral, PublicKeyToken=6b7e450ec5ed63ad'. Are you missing an assembly reference?
So my tests are not working on build, even though I selected vs test runner (not msbuild) for running tests.
Unfortunately I can not update Ninject in Solution N1 for some external reasons.
In production the app works as I have Ninject remapped to 3.2.0.0 and it works.
Any idea how to make fakes either load 3.2.0.0 (without referencing in SomeProj) or just ignore that code? (I tried specifying the stubs and shims that I need explicitly, same error in MsBuild).
So what I did in the end was add the old Ninject to the repo, and then referenced it like so inside .fakes file:
<Compilation>
<Reference Path="RelativeToCsProjFolder\Ninject.dll" FullName="Ninject, Version=2.2.0.0, Culture=neutral, PublicKeyToken=6b7e450ec5ed63ad"/>
</Compilation>
What got me a bit was the relative path syntax in this path.

System.IO.FileLoadException: Could not load file or assembly Log4net

I added an existing project to my solution. When I run all unit tests with MSTest runner, I get the following error on a couple of tests:
Message: Test method soandso threw exception:
System.IO.FileLoadException: Could not load file or assembly 'log4net, Version 1.2.12.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a' or one of it's dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT:0x80131040)
I know others have had the same problem and there is other questions and answers about this topic. But I tried many things, but nothing helped.
The version of log4net we use is 1.2.13.0.
I checked with FUSLOGVW.exe for binding errors. The log4net shows up with the added assembly and some Unknown assembly.
The reference of log4net in the assembly shows version 1.2.13.0 which was added with NuGet. So it is probably a dependent assembly that is causing all this trouble.
I tried changing log4net back to version 1.2.12.0, but I still get the same error message.
When I run all the tests with MSTest testrunner, these errors show up. When I only run the failed tests, they pass. When I run them individually, they also pass.
I tried binding redirection, but I did it for the assembly that is tested not the testing assembly. I did not know how to do that for a test assembly - there is no config.
When I run the tests with Resharper test runner they also pass (but other tests fail). The TFS Build server runs the MSTest-runner, therefore I need to get it working with MSTest.
Does anyone know how I can get this resolved?
The culprit was found. Like I was suspecting, a dependent assembly was referencing log4net 1.2.12.0. The tool used to find out was dotPeek. Luckily we do have the source code for the dependent assembly and we can change it to reference the latest log4net. This solves this issue.
So if anyone has a similar problem, use dotPeek or a similar tool to go through the dependent assemblies to find out what versions of assemblies it is referencing.

Categories