search

nunit / nunit3-vs-adapter

NUnit 3.0 Visual Studio test adapter for use under VS 2012 or later
https://nunit.org
MIT License
205 stars 106 forks source link

Could not load type 'System.Runtime.Remoting.Channels.IChannel' #842

Closed Giorgi closed 3 years ago

Giorgi commented 3 years ago

I get this error when I run dotnet test MyTestProject.csproj Tests run fine from Visual Studio.

An exception occurred while invoking executor 'executor://nunit3testexecutor/': Could not load type 'System.Runtime.Remoting.Channels.IChannel' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

NUnit Version="3.13.1" NUnit3TestAdapter Version="3.17.0"

dotnet --version 5.0.201

Tests project targets netcoreapp3.1. Didn't work with net5.0 either.

OsirisTerje commented 3 years ago

@Giorgi This doesn't seem familiar at all. I think we need a small repro project for this. Can you provide that?

Giorgi commented 3 years ago

@OsirisTerje Invited you to the private repo.

OsirisTerje commented 3 years ago

There are 34 tests in the repo sln, 29 are passed, and 5 are skipped due to Ignore attribute. I don't see any errors, not in VS and not with dotnet test.

Giorgi commented 3 years ago

This is the output when I try to run with dotnet test:

image

mikkelbu commented 3 years ago

Searching for this on the net gives a couple of cases where cleaning up caches solved the problem, see e.g. https://github.com/microsoft/vstest/issues/840#issuecomment-427475391 and the following comment.

OsirisTerje commented 3 years ago

It seems your project has been converted from legacy csproj format to SDK format. I do notice at the top of the tests.csproj two import statements, they are no longer needed with packagereference. They will have no effect on a clean clone like I have here, but perhaps you have something down in that path? Both of those can be deleted though. (A bit surprised I don't get any warnings about those files not found, but....). Can you delete your packages folder and see what happens ?

You could also try a clean clone.

Giorgi commented 3 years ago

I deleted the packages folder, deleted all bin/obj folders in the solution, removed the extra imports and it now works without any issues. Thanks!

nloding commented 3 years ago

@OsirisTerje or @Giorgi - have either of you encountered this again? I have it occurring on my project now, but there are no extra imports in the csproj, and I've deleted packages/bin/obj/etc. and it recurs. It's also happening on our CI system, so it's not limited to just my local environment.

Unfortunately it's a proprietary codebase, so I don't think I can get you access to it. What else could I provide that might be helpful?

Update: it starts with version 3.16.0. The project is currently on 3.15.1 and works, but when we upgrade beyond that we get this same error. The release don't know have anything particularly suspect other than dropping .NET Core 1.x support, and we are on 2.x and targeting netstandard20.

OsirisTerje commented 3 years ago

@nloding No, has not had any other reports like this. We only need a small repro, so if you was able to create a small project where you mimick some of what you do, and see if that fails too, then we have something to look at.

Since you're on net core 2, that means you have the new SDK format, so when you talk about packages folder - that means the global one, right ?

Locally also delete the .vs folder, but since this also happens on azure devops (?) CI build, then you don't have anything lingering there.

The best approach is to get a repro for this.

nloding commented 3 years ago

@OsirisTerje yes, I ran dotnet clean and dotnet nuget locals... (whatever that full clean command is!), deleted ~/.nuget/packages. I am not using Visual Studio, but rather VS Code on macOS, and we are using the dotnet test command for test execution. I left out those details, which would have been helpful. The error is a .NET Framework/Windows error, I believe.

The issue starts with 3.16.0. 3.15.1 works just fine! I'll see if I can recreate this in a repo now that I know more about what exactly is happening.

petertiedemann commented 3 years ago

I am also seeing this when running tests on Github Actions (on Alpine). In our case we publish our tests and run them in another job.

I am also trying to figure out what is going on, and see if I can understand why its failing, especially because it is not failing for all tests.

    <NUnitVersion>3.13.2</NUnitVersion>
    <NUnitTestAdapterVersion>4.1.0</NUnitTestAdapterVersion>
    <TestSdkVersion>17.0.0</TestSdkVersion>
petertiedemann commented 3 years ago

The test project I am trying to run is .net 6.0, and as far as I can see, System.Runtime.Remoting.Channels.IChannel is a .NET Framework thing, not available any longer.

If I go to the test adapter ~/.nuget/packages/nunit3testadapter/4.1.0/build/netcoreapp2.1 and copy the content into the folder containing my published test project, then it works. I wonder if somehow the wrong assemblies are being copied, especially because I have also been having problems with https://docs.microsoft.com/en-us/dotnet/core/compatibility/sdk/6.0/duplicate-files-in-output.

Many of my test projects (targeting .net 461 and net60) reference another project that also references Nunit and uses .net standard 2.0.

petertiedemann commented 3 years ago

@nloding @OsirisTerje I think I figured out how this happens (at least in my case). My test project has a dependency on a netstandard 2.0 test helper project while itself targeting net461 and net60. The test helper has a reference to the test adapter due to inheriting from an msbuild property file for test projects. When doing dotnet restore, this leads the adapter to be restored using .net framework instead of .net core.

pmaytak commented 2 years ago

I also got the same error with similar project structure as described above. A fix that worked for me was to add an explicit reference to the test adapter package in my top level project.

bgavrilMS commented 2 years ago

I also got the same error with similar project structure as described above. A fix that worked for me was to add an explicit reference to the test adapter package in my top level project.

Do you mean to add a reference to NUnit test adapter explicitly?

OsirisTerje commented 2 years ago

All test projects should have explicit package references to the adapter, and not rely on any test library projects to add those. I think that is what caused the issues from the reporter.

bgavrilMS commented 2 years ago

@OsirisTerje - interestingly enough, I am not using Nunit for this particular project (mostly out of inertia, we use nunit for new projects). However, the Azure DevOps build, which calls vstsest.exe, is failing with the exception above. Anyway, @pmaytak's suggestion has fixed it.

jchesshirAspire commented 3 months ago

I found that I was referencing both NUnitTestAdapter 2.3.0 and NUnit3TestAdapter 4.6.0. When I removed NUnitTestAdapter from my test project, the error went away.