Mocking Interfaces

[kapdave]

My apologies if I missed an update or have done something wrong in my code. I have updated my moq version and it seems as though I can no longer mock an interface without receiving a System.TypeLoadException? Any help with this issue? The following is a simple snippet of code that is generating the error:

using Moq;
namespace ConsoleApplication4 {
    class Program {
        static void Main(string[] args) {

            //Mock<ICrapGoat> asdf = new Mock<ICrapGoat>(); // <-- Throws System.TypeLoadException
            Mock<CrapGoat> asdf = new Mock<CrapGoat>(); // <-- Need to use concrete instance
            var asdfsdfvcsdafr = asdf.Object;
        }
    }

    public interface ICrapGoat {}
    public class CrapGoat : ICrapGoat {}
}

[kzu]

I've hidden the release from NuGet while we investigate. Thanks for reporting it so quickly!

We'll keep this issue updated. I've referenced the PR that seems to be one causing this.

[pimterry]

Hmm. Yes, I can reproduce this too, although it doesn't make much sense.

First up, the easy solution for us is to just make InterfaceProxy public here, although I'd rather not, if possible.

Quite a bit of the internet meanwhile seems to suggest that this happens in other places when people don't realise that they're implicitly creating new assemblies, I think, which would suggest we'd just need to add the new assembly that we're creating somewhere to our InternalsVisibleTo config. I can't see anything anywhere that would give any more detail on that though, and I've spent a little while looking for the sort of obvious issues that might mess this up. Any more ideas on why this might be happening here @kzu? Nothing obvious jumps out to me.

For now, I think I'd suggest that for now we make InterfaceProxy public (and mark it as deprecated to avoid people depending on it), then release a working version with that to get the current release out. Once that's out the way we can then try and spend further time to work out what the issue is and make it internal again in future, to tidy this up a bit, but at least it's not a release-blocking problem at that point. Sound reasonable?

[kzu]

How about making it public with EditorBrowsable.Never?

/kzu from mobile
On Feb 20, 2014 7:15 PM, "Tim Perry" notifications@github.com wrote:

Hmm. Yes, I can reproduce this too, although it doesn't make much sense.

First up, the easy solution for us is to just make InterfaceProxy public
here, although I'd rather not, if possible.

Quite a bit of the internet meanwhile seems to suggest that this happens
in other places when people don't realise that they're implicitly creating
new assemblies, I think, which would suggest we'd just need to add the new
assembly that we're creating somewhere to our InternalsVisibleTo config. I
can't see anything anywhere that would give any more detail on that though,
and I've spent a little while looking for the sort of obvious issues that
might mess this up. Any more ideas on why this might be happening here
@kzu https://github.com/kzu? Nothing obvious jumps out to me.

For now, I think I'd suggest that for now we make InterfaceProxy public
(and mark it as deprecated to avoid people depending on it), then release a
working version with that to get the current release out. Once that's out
the way we can then try and spend further time to work out what the issue
is and make it internal again in future, to tidy this up a bit, but at
least it's not a release-blocking problem at that point. Sound reasonable?

Reply to this email directly or view it on GitHubhttps://github.com//issues/98#issuecomment-35675937
.

[kzu]

I have published this fix for now. @kapdave plz update to the latest version and it should be fixed.

[kapdave]

Thank you guys!

[chrfalch]

Great work!