Inheritance security rules violated by type: 'System.Net.Http.WebRequestHandler'. Derived types must either match the security accessibility of the base type or be less accessible.

[clairernovotny]

Using the latest System.Net.Http 4.1.1 as per https://github.com/dotnet/runtime/issues/17770#issuecomment-242131706, results in an exception when starting a web app that's .NET 4.6.1:

Inheritance security rules violated by type: 'System.Net.Http.WebRequestHandler'. Derived types must either match the security accessibility of the base type or be less accessible.

I've emailed a repro to @davidsh

---

Execution plan & status

[UPDATED by karelz]

High-level plan: A. Revert HttpClientHandler implementation in net46 build of CoreFX back to using original .NET Framework HTTP stack instead of WinHTTP (WinHttpHandler) based stack. B. Revise implementation of the 8 new APIs on HttpClientHandler we introduced in 4.1.0.0 OOB package so that it works accordingly for the net46 build.

Execution plan:

1. Validate feasibility of [A]

   • [x] a. Port HttpClientHandler from NetFX (remove WinHttpHandler build dependency for net46 build).
   • [x] b. Add APTCA (on assembly only, no security attributes should be necessary for types or methods - same as in Desktop source code).
     • [x] Run the SecAnnotate tool to verify the claim above - Result: Passed
   • [x] c. Manually test the 2 scenarios (simplified and @onovotny’s) - Result: Verified

2. Validate feasibility of [B]

   • [x] a. Investigate the 2 remaining APIs (DefaultProxyCredentials, MaxConnectionsPerServer) which we do not know if we can implement. - Result: They are in the bucket 4.a below.

3. Full testing of [A] implementation (cost: 1d)

   • [x] a. Make changes in master
   • [x] b. Test all ~7 end-to-end scenarios reported by community (ask for help from community, provide steps to consume master packages on myget)
     • [x] Self hosting ASP.NET Core from Windows Service - validated by @annemartijn0 (here)
     • [x] Azure Storage API - validated by @karelkrivanek (here)
     • [x] Raven.Database package + usage of new HttpClientHandler - validated by @jahmai (here)
     • [x] Direct dependency on System.Net.Http - validated by @pollax (here)
     • [x] 4.6 console app depending on System.Net.Http - validated by @MikeGoldsmith (here)
     • [x] 4.6 Azure webjob (console app) with ServiceBus - validated by @chadwackerman (here)
     • [x] 4.6 Azure Batch app - validated by @chadwackerman (here)
     • [ ] Not-yet-described scenario by @dluxfordhpf

4. Full implementation and testing of [B]

   • [x] a. Decide on design of 4 APIs (CheckCertificateRevocationList, SslProtocols, DefaultProxyCredentials, MaxConnectionsPerServer) which we can’t implement “correctly” - we have 3 choices - either throw PlatformNotSupportedException, or do nothing, or set the properties domain-wide instead of per-HttpClient-instance
     • [x] i. Implement the decision (cost: 2d)
     • [x] ii. List all libraries on NuGet (e.g. WCF?) which use the APIs we will be technically breaking, contact them
     • 4 NuGet libraries potentially affected - owners contacted - see details and tracking progress
   • [x] b. Implement 5 APIs which we know how to implement (cost: 3d)
   • [x] c. Final testing on master branch package - covered by [3.b]

5. Ship final packages

   • [x] a. Port changes into release/1.1.0 branch
   • [x] b. Produce new package - 4.3.1
   • [ ] c. Test most of ~7 end-to-end scenarios reported by community (ask for help from community, provide steps to consume 4.3.1 stable package from myget feed - see here)
     • [ ] Self hosting ASP.NET Core from Windows Service - @annemartijn0
     • [x] Azure Storage API - @karelkrivanek
     • [ ] Raven.Database package + usage of new HttpClientHandler - @jahmai
     • [x] Direct dependency on System.Net.Http - @pollax (here)
     • [ ] 4.6 console app depending on System.Net.Http - @MikeGoldsmith
     • [ ] 4.6 Azure webjob (console app) with ServiceBus
     • [ ] 4.6 Azure Batch app
     • [ ] Not-yet-described scenario by @dluxfordhpf
     • [x] KeyVault - @Vhab (here)
     • [x] SignalR - @tofutim (here)
     • [x] OwlMQ - @JoeGordonMVP (here)
   • [x] d. Publish package on nuget.org - https://www.nuget.org/packages/System.Net.Http/4.3.1

