System.MissingMethodException Method not found: 'Boolean Castle.DynamicProxy.ProxyUtil.IsAccessible()' #308
Comments
|
@smithkl42 - thanks for reporting this. I'd say this is an issue with Moq, not with Castle Core. I would expect this problem to go away if you update to Moq 4.7.137 (which references Castle.Core 4.2.0)... could you please try this first? I was involved in #290 which likely led up to this situation. We juggled around a few methods related to the one that's now gone "missing", but we did take care to keep method signatures intact. I'm speculating now, but perhaps this
|
|
@stakx I agree, changing the class to static appears to be the only thing we changed that I would think could have caused it. The IL of Castle.Core 4.1.1 vs 4.2.0 does change by specifying the class as static: -.class public auto ansi beforefieldinit Castle.DynamicProxy.ProxyUtil extends [mscorlib]System.Object
+.class public abstract auto ansi sealed beforefieldinit Castle.DynamicProxy.ProxyUtil extends [mscorlib]System.ObjectHowever, as expected the calling code in Moq 4.7.127 is the same as 4.7.137: @smithkl42 can you confirm the version number of Castle.Core.dll is 4.2.0, and not a previous version without this method. |
|
(@jonorossi: FWIW, I checked with ECMA-335: A TypeRef metadata table entry--which is what a Moq 4.7.127 assembly contains for Castle's |
|
What I just confirmed again:
So I'm not sure why Moq 4.7.137 fixes things, but it definitely seems to. |
|
@smithkl42: Could you please (a) state what platform (including version) your code is targeting (.NET Framework, .NET Core, Mono, etc.), and (b) post repro code? Even if the problem appears to be fixed with the new versions it'd be good to find out how it got caused, so we can try to prevent it from happening again. |
Agreed, I'd really like to avoid making a breaking change like this in the future. Really not sure where to look next to work out what is going on: v4.1.1...v4.2.0 |
|
@jonorossi - The only other thing that I can think of is that somehow, NuGet resolved the wrong platform DLLs. Just today I observed VS 2017 pick .NET 4.6.1 assemblies of xUnit for a .NET Core 2.0 console app project. .NET Standard has If this happened to @smithkl42, he would likely see a NuGet warning (possibly NU1701) in VS' output window. What I find somewhat implausible about this is that there wouldn't be an earlier call from Moq to Castle Core (before |
|
Hi, |
|
@sbabaei, @smithkl42 : It's really difficult to do something about this issue as long as we don't have an isolated repro code that exhibits the problem. @sbabaei: You're saying you're only having this issue on TFS. Could you please verify a few things:
|
|
@stakx |
|
I've just attempted to reproduce this with the most basic components. I've got:
I then compile Copy it to both Program.cs: namespace MissingMethodExceptionTest
{
class Program
{
static void Main(string[] args)
{
// Castle
System.Reflection.MethodInfo method = typeof(IService).GetMethod("Test");
string messageIfNotVisible;
bool result = Castle.DynamicProxy.ProxyUtil.IsAccessible(method, out messageIfNotVisible);
System.Console.WriteLine(result);
// Moq
var mock = new Moq.Mock<IService>();
mock.Setup(x => x.Test())
.Returns(true);
System.Console.WriteLine(mock.Object.Test());
}
}
public interface IService
{
bool Test();
}
}It definitely appears to be an environment or NuGet issue. |
@jonorossi - I agree. @sbabaei is having the issue with Moq 4.7.137 and Castle Core 4.2.0, and the former has been compiled against the latter. There's nothing wrong with the DLLs themselves as far as I can see (I checked Moq's AssemblyRef entries and ran PEVerify on both assemblies, too). I have this one suspicion about the recent change of Castle Core's assembly version. Instead of steadily increasing, it has decreased from 4.1.1.0 to 4.0.0.0. I wouldn't be surprised if this leads to tools such as NuGet or the default MSBuild targets to do something wrong. I can't back this up in any way, though, perhaps someone more knowledgeable can judge whether that's plausible at all. Other than that, my main advice to affected users at this point would be to clean their package cache and build output directories and see whether this helps. |
|
I'm going to close this issue now, we've worked out that the assemblies are valid and we didn't making a breaking API change, but won't know if NuGet did something silly causing the wrong assemblies to be provided. |
|
I've got a semi-interesting continuation to this: I'm trying to run xunit tests that use Moq using ReSharper's unit test runner. Apparently ReSharper ships a copy of Castle.Core as part of the runner, so Moq ends up calling that, and produces this exception. Now, the file version for the R# copy is 4.0.0 whereas the version I've got installed is 4.2.1. Since both copies have the same assembly version, though, I don't seem to have any way of forcing the newer assembly to be used via binding redirects. |
|
@rytmis, perhaps you can tell that unit test runner to execute your tests in a separate AppDomain...? |
|
The option is there in R#'s settings, but it doesn't seem to have any effect on this issue:
Is this a "file a bug at JetBrains" kind of situation, then? |
|
@rytmis - don't know, I don't use ReSharper. However, I'd expect that its test runner should better isolate your test code from its own implementation specifics. On the other hand, it can be argued that Castle Core has been versioned "incorrectly" (whether that's true or not). I find it hard to say which component is at fault in your particular scenario. |
|
I suppose it's a case of "a little bit of both" -- the problem wouldn't be here were it not for R#'s behavior, but the Castle Core versioning strategy leaves me with no workaround, either. 🤷♂️ I guess I'll try and file this at JetBrains and see what they come up with. |
|
I'm running an older version of ReSharper, what version are you running? I don't think there is anything we can do about it, if the runner loads its version of Castle Core into the AppDomain first then Moq won't get to use its own version, I don't think assembly versions and binding redirects would solve this issue. I assume ReSharper has changed; even though Moq (and other mocking libraries) used to ILMerge Castle Core so it wouldn't have these problems other people would have picked up this problem before now using Castle Core directly, e.g. us. This actually sounds like the same sort of problem that the Azure Functions .NET SDK has where it uses JSON.NET itself which means you can't choose what version gets loaded and can't use your version. Let us know when you log the issue with JetBrains. |
|
Did that yesterday. 😊 [Edit:] Oh, and I'm running R# 2018.1, the latest published version. Curiously enough, Rider does not exhibit this problem. |
|
Today I have got an exception with text.
|
|
Your exception appears unrelated to the reported issue here.
Do you have any other libraries using Castle.Core? EntityFramework Core's proxy support? |
I agree, this is most likely a NuGet / dependency issue. This is essentially a duplicate of devlooped/moq#935, which was caused by an old version of Castle.Core lurking around. (NuGet unfortunately favors the lowest compatible version instead of the most recent one, which can cause this and similar problems.) |
|
Sorry for not being clear enough. I didn't mean that my problem was related to this one. @jonorossi , thanks for your suggestion about older stale version. I did ran into that problem again. And I did check the version of Castle.Core.dll in output folder. And you were totally right, it has v4.2.0 ("product version" of dll). I have also checked and confirmed that the file completely matches the one in ".nuget/packages/castle.core/4.2.0/lib/netstandard1.3". @stakx , thatnks for the link to the issue. This is exactly what I've got. |
After upgrading to Castle 4.2.0, I'm getting a
System.MissingMethodExceptionwith Moq 4.7.127 when trying to run some unit tests.Downgrading to 4.1.1 solves the issue.
It sounds like Castle has updated a few things in 4.2 - is this a breaking change that Moq needs to update for?
The text was updated successfully, but these errors were encountered: