After version 2.6.1 Remoting stop working from tests.

[savpek]

I am writing system tests agains legacy api that uses remoting, however after updated Nunit any remote call will fail to:

Errors and Failures:
1) Test Error : EndToEndTests.Smoke.FailingTest
   System.Security.SecurityException : Type System.Runtime.Remoting.ObjRef and t
he types derived from it (such as System.Runtime.Remoting.ObjRef) are not permit
ted to be deserialized at this security level.

Error cannot be reproduced with 2.6.1, 2.6.0.
Error can be reproduced with any version 2.6.2, 2.6.3, 2.6.4, and even 3.0.x.

Tested with Nunit nunit-console.exe from matching binaries, example: when tested 2.6.1 used console.exe of from version 2.6.1. With 2.6.4 used 2.6.4 and so on.

If test project uses 2.6.1 off nunit and runner is 2.6.2+ (2.6.4 for example) test will fail again.

Example code used to create error:

public interface ISomeRemoteObject
{
    string GetSomething();
}

public class SomeRemoteObject : MarshalByRefObject, ISomeRemoteObject
{
    public string GetSomething()
    {
        return "SomeValue";
    }
}

[TestFixture]
public class ExampleTest
{
    [SetUp]
    public void Init()
    {
        TcpChannel channel = new TcpChannel(9999);
        ChannelServices.RegisterChannel(channel, false);
        RemotingConfiguration.RegisterWellKnownServiceType(
           typeof(SomeRemoteObject), "Test",
           WellKnownObjectMode.SingleCall);
    }

    [Test]
    public void FailingTest()
    {
        var target = (ISomeRemoteObject)Activator.GetObject(typeof (ISomeRemoteObject), "tcp://localhost:9999/Test");
        Assert.AreEqual(target.GetSomething(), "SomeValue");
    }
}

[rprouse]

I have confirmed that this is happening in the latest release of NUnit 3.

[rprouse]

The workaround to get this working is to set TypeFilterLevel.Full, the default level is Low which is causing the error you are seeing. See this MSDN article for more information.

The modified version of your example code that works is;

[SetUp]
public void Init()
{
    // Creating a custom formatter for a TcpChannel sink chain.
    var provider = new BinaryServerFormatterSinkProvider();
    provider.TypeFilterLevel = TypeFilterLevel.Full;
    // Creating the IDictionary to set the port on the channel instance.
    IDictionary props = new Hashtable();
    props["port"] = 9999;
    // Pass the properties for the port setting and the server provider in the server chain argument. (Client remains null here.)
    var channel = new TcpChannel(props, null, provider);

    ChannelServices.RegisterChannel(channel, false);
    RemotingConfiguration.RegisterWellKnownServiceType(
        typeof(SomeRemoteObject), "Test",
        WellKnownObjectMode.SingleCall);
}

Since the workaround is fairly simple and arguably more correct, I am going to close this issue as Won't Fix. I would rather not put code into the framework to fix this limited scenario if we can help it. If anyone disagrees, please comment on this issue and we can discuss reopening it.