---

Impact of the change - Breaking changes

Here's list of technical breaking changes caused by the proposed solution. It includes workarounds for each. Note that these new behaviors are specific when running on net46 / Desktop. When you run on .NET Core, the behavior is intact.

1. HttpClientHandler.CheckCertificateRevocationList (introduced in System.Net.Http 4.1)
   • New behavior: Throws PlatformNotSupportedException
   • Workaround: Use ServicePointManager.CheckCertificateRevocationList instead (impacts the whole AppDomain, not just single HttpClientHandler as it did in System.Net.Http 4.1-4.3)
2. HttpClientHandler.SslProtocols (introduced in System.Net.Http 4.1)
   • New behavior: Throws PlatformNotSupportedException
   • Workaround: Use ServicePointManager.SecurityProtocol instead (impacts the whole AppDomain, not just single HttpClientHandler as it did in System.Net.Http 4.1-4.3)
3. HttpClientHandler.ServerCertificateCustomValidationCallback (introduced in System.Net.Http 4.1)
   • New behavior: Works fine, except that the first parameter of type HttpRequestMessage is always null
   • Workaround: Use ServicePointManager.ServerCertificateValidationCallback

4. HTTP/2.0 support (introduced in System.Net.Http 4.1)

   • New behavior: System.Net.Http (for net46 = Desktop) no longer supports HTTP/2.0 protocol on Windows 10.
   • Workaround: Target System.Net.Http.WinHttpHandler NuGet package instead.

   • Details:

     • HTTP/2.0 support is part of the new CoreFx HTTP stack which on Windows is based on WinHTTP. The original HTTP stack in .NET Framework 4.6 did not support HTTP/2.0 protocol. If HTTP/2.0 protocol is needed, there is a separate NuGet package, System.Net.Http.WinHttpHandler which provides a new HttpClient handler. This handler is similar in features to HttpClientHandler (the normal default handler for HttpClient) but will support HTTP/2.0 protocol. When using HttpClient on .NET Core runtime, the WinHttpHandler is actually built-in to HttpClientHandler. But on .NET Framework, you need to explicitly use WinHttpHandler.
     • Regardless of whether you are running using .NET Framework runtime (with WinHttpHandler) or .NET Core runtime using HttpClientHandler (or WinHttpHandler), there are additional requirements in order to get HTTP/2.0 protocol working on Windows:
     • The client must be running on Windows 10 Anniversary Build (build 14393 or later).

     • The HttpRequestMessage.Version must be explicitly set to 2.0 (the default is normally 1.1). Sample code:

       var handler = new WinHttpHandler();
       var client = new HttpClient(handler);
       var request = new HttpRequestMessage(HttpMethod.Get, "http://www.example.com");
       request.Version = new Version(2, 0);
       
       HttpResponseMessage response = await client.SendAsync(request);

[davidsh]

Tried to verify but I'm getting errors attempting to install that package.

When I did my validation, I did it with a brand new project.

I suspect that the error you're getting with "Failed to update binding redirects" is due to the downgrade in package and assembly versions. Your current project appears to be based on the packages from the [master] branch. System.Net.Http.4.4. is package numbering from [master] branch (part of the pre-release for .NET Core 2.0). It has an assembly version for System.Net.Http that is 4.2..

The package System.Net.Http version 4.3.1 is a STABLE (not pre-release) package and it is built from the .NET Core 1.1 servicing branch (compatible with .NET Core 1.1.1 servicing release). It contains a binary of System.Net.Http dll with a different assembly version.

I think the bug you've discovered is when Visual Studio/NuGet is trying to re-write your binding redirects for the changed assembly version of System.Net.Http.

So, you could try either to create a fresh new solution/project. Or perhaps delete your binding redirects and then put them back.

[davidsh]

FYI. My log from my package install:

Attempting to gather dependency information for package 'System.Net.Http.4.3.1' with respect to project 'Net46HttpTest3', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 4.27 min
Attempting to resolve dependencies for package 'System.Net.Http.4.3.1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'System.Net.Http.4.3.1'
Resolved actions to install package 'System.Net.Http.4.3.1'
Retrieving package 'System.Security.Cryptography.Encoding 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Primitives 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Algorithms 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.X509Certificates 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Net.Http 4.3.1' from 'CoreFx Dev Feed'.
  GET https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1
