Implicit CallBase on internal methods

[johnmog]

If you new up a mock for a class and then call an internal virtual method on the mock, it always calls the base method, even when call base is explicitly set to false or you have called setup on the method.

    public class ClassToTest
    {
        public virtual void PublicMethod()
        {
            throw new Exception("Public");
        }

        internal virtual void InternalMethod()
        {
            throw new Exception("Internal");
        }
    }

    Mock<ClassToTest> mock = new Mock<ClassToTest>();
    Assert.AreEqual(false, mock.CallBase);
    mock.Setup(_ => _.PublicMethod());
    mock.Setup(_ => _.InternalMethod());
    mock.Object.PublicMethod(); // Does not throw because it is setup
    mock.Object.InternalMethod(); // Throws despite being setup

I validated the behaviors after adding:
[assembly:InternalsVisibleTo("DynamicProxyGenAssembly2,PublicKey=...]

The setup and call base both start working after adding this. Upon giving this more thought, there may be nothing to do to prevent the method from being called when CallBase is false without the attribute. But I will let you decide.

Either way, this tripped me up for a while so I would hope that the setup could throw an error when internals visible is not granted.

[ledbutter]

Thank you for opening this issue as I spun my wheels for a while on just such a scenario before stumbling upon this and noticing in my case that the source project had the internals visible to my test project, but not to "DynamicProxyGenAssembly2".

+1

[hungwunfai]

I have the same issue

[kind-serge]

+1
stuck with testing because of this issue, and .Protected().Setup() does not work either

[stakx]

I would hope that the setup could throw an error when internals visible is not granted.

Sounds like a good idea! Well, probably an error would go too far, but a warning of some sort might be helpful. IIRC there's something in DynamicProxy that should enable such a check.

[stakx]

The next version of Moq (>4.7.99) will raise an exception when an attempt is made to set up a method that isn't accessible to DynamicProxy. The exception's message will also contain instructions how to make the member properly accessible (i.e. it'll contain a hint about adding the [assembly: InternalsVisibleTo(...)] bit).