Owin.Security.Providers - OpenIDAuthenticationMiddlewareBase derived class claims a FieldNotFoundException

Question

Using Nuget packages Owin.Security.Providers.OpenIDBase 2.1.1 and Owin.Security.Provides.OpenID 2.24.0 - DLLs version 2.0.0.0 .

I'm deriving my own provider - ie MyOwnAuthenticationMiddleware : OpenIDAuthenticationMiddlewareBase<MyOwnAuthenticationOptions> , and passing that to IAppBuilder.Use() as part of the standard Startup.

This compiles and runs fine on my own machine - the classic developer line.

But when built on Microsoft Visual Studio Online's build server (Hosted 2017), it builds but then throws a runtime error on startup:

MissingFieldException: Field not found:
    'Owin.Security.Providers.OpenIDBase.OpenIDAuthenticationMiddlewareBase`1.HTTPClient'.]
    xxxx.CreateSpecificHandler()

Field HTTPClient (a System.Net.Http.HttpClient ) apparently can't be found in the derived generic class -it's a member of OpenIDAuthenticationMiddlewareBase , which hasn't changed in living memory.

I was thinking that the build server must be linking to a different OpenIDAuthenticationMiddlewareBase , but the full canonical name in the error message indicates otherwise.

I am receiving a fair few warnings due to ongoing .NET Framework/.NET Standard DLL hell - one relates to different versions of System.Net.Http , which I have as a Nuget package also. Could this be relevant?

On an unrelated note - does anyone else feel like the combination of Nuget dependencies and the bewildering array of .NET Framework/Standard/Core versioning has just recreated the same DLL hell that .NET was supposed to alleviate in the first place?

Answer 1

The issue is with System.Net.Http and .NETStandard.

If you have a solution/project targeting .NET Framework 4.6/4.7 that involves referencing .NETStandard2, you may have a bad time. See issues here and here on Github. Keywords: .NET Standard, .NET Framework, ASP.NET, System.Net.Http, MissingMethodException, FieldNotFoundException.

Symptoms: runtime exceptions - such as FieldNotFoundException , where the field in question could be a HttpClient, for example, something from the System.Net.Http package. Or (in my case also, in the case of BotFramework) - requests to api/messages , users trying to talk to the bot fail with a MissingMethodException . Which you can only see in server logs or ApplicationInsights. From the user's POV, it fails silently.

The consensus seems to be that an explicit reference to System.Net.Http is required in these circumstances. Easiest is to add the a binding redirect to your web.config - for example, for Nuget System.Net.Http package version 4.3.3:

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
  </dependentAssembly>

The reason this wasn't there in the first place is that I had <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> in my .csproj file, in the mistaken belief that letting the system take care of binding redirects would be best - see the article here . However, I missed the bit where it (clearly) says autogenerated binding redirects don't work in web application projects!