funny versions of System.IO.Pipelines and System.Runtime.CompilerServices.Unsafe are being loaded at runtime

[eli-darkly]

This may not really be a WireMock.Net issue, but I'm hoping that maybe someone can shed some light on what's going on.

I'm trying to use WireMock.Net inside some .NET test code that's being run with the Xamarin runtime in iOS. The target framework is netstandard2.0. I have no problem building or deploying the app. But at runtime, I get this error from the FluentMockServer constructor:

---- System.AggregateException (Could not load file or assembly 'System.IO.Pipelines, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies.)
-------- System.IO.FileNotFoundException assembly 'System.IO.Pipelines, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies.

There are two odd things about this. First, I can't find where the dependency on System.IO.Pipelines is coming from; it doesn't seem to be a transitive dependency of my project or of WireMock.Net. That makes me think that some kind of dynamic loading is going on, possibly due to Owin/Kestrel-related stuff that I don't understand.

Second, there isn't any 4.0.0 version of System.IO.Pipelines— at least, not in NuGet, where the earliest available version is 4.5.0. So if this were a dependency that the compiler knew about, it would fail at compile time.

On a hunch, I tried adding an explicit dependency on System.IO.Pipelines (v4.7.0) in my own code. This actually did get rid of the error I mentioned. But now it's complaining instead (again at runtime only) about not being able to find a different assembly: System.Runtime.CompilerServices.Unsafe, v4.0.4. Again, that's a version that does not exist in NuGet. Unfortunately, adding my own dependency on a later version of this package doesn't fix the error, so I assume whoever is trying to use it has specified a stricter version constraint than they did for the other package.

I presume the ultimate reason this is happening has something to do with details of what is or isn't included in the Xamarin runtime— I see that a similar issue (#281) was reported earlier in Xamarin Android (although I'm deploying the same test code in Android and not having the error there). @StefH I know testing in Xamarin is probably impractical for you, but since you clearly know more about the ASP.NET Core web tools than I do, I'm just wondering if you know anything about where these dependencies are coming from.

[LevYas]

@eli-darkly

1. You can use dependency walkers such as IlSpy or many others to see all the dependencies
2. This version notation means relation to major versions. You can see this kind of references everywhere, i.e. see the screenshot in this answer https://stackoverflow.com/a/36404201/3087417

Also, there is information about other dependency walkers in other answers.
About your error, it looks like something is not installed, or maybe a binding redirects issue.

[eli-darkly]

@LevYas:

You can use dependency walkers such as IlSpy or many others to see all the dependencies

That would be true if this were a build-time dependency that is defined in the usual way. But as I said, this appears to be coming from something that's dynamically loaded, possibly by using System.Reflection.Assembly. The implementation types that make up Kestrel do not appear if you walk the dependency tree of WireMock.Net; the transitive dependencies stop at Owin and Microsoft.Owin, leading me to believe that those packages use dynamic loading to obtain the underlying implementation.

This version notation means relation to major versions

Yes, I know about major version references in dependencies. I have not seen such a version in a "Could not load file or assembly" error, though; don't those normally refer to the actual, specific version that it was trying to load? As I mentioned, when it complained about not being able to find System.Runtime.CompilerServices.Unsafe, the error referenced 4.0.4 rather than 4.0.0.

[LevYas]

@eli-darkly

don't those normally refer to the actual, specific version that it was trying to load?

Usually, I see only .0.0-versions. 4.0.4 is strange, I think it means specific version when it matters.

if I were you I would try to diagnose the problem further using tools for runtime assembly bindings checks like mentioned here: https://stackoverflow.com/a/54011223/3087417 It could provide some useful insights.

[eli-darkly]

@LevYas As I mentioned in the original description, my code is running in an iOS environment via Xamarin. It's not possible to use a tool like fuslogvw.exe there.

[LevYas]

@eli-darkly but there should be some iOS-specific tools, I think. Maybe some extended verbose logging or so on. Because this doesn't look like a general problem, so more information is needed.

[LevYas]

Do you use Mono? If so, maybe this could be helpful https://www.mono-project.com/docs/advanced/runtime/logging-runtime-events/

As for versions, I found out that the NuGet version is not the same as the assembly version, and there is a recommendation here to not change the assembly versions every time to avoid version hell. The example with different versions of the library "Immutable":

What is interesting, assemblies inside the folders for different netstandard have the same version.

[eli-darkly]

@LevYas

Because this doesn't look like a general problem, so more information is needed.

Of course it's not a general problem. I made prominent disclaimers in my original post saying that I knew this was weird and probably only tangentially related to WireMock, but that I was posting it in the long-shot hope that Stef, due to having worked with the ASP.NET Core web frameworks, might know something relevant about their dependencies. That's all. Please don't feel compelled to try to diagnose this issue for me if you don't happen to know any weird quirks of ASP.NET Core; answers like "have you tried to enable verbose logging" are not what I was looking for.

[LevYas]

Ok, sorry for bothering :)

[StefH]

@eli-darkly
I think I cannot really help you on this question.

Does maybe upgrading your unit-test project to .NET Core 3.x help?

[eli-darkly]

@StefH Just FYI, I never did manage to figure this out. Changing the project to .NET Core is not an option, because these are tests that run in Xamarin; the target framework has to be either MonoAndroid or XamarinIOs. So it is using the .NET Standard target of WireMock.Net. Unfortunately, while #534 looks like an extremely similar assembly loading problem, the workaround described there is not an option because Xamarin doesn't support binding redirects in app.config.

So what I ended up doing in Xamarin was to switch to EmbedIO. I'm still using WireMock.NET in test code that has to run in .NET Framework 4.5.x, because .NET Framework 4.5.x isn't compatible with .NET Standard and EmbedIO only has a .NET Standard target.

[StefH]

Hello @eli-darkly,

Sorry that you could not get it working with WireMock.Net

Can you maybe provide a sample project which shows the error ? Then maybe I can debug it on my system ?

[eli-darkly]

@StefH I'll try to put together a minimal example if I have time, but it wouldn't be practical for me to send you the actual project I'm working on.

[StefH]

Hello @eli-darkly,

Is this issue still relevant, or can it be closed?

[StefH]

Hello @eli-darkly,

Is this issue still relevant, or can it be closed?

[StefH]

Closing,,,