Adding package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
  OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1 302ms
Installing System.Net.Http 4.3.1.
Added package 'System.Security.Cryptography.Encoding.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Encoding 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Primitives 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Algorithms 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.X509Certificates 4.3.0' to Net46HttpTest3
Adding package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to 'packages.config'
Successfully installed 'System.Net.Http 4.3.1' to Net46HttpTest3
Executing nuget actions took 2.41 sec
========== Finished ==========
Time Elapsed: 00:06:40.8451462

[pollax]

Hm, I'm confused when testing. I updated to 4.3.1 and got the following binding redirect in my web.config.

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

Expected? Maybe I missed something earlier in the thread, or maybe this is one of those confusing packages version vs dll version missmatch situations. I also uninstalled the package, removed the binding redirects and then reinstalled and I got the same result.

Building and running Works On My Machine™️.

[davidsh]

Incidentally I'm not quite sure why this version dropped from 4.4 to 4.3.1 but okay.

The version dropped in numbering because the 4.4 version will be the latest but it is still pre-release and will shipped as part of .NET Core 2.0. @karelz asked folks to test that package first because the fix was there first.

The 4.3.* packages are based on the RTM .NET Core 1.1. And there will be a servicing release of that. So, the updated package based on that codebase is 4.3.1 for System.Net.Http (since the .NET Core 1.0 package was 4.3.0 for System.Net.Http.

Maybe I missed something earlier in the thread, or maybe this is one of those confusing packages version vs dll version missmatch situations.

Yes, this is confusing. The NuGet package version is not the same as the .NET assembly version of the binary.

For the System.Net.Http 4.3.1 NuGet package, it does contain a binary of System.Net.Http that has a 4.1.1.0 assembly version. So, you are getting the right results.

[karelz]

Thanks @pollax for validation of your end-to-end scenario (top post updated). Waiting for couple of more validations, before we can ship it as final fix on nuget.org ... almost there ...

My apologies that we missed the binding redirect in instructions (I didn't realize we automatically bump assembly version due to potential GAC'ing, but it makes sense). Also apologies that myget forces you into all packages from myget -- I am following up with folks internally to find out if we have steps to grab just single package from myget. At least for future verifications.

@davidsh can you please coordinate the end-to-end validations while I am OOF? Once we have ~3 validations, please ask @leecow / @weshaggard to publish the package on nuget.org. Thanks!

[kriscoleman]

Hey guys,

Slightly off topic but I just wanted to give a shoutout to the team here. This issue has been very active and the response has been sometimes hostile. Despite the hostility, I feel the dev team here handled it with class.

Thanks for the support guys and keep up the good work. Mistakes happen. Thanks for fixing it, I understand it takes time.

[Vhab]

Here's another confirmation the new version fixes the issue.

We use KeyVault, bumping to 4.3.1 fixed the issue.

[tofutim]

Hi, I have this problem with SignalR. But how do I get System.Net.Http 4.3.1? I only see 4.3.0 in https://www.nuget.org/packages/System.Net.Http/

Oops, missed messages about CoreFx - https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

It fixes my SignalR issue.

As noted by others, the feed is super slow. Any chance of getting 4.3.1 into the normal nuget channel? It is Sat at 1:30pm and whoa.... (8 minutes waiting for deps)

---

Attempting to gather dependency information for package 'System.Net.Http.4.3.1' with respect to project 'Translate\Kumquat.Translate.Tests', targeting '.NETFramework,Version=v4.6' Gathering dependency information took 5.85 min Attempting to resolve dependencies for package 'System.Net.Http.4.3.1' with DependencyBehavior 'Lowest' One or more unresolved package dependency constraints detected in the existing packages.config file. All dependency constraints must be resolved to add or update packages. If these packages are being updated this message may be ignored, if not the following error(s) may be blocking the current package operation: 'System.Net.Http 4.3.0' Resolving dependency information took 0 ms Resolving actions to install package 'System.Net.Http.4.3.1' Resolved actions to install package 'System.Net.Http.4.3.1'

Attempting to gather dependency information for package 'System.Net.Http.4.3.1' with respect to project 'Dict\Kumquat.Dict.CE.Tests', targeting '.NETFramework,Version=v4.6' Gathering dependency information took 3.84 min Attempting to resolve dependencies for package 'System.Net.Http.4.3.1' with DependencyBehavior 'Lowest' One or more unresolved package dependency constraints detected in the existing packages.config file. All dependency constraints must be resolved to add or update packages. If these packages are being updated this message may be ignored, if not the following error(s) may be blocking the current package operation: 'System.Net.Http 4.3.0' Resolving dependency information took 0 ms Resolving actions to install package 'System.Net.Http.4.3.1' Resolved actions to install package 'System.Net.Http.4.3.1'

[karelkrivanek]

@karelz Azure Storage API scenario revalidated with the 4.3.1 version from MyGet.

Sorry for not responding sooner.

[maartenba]

@tofutim gathering dependencies is slow because of a lot of metadata going over the wire - https://github.com/NuGet/Home/issues/4448

[tofutim]

I figured that. Any ETA on getting it into nuget.org?

@davidsh Hi David, will this be the week 4.3.1 makes it to nuget? I have a fairly complex project and it feels like wait time must scale with the number of packages in the project. Still, having a fix is better than nothing. I suppose I can copy the nupkg somewhere.

Attempting to gather dependency information for package 'Kumquat.Translate.8.6.2' with respect to project 'qi', targeting '.NETFramework,Version=v4.6' Gathering dependency information took 8.76 min

Most recently 8.76 min.

[JoeGordonMVP]

@davidsh This just popped up on the OwlMQ mailing list. I can report that the updated package solves it.

Thanks so much to the team for getting ahead of this. Awesome work!

[davidsh]

Thank you for all the validations of the package.

The System.Net.Http 4.3.1 package has been promoted to NuGet.org.

https://www.nuget.org/packages/System.Net.Http/4.3.1

[georgiosd]

Hm, very bizarre - RavenDB client now complains it can't find the 4.1.1 assembly

EDIT: Caveat - Acme.Core references RavenDB.Client and Acme.Main references Acme.Core. VS2015 won't copy System.Net.Http as dependency but binding redirect is there -> boom. Is this expected behavior? Simple enough fix of course...

[karelz]

Closing the issue as fixed. Thanks @davidsh and @CIPop for their work here! Thanks everyone for their patience. And our apologies for the delay. Next step: post-mortem (as promised) - please give me ~2 weeks to find out all historical details around here ...

@georgiosd can you please file a new issue and provide a repro? (ideally starting with new project)

[tofutim]

@karelz thank you!

[karelz]

FYI:

• I updated top most post with list of verified scenarios (just in case it is ever needed in future) and link to the package.
• For future, I plan to look at steps to use just particular package from myget instead of the entire feed, to workaround the problem of getting everything as latest (and also the slowness issues). Let's hope we won't need it that soon.

[PureKrome]

@karelz quick question: where will we find info about the post-mortem, when that is completed. In this thread or another thread/place?

[karelz]

@PureKrome I will definitely update this thread - it's easier for everyone already interested to get the notification. Also my goal is not to downplay the post-mortem and hide it from people. I will most likely create a new issue for the discussion though (as I expect some) ;-). On high level, I plan to cover:

1. How did the issue slip through into release? How to prevent such situation in future?
2. Why did it take 6 months to fix? Why wasn't it treat/communicated as high-impact issue earlier? How to recognize and react to high-impact issues earlier in future?
3. Other concerns (e.g. overall communication)

Also, if we find something broken / not working correctly with 4.3.1 (e.g. @georgiosd's find above), we should mention it here for awareness, but take details into separate issue for easier discussion/follow up.

[PureKrome]

Thank you @karelz (and MS Team). I'll stay subscribed to this thread then. 👍

Keep fighting the good fight, team! 💯

[tofutim]

I also have to thank @chadwackerman2

[georgiosd]

Congrats to all once again for solving one of the most annoying bugs in the history of .NET :)

@karelz happy to do so but I wondered if this is somehow the expected behavior?

[karelz]

@georgiosd I don't know - it will be easier to discuss it in separate issue ;-) (incl. pulling in the right experts)

[gulbanana]

Thanks for driving this work, @karelz

[karelz]

I know I am late with the post-mortem here, my apologies. I didn't forget, I just didn't get to it yet due to higher priorities (planning/tracking 2.0, looking deeper into the binding redirects issue which surfaced here as well - dotnet/runtime#17770) I'll try hard to finish the post-mortem in next 1-2 weeks.

[dmcweeney]

Hi, Well done all involved in resolving this. Cant say I understand all the nuts and bolts but one thing I still don't understand is why this only happened when we upgraded our solution from VS 2015 Update 3 to VS 2017. Solution in question was a set of ASP.Net Core projects targeting the .net framework 4.6. Problem was getting triggered by our use of Azure KeyVaultClient.

Thanks, Donal

[parismiguel]

Hi @karelz , I've been researching and working two nights in a row so far but I'm not able to fix this. All my System.Net.Http packages have been updated to version 4.3.1 but still get the same error. Please help me, I don't know what else to try or where to go. Thanks!

FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

An here my .csproj

netcoreapp1.1 $(PackageTargetFallback);portable-net45+win8+wp8+wpa81; aspnet-IbmVcaCore-5aa05652-04e7-4a42-9fd6-8dbc1c8b98fe

[karelz]

@parismiguel sorry to hear that :(. Do you have bindingRedirects from 4.0.0.0 to 4.1.1.0 in your app?

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

We're looking into how to make the bindingRedirects story smoother: https://github.com/dotnet/corefx/issues/9846#issuecomment-287941109

UPDATE: Looking at your error, it seems that the problem is that your 4.1.1.0 version was not found. Can you check your app directory if the right assembly version is truly there?

[parismiguel]

@karelz that was fast, thank you very much! I've saw the bindingRedirects stuff in previous posts but I'm not sure where to place it... I've tried inside my .csproj but I've got errors (attached as .txt) Concerning version 4.1.1.0 I'm not sure to follow... Am I not supposed to upgrade it to 4.3.1 ?

IbmVcaCore.csproj.txt

[davidsh]

Binding redirects go into your app.config or web.config file:

[davidsh]

See this for details: https://msdn.microsoft.com/en-us/library/7wd6ex19(v=vs.110).aspx

[parismiguel]

Hi @davidsh , thank you for your help! My project doesn't have any of those files... its a NET Core project build using Visul Studio 2017 template... what am I missing?

[karelz]

Re: 4.3.1 vs. 4.1.1 - 4.3.1 is NuGet package version, 4.1.1.0 is assembly version (ildasm/ILSpy/VS will show it to you). The versions NuGet vs. assembly are a bit confusing and it's hard to connect which belongs to which. It's on my list of things to look deeper into if we can connect the dots via documentation (e.g. on NuGet page).

[karelz]

If you're on .NET Core, you don't need the bindingRedirects and moreover, this issue does NOT affect you at all. This issue is specific to Desktop (= .NET Framework). The 4.3.1 NuGet package modified only its Desktop assembly, not .NET Core assembly.

[karelz]

If you still have trouble, please file a new bug and tag me there. This issue is blasted to quite a lot folks (as it was impactfull), your problem is unrelated to it (at least it looks like that), so let's be kind to everyone's GH notifications / inboxes.

[karelz]

To everyone: I have created a new issue #20777 (was https://github.com/dotnet/corefx/issues/17522) to track the post-mortem I promised. Sadly, I didn't make much progress towards it yet :( ... but at least everyone interested can start following that issue and avoid potential noise on this issue (trying to help people focus on what they are interested in).

[parismiguel]

@karelz thanks, I'll follow your instructions and post on your brand new issue tracker. Regards.

[karelz]

@parismiguel not on the new issue I created, please create a brand new one. The one I created (#17522) is for post-mortem analysis why this issue (#11100) took so long to resolve.

[parismiguel]

thank you @karelz and my sincere apologies for messing this topic.... hope to get some help in the new one as instructed. Warm regards,

[Workshop2]

I have seemed to have encountered this via a perfect storm.

I am using the Azure Functions preview with a combination of both Azure Key Vault (2.0.6) and Octopus Client (4.15.3).

I have tried upgrading to System.Net.Http to 4.3.2 however it still fails when trying to use Key Vault.

Any tips?

@karelz

[karelz]

Can you please make sure that the assembly from 4.3.2 nuget package is really used at runtime? (it was fixed in 4.3.1)