nunit: RemotingException from TestContext when using TestCaseSource and multiple assemblies

Given multiple test assemblies where at least one assembly has a test method that uses the TestCaseSource attribute, and the method linked to by TestCaseSource makes a call to TestContext.CurrentContext.TestDirectory,

the test fails with a RemotingException

1) Invalid : Second.Tests.UnitTest1.TestMethod1
System.Runtime.Remoting.RemotingException : This remoting proxy has no channel sink which means either the server has no registered server channels that are listening, or this application has no suitable client channel to talk to the server.
   at System.Runtime.Remoting.Proxies.RemotingProxy.InternalInvoke(IMethodCallMessage reqMcmMsg, Boolean useDispatchMessage, Int32 callType)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at NUnit.Framework.Internal.TestExecutionContext.get_CurrentTest()
   at NUnit.Framework.TestContext.get_TestDirectory()
   at Second.Tests.UnitTest1.<MyTestCaseSource>d__0.MoveNext() in D:\dev\Sandbox\NUnitMultipleRemoteException\Second.Tests\UnitTest1.cs:line 14
   at NUnit.Framework.TestCaseSourceAttribute.GetTestCasesFor(IMethodInfo method)

I have created a minimal repro here - https://github.com/flcdrg/NUnit-Issue1824.

If I run a single assembly at a time, I don’t see the problem. It’s only when the test runner spins up multiple agents that it seems to experience this issue.

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 25 (14 by maintainers)

Most upvoted comments

@BlythMeister A counter-argument might be that many developers think that they are in the scope of a test when in the constructor of a TestFixture. To allow for that, we could check the context and return the directory of the calling assembly when no context exists. Of course, if we throw an exception, we won’t get that far.

@jnm2 The Shadow copy problem is easy to avoid. NUnit itself avoids it and I’ve posted code for it before - which I can’t find right now. 😄 Basically, it involves ignoring Assembly.Location and working from Assembly.Codebase instead. Provided the codebase is a //file: you can easily get the true location from which the assembly was loaded. That’s usually what people want, since they have other files stored in the same directory.

CharliePoole on Nov 13, 2017

@CharliePoole that would make sense…is that recent change as I only started getting error when going from 3.7 to 3.9.

I’ll update my test(s) and try again

Thanks!

BlythMeister on Nov 13, 2017

Sorry about not responding previously. Thanks for the fix. We’re running the latest version and not having any problems.

flcdrg on Jul 25, 2017

@nunit/engine-team I don’t think this would have been fixed by https://github.com/nunit/nunit-console/pull/223, but I will take this on when I have a chance in case it’s related.

@flcdrg Minimal repros are amazing. Thank you!

jnm2 on May 29, 2017