Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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. #18280

Closed
clairernovotny opened this issue Aug 24, 2016 · 193 comments
Assignees
Milestone

Comments

@clairernovotny
Copy link
Member

@clairernovotny clairernovotny commented Aug 24, 2016

Using the latest System.Net.Http 4.1.1 as per https://github.com/dotnet/corefx/issues/9846#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]

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

    • 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)

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

    • 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
      • i. Implement the decision (cost: 2d)
      • ii. List all libraries on NuGet (e.g. WCF?) which use the APIs we will be technically breaking, contact them
    • b. Implement 5 APIs which we know how to implement (cost: 3d)
    • c. Final testing on master branch package - covered by [3.b]
  5. Ship final packages

    • a. Port changes into release/1.1.0 branch
    • 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)
    • 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 davidsh self-assigned this Aug 24, 2016
@ericstj
Copy link
Member

@ericstj ericstj commented Sep 8, 2016

I happened to look at this today from another report. /cc @ChadNedzlek

This looks like it might be due to missing security attributes on the out-of-band System.Net.Http.dll compared to the inbox System.Net.Http.dll. Inbox version has AllowPartiallyTrustedCallers. So does the inbox System.Net.Http.WebRequest.dll. This means everything is treated as SecurityTransparent unless annotated otherwise.

The OOB System.Net.Http.dll is missing AllowPartiallyTrustedCallers, which makes everything security-critical. Now when the inbox WebRequest.dll loads the OOB System.Net.Http.dll it violates the security rule, since WebReqeuestHandler is transparent, but HttpClientHandler which it derives from is critical.

My repro:

  1. File > new desktop application
  2. Project properties > signing > enable strongname signing
  3. Add reference to System.Net.Http.WebRequest
  4. Install System.Net.Http 4.1.0.
  5. In the main, just call new WebRequestHandler();
@fabiodiluca
Copy link

@fabiodiluca fabiodiluca commented Sep 12, 2016

ericstj is right, I have the same problem here. This is a critical issue on System.Net.Http 4.1.0 that should be repaired. I can't use this library with .net4.6.1 because it lacks consistency.

@dluxfordhpf
Copy link

@dluxfordhpf dluxfordhpf commented Sep 12, 2016

This problem is a significant pain to deal with, and in particularly makes using the Azure KeyVault client painful for my team. The only painless alternative is to downgrade to .NET 4.5.2, which is not acceptable.

Also, the workaround listed previously is insufficient. If you want to use NET 4.6.x, what we've found is you have to do the following this for it to work reliably: disable dependency checking, downgrade System.Net.Http, edit the CSPROJ and disable automatic binding redirect, modify the app.config, and typically clean/exit VS/and rebuild as I've often seen System.Net.Http in use, even for trivial projects. Here's the procedure that reliably fixes this.

  1. Right click the project in Visual Studio and select Manage NuGet Packages.
  2. Goto the Installed tab.
  3. Scroll down to SYSTEM.Net.Http – not Microsoft.Net.Http.
  4. In the right hand pane, if Installed is not 4.0.0.0, then set Version to 4.0.0.0.
  5. In the right hand pane, set Dependency behavior to Ignore Dependencies. If you do NOT do this, the Microsoft.IdentityModel.Clients.ActiveDirectory package will be substantially downgraded, which is NOT correct.
  6. Click Update - this button should really be labeled "Change To Version".
  7. In the Preview window, verify that the ONLY change listed is "Installing System.Net.Http". If you forgot to set Dependency behavior correctly, the additional change will be listed here.
  8. Click OK/Yes/I Agree on the confirm dialogs and wait for processing to complete. When complete, the package listing will show two version numbers – the check mark is next to the one that is in use.
  9. On the NuGet Installed tab, select the listing for Microsoft.IdentityModel.Clients.ActiveDirectory.
  10. In the right-hand details pane, set Dependency behavior to "Ignore". If you do not do this, any subsequent NuGet adds will fail when NuGet's validation for this package runs.
  11. In Visual Studio, select File|Save All.
  12. Open the CSPROJ file for this project in a text editor.
  13. In /Project/PropertyGroup*1 (the first PropertyGroup element of Project), add the following line, or change the value of this element if it already exists:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
  14. Save the file, then reload the project in Visual Studio.
  15. Open the app.config file for this project.
  16. Find the line for System.Net.Http and edit it to redirect it to 4.0.0.0 instead of 4.1.0.0. So find this:
<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> 
</dependentAssembly> 

And change it to this:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.0.0" /> 
</dependentAssembly> 
  1. Rebuild the project. If you get an exception when running Azure Key Vault code, one or more *.config files in the bin/debug or similar directories have not been updated. You may have to exit Visual Studio to clear them and rebuild.
@fabiodiluca
Copy link

@fabiodiluca fabiodiluca commented Sep 12, 2016

dluxfordhpf, thanks for your time explaining how you have worked this out. Redirecting to System.Net.Http 4.0 worked for me in .net4.6.1, But is still very hard to maintain (the nuget dependency). Looking forward the version that will fix this.

@ericstj
Copy link
Member

@ericstj ericstj commented Sep 12, 2016

Redirecting could cause problems if folks are using any of the new API added in System.Net.Http 4.1.0.

in particularly makes using the Azure KeyVault client painful for my team

@ChadNedzlek had the same problem and was able to workaround it by passing in an HttpClient he created himself to the KeyVaultClient constructor. If you don't use WebRequestHandler you'll avoid the problem.

EG:

var handler = new HttpClientHandler();
// configure handler
// eg: handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => errors == SslPolicyErrors.None;
var client = new HttpClient(handler);
var kvclient = new KeyVaultClient(async (authority, resource, scope) => "foo", client);

@davidsh I think you need to put AllowPartiallyTrustedCallers back on System.Net.Http.dll. /cc @morganbr

@guillaumeraymond
Copy link

@guillaumeraymond guillaumeraymond commented Sep 20, 2016

@dluxfordhpf Big thanks for the steps.
It is temporary and we hope a fix soon but still, I can continue to work on the project !

@robertmclaws
Copy link

@robertmclaws robertmclaws commented Oct 13, 2016

@terrajobst This is a blocking production issue. Any idea when we can get a fix onto NuGet? Thanks!

@b3nt0
Copy link

@b3nt0 b3nt0 commented Oct 17, 2016

Just ran into this myself. Would be awesome if we didn't descend into dependency hell in .Net. It's heading that way.

EDIT: Fixed with a prior comments suggestion to use the system httpclient??
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
That seemed to get it...

@MichaelVach
Copy link

@MichaelVach MichaelVach commented Nov 2, 2016

The problem is only becoming worse as more and more nuget packages from Microsoft take a dependency on the latest version of System.Net.Http. I am probably not the only one who constantly upgrades his Microsoft nuget packages to the latest pre-release version. For example packages that no longer work for me in their latest version:

Microsoft.IdentityModel.Clients.ActiveDirectory
Microsoft.TeamFoundationServer.Client
Microsoft.VisualStudio.Services.Client.
....

@robertmclaws
Copy link

@robertmclaws robertmclaws commented Nov 2, 2016

I still don't understand why this package is still available. @terrajobst @coolcsh can we get this package taken down/fixed? It's REALLY causing issues with complex app environments. Wasted several hours trying to keep the offending package from creeping into the build. Thanks!

@dluxfordhpf
Copy link

@dluxfordhpf dluxfordhpf commented Nov 2, 2016

We are looking at binding to the System.Net.Http in the NET Framework instead of this broken thing from NuGet. I agree, this problem is ridiculous, and very expensive to deal with as you must synchronize NuGet versions between projects, prevent auto binding updates, and fix/check your app.config. What surprises me is that it’s in such a widely used assembly. Perhaps MS doesn’t really care about KeyVault that much?

@guillaumeraymond
Copy link

@guillaumeraymond guillaumeraymond commented Nov 2, 2016

It is also used by the ActiveDirectory Nugget

@sandersaares
Copy link

@sandersaares sandersaares commented Nov 3, 2016

I have reverted some libraries from targeting .NET Standard due to this and related issues where broken NuGet packages just mess up apps that target .NET Standard. This is a sorry state of things.

@terrajobst
Copy link
Member

@terrajobst terrajobst commented Nov 4, 2016

Thanks for filing. We're actively looking into this. Stay tuned.

@CodingGorilla
Copy link

@CodingGorilla CodingGorilla commented Nov 14, 2016

This has become a significant issue for me; we use a lot of our own nuget packages internally. And it seems nuget just will not let those bindingRedirects alone. Everytime we update one of our internal packages, it changes the redirect back to newVersion="4.1.0.0". Is there a way to stop it from doing that, or is there a fix on the horizon?

@mdsharpe
Copy link

@mdsharpe mdsharpe commented Nov 16, 2016

Encountered when running application over HTTPS, which worked fine over HTTP. Not sure if any other significant differences.
Workaround of setting newversion="4.0.0.0" worked for me.

@jahmai
Copy link

@jahmai jahmai commented Nov 19, 2016

Still an issue in NETStandard 1.6.1. Why?!

@LoulG
Copy link

@LoulG LoulG commented Nov 19, 2016

System.Net.Http 4.3.0 is out. Someone tried ?

@jahmai
Copy link

@jahmai jahmai commented Nov 19, 2016

@LoulG Yep, still a problem I'm afraid.

@robertmclaws
Copy link

@robertmclaws robertmclaws commented Nov 19, 2016

I spoke with @terrajobst on Twitter, and he said it's actually a bigger problem, and they have like 10 people working on it now. I'm personally not sure why they are not pulling the versions of this package displaying the problem, as I thought that's what package management was for. But the next we can do at this point is wait.

@odinnou
Copy link

@odinnou odinnou commented Nov 20, 2016

@LoulG same here, I have updated all my Nuget Packages, with the release of .net core 1.1 and i got this issue

System.TypeLoadException: 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.

Firstly, I think it was due to IdentityServer/IdentityServer3.AccessTokenValidation but, with reading this issue I understand my situation t_t, I spent several hours to try to solve it

EDIT :
OMG,
Workaround of setting newversion="4.0.0.0" worked for me too

I try to update to 4.3 but, same issue :(((

@HalidCisse
Copy link

@HalidCisse HalidCisse commented Nov 20, 2016

same issue here after upgrading

@vascofernandes
Copy link

@vascofernandes vascofernandes commented Nov 21, 2016

Issue still present with 4.3.0.

@Kwal
Copy link

@Kwal Kwal commented Nov 22, 2016

@terrajobst can you provide any updates on this issue or any further insight into the deeper problem that @robertmclaws referenced?

@matthewrwilliams
Copy link

@matthewrwilliams matthewrwilliams commented Nov 22, 2016

Any reason why this fix works locally, but when deployed to an Azure Cloud Service, the error persists?

@jahmai
Copy link

@jahmai jahmai commented Nov 22, 2016

Sometimes packaging Azure can screw up your binding redirects, try unzipping the cspkg and see what is actually being deployed.

@matthewrwilliams
Copy link

@matthewrwilliams matthewrwilliams commented Nov 22, 2016

Here is the version of the System.Net.Http.dll

Snip

I've been working on this for a few days now. Was super happy to find this fix and in tears when deploying out to Azure.

@jahmai
Copy link

@jahmai jahmai commented Nov 22, 2016

What about the .config file containing binding redirects for the project? I actually expect it to still deploy the broken version of the assembly due to CopyLocal being true from the nuget package, but the binding redirect should ensure that the framework version of the assembly is instead loaded inside the cloud service VM.

@matthewrwilliams
Copy link

@matthewrwilliams matthewrwilliams commented Nov 22, 2016

It is!!! WTH?

<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>

Looking back into my project, the web.config has reverted as well. I'll have to pick this up again in the morning. Thanks for some leads!

@tofutim
Copy link

@tofutim tofutim commented Feb 22, 2017

I also have to thank @chadwackerman2

@georgiosd
Copy link

@georgiosd georgiosd commented Feb 23, 2017

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
Copy link
Member

@karelz karelz commented Feb 23, 2017

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

andreesteve referenced this issue in iedeny/BotBuilder Feb 24, 2017
@gulbanana
Copy link

@gulbanana gulbanana commented Feb 24, 2017

Thanks for driving this work, @karelz

@karelz
Copy link
Member

@karelz karelz commented Mar 16, 2017

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 - #17770)
I'll try hard to finish the post-mortem in next 1-2 weeks.

msft-shahins referenced this issue in microsoft/botframework-sdk Mar 21, 2017
commit dcad83404f82972e5f6cf9a575882c602294a345
Merge: 2448cc9 5a66adf
Author: Shahin Shayandeh <shahins@microsoft.com>
Date:   Tue Mar 21 11:20:45 2017 -0700

    Merge branch 'sharedtolibrary' of https://github.com/iedeny/BotBuilder into iedeny-sharedtolibrary1

commit 2448cc9
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Mon Mar 13 18:07:10 2017 -0700

    new RecognizerFiler class

commit d74fe9c
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Mon Mar 13 16:41:17 2017 -0700

    new LocalizedRegExpRecognizer class.

commit 2a78d18
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Mon Mar 13 15:52:43 2017 -0700

    Fixed bug in UniversalBot.send()
    - Didn't protect against empty list of messages,
    - Also wasn't returning errors in an edge case.

commit b74bcb9
Merge: bd76705 9ee2f8d
Author: Robert Standefer <robstand@outlook.com>
Date:   Mon Mar 20 08:47:38 2017 -0700

    Merge pull request #2465 from brandonh-msft/patch-1

    Update GettingStarted.cs

commit 9ee2f8d
Author: Brandon H <hurlburb@microsoft.com>
Date:   Mon Mar 20 08:32:13 2017 -0700

    use new shorturls for dialog & controller templates

commit 826e9dc
Author: Brandon H <brandonh-msft@users.noreply.github.com>
Date:   Sun Mar 19 13:45:41 2017 -0700

    Update GettingStarted.cs

    Adding links to Dialog and Controller Item templates

commit 5a66adf
Author: Yegor Denisov <yegor.denisov@gmail.com>
Date:   Wed Mar 15 15:28:41 2017 -0700

    Remove app id and password from sample configs

commit f95ba06
Author: Yegor Denisov <yegor.denisov@gmail.com>
Date:   Wed Mar 15 15:27:55 2017 -0700

    Regenerate Microsoft.Bot.Connector.xml after merge from master

commit 1f5540d
Merge: a06cee8 bd76705
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Wed Mar 15 23:09:21 2017 +0100

    Merge remote-tracking branch 'origin/master' into sharedtolibrary

commit bd76705
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Mon Mar 13 14:58:01 2017 -0700

    Bug fixes around new debug event.

commit d2f0299
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Thu Mar 9 13:33:31 2017 -0800

    Added customAction() feature.

commit 2d26947
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Wed Mar 8 15:34:59 2017 -0800

    Updated docs with session logger stuff.

commit b77f683
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Tue Mar 7 22:14:35 2017 -0800

    Added watch support.

commit 125f22b
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Tue Mar 7 19:30:58 2017 -0800

    DEBUG event support
    - Stream console logs to emulator

commit b3b602e
Author: Shahin Shayandeh <shahins@microsoft.com>
Date:   Tue Mar 7 15:14:33 2017 -0800

    Update assembly versions for latest release

commit 07f3e89
Author: Shahin Shayandeh <shahins@microsoft.com>
Date:   Tue Mar 7 13:53:27 2017 -0800

    Update the french resource file and test

commit 2956e49
Merge: a7e4677 3564235
Author: Shahin Shayandeh <shahins@microsoft.com>
Date:   Tue Mar 7 13:46:06 2017 -0800

    Merge branch 'develop'

commit a06cee8
Author: Yegor Denisov <yegor.denisov@gmail.com>
Date:   Tue Mar 7 12:27:01 2017 -0800

    Microsoft.Bot.Builder.VS2017.sln auto-refreshed by RTM version VS 2017

commit 24dcf7c
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Thu Mar 2 20:09:27 2017 +0000

    Apply workaround for netstandard 1.6 tooling

    Issue: dotnet/roslyn#12918

commit a7e4677
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Tue Feb 28 19:21:39 2017 -0800

    Adding snippets needing for new docs.

commit a170fa4
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Fri Feb 24 22:20:46 2017 +0000

    Revert EOL changes

commit 1003f26
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Thu Feb 23 18:26:33 2017 -0800

    Updated package.json version

commit 091e0f4
Author: Carlos Castro <ccastro@microsoft.com>
Date:   Tue Feb 21 11:30:16 2017 -0800

    Prompts methods verification for session parameter

commit df9e9a7
Author: Carlos Castro <ccastro@microsoft.com>
Date:   Tue Feb 21 11:25:29 2017 -0800

    Prompts.text outputs a meaningful error message when session is not provided

commit f67dea2
Author: Yegor Denisov <yegor.denisov@gmail.com>
Date:   Thu Feb 23 11:47:44 2017 -0800

    Add missing IdentityModel packages to samples

commit 6676183
Author: iedeny <iedeny@microsoft.com>
Date:   Wed Feb 22 19:40:06 2017 -0800

    Downgrade AutoRest back to 0.16.0

commit 3d1745b
Author: iedeny <iedeny@microsoft.com>
Date:   Wed Feb 22 19:23:45 2017 -0800

    Add AspNetCore.Mvc to original solution

commit 40f8b74
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Thu Feb 23 04:00:50 2017 +0000

    Add package for Builder.Framework and Connector.AspNetCore.Mvc

commit e0710fe
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Thu Feb 23 03:06:22 2017 +0000

    Update autorest version in generateClient.cmd

commit 038d647
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Thu Feb 23 00:58:53 2017 +0000

    Add check for service provider registered on autofac composition
     - Add missing packages to samples
     - Fix authentication on AspNetCore project when secret is not provided

commit 72497b1
Author: iedeny <iedeny@microsoft.com>
Date:   Wed Feb 22 19:10:09 2017 -0800

    Add new AspNetCore.Mvc projects

commit 2421b93
Author: iedeny <iedeny@microsoft.com>
Date:   Wed Feb 22 12:33:45 2017 -0800

    Rename Connector.Abstractions folder back to Connector.Shared
     - Remove ApplicationInsights package from AspNetCore.Pizza sample
     - Consolidate packages to latest
     - Fix folder name in packaging script for Shared project
     - Fix remaining unit test failures
     - Consolidate assembly version

commit 30183de
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Wed Feb 22 02:25:39 2017 +0000

    Update nuget package creation

commit 1890960
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Wed Feb 22 00:30:29 2017 +0000

    Update System.Net.Http to 4.3.1

    This is required to address issue https://github.com/dotnet/corefx/issues/11100

commit f2bc432
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Thu Feb 16 23:43:11 2017 +0000

    Enable ASP.NET CORE usage with BotBuilder

     - Fix simple sandwich bot and add TODO comment
     - Improve Service resolution for multi-platform support
     - Remove remaining #IF NET45 compiler conditionals
     - Remove #IF NET45 conditionals merge from upstream

commit aa72e0f
Author: Andre Esteve <andreesteve@gmail.com>
Date:   Thu Feb 16 17:34:01 2017 +0000

    Add IBotConfiguration to abstract ConfigurationManager out of portable code

commit 64f3edc
Author: iedeny <iedeny@microsoft.com>
Date:   Wed Feb 15 15:54:34 2017 -0800

    Update System.Net.Http to 4.3.1

commit 2636a24
Author: iedeny <iedeny@microsoft.com>
Date:   Wed Feb 15 12:39:58 2017 -0800

    Remove xproj
    Add VS2017 solution to support netcore projects

commit 71f1189
Author: iedeny <iedeny@microsoft.com>
Date:   Wed Feb 15 11:37:04 2017 -0800

    Autofac now references common connector library

commit 094213e
Author: Yegor Denisov <yegor.denisov@gmail.com>
Date:   Mon Feb 13 03:13:00 2017 -0800

    Add AspNet Core pizza bot sample

commit c6b4f69
Author: Yegor Denisov <yegor.denisov@gmail.com>
Date:   Sat Feb 11 05:39:11 2017 -0800

    Convert AspNetCore Connector into portable library

     - Convert aspnet core connector to netstandard 1.4
     - Fix System.Net.Http binding

commit 0d590d4
Author: Yegor Denisov <yegor.denisov@gmail.com>
Date:   Sat Feb 11 04:44:41 2017 -0800

    Consolidate all nuget packages.
    Update all packages except Moq, Autofac and Castle.Core

commit d220e63
Author: Yegor Denisov <yegor.denisov@gmail.com>
Date:   Sat Feb 11 02:29:40 2017 -0800

    Convert shared Connector code into a separate library

commit ce39e2a
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Thu Feb 23 15:08:25 2017 -0800

    Removed node-uuid.
    We're not using it and it's deprecated.

commit 4bccc42
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Wed Feb 22 17:43:00 2017 -0800

    Moved locale files to output

commit ad2c98b
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Tue Feb 21 14:14:10 2017 -0800

    RegExpRecognizer fails on Node-RED
    - Added duck typing based check to constructor as instanceof doesn't work on Node-RED

commit f26b12f
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Tue Feb 21 10:57:02 2017 -0800

    Session.validateDialogStack() always succeeded.

commit c7e981a
Merge: 99bd9ce a8cbef0
Author: Steven Ickman <stevenic@microsoft.com>
Date:   Wed Feb 22 17:40:38 2017 -0800

    Merge pull request #2026 from saveriopalmieri/master

    New locale (PT - Portuguese) for NodeJs BotBuilder

commit 99bd9ce
Author: Andrea-Orimoto <andreo@microsoft.com>
Date:   Tue Feb 21 14:52:32 2017 -0800

    Update ISSUE_TEMPLATE

commit ea0ed7d
Author: Andrea-Orimoto <andreo@microsoft.com>
Date:   Tue Feb 21 14:47:14 2017 -0800

    Create ISSUE_TEMPLATE

commit 16dd579
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Thu Feb 16 16:40:16 2017 -0800

    Updated build process
    - Build now builds directly to live.
    - botbuilder.d.ts & locale files are only in lib.

commit 15a6ded
Author: Steve Ickman <stevenic@microsoft.com>
Date:   Thu Feb 16 16:39:13 2017 -0800

    Added support for intent forwarding.

commit b47dab3
Merge: 8542c89 6f3a08c
Author: Chris McConnell <chrimc@microsoft.com>
Date:   Fri Feb 17 11:44:45 2017 -0800

    Merge pull request #2212 from ArtisanDuCode/master

    Fixed Caps non Non

commit 8542c89
Author: Shahin Shayandeh <shahins@microsoft.com>
Date:   Thu Feb 16 16:41:35 2017 -0800

    Update assembly versions to 3.5.3

commit 497252e
Merge: c769a9f 9ae4978
Author: Shahin Shayandeh <shahins@microsoft.com>
Date:   Thu Feb 16 16:31:16 2017 -0800

    Merge branch 'develop'

commit 6f3a08c
Author: Un artisan du Code <lartisanducode@gmail.com>
Date:   Wed Feb 8 19:49:29 2017 +0100

    Fixed Caps non Non

commit c769a9f
Author: Shahin Shayandeh <shahins@microsoft.com>
Date:   Tue Feb 7 12:53:39 2017 -0800

    Update bot.builder assembly version to 3.5.2

commit 8cd6598
Author: Shahin Shayandeh <shahins@microsoft.com>
Date:   Tue Feb 7 13:00:30 2017 -0800

    Update persian resource file with the resource file generated by multilingual app tool

commit 387e7e5
Author: Behnam Emamian <emamian@persianprocess.com>
Date:   Wed Feb 8 07:55:56 2017 +1100

    Fixing persian resources. (#2020)

    * Fixing persian resources.

    * Fixing persian resources

commit a8cbef0
Author: Saverio Palmieri <Saverio Palmieri>
Date:   Thu Jan 12 20:26:29 2017 -0200

    Small typos.

commit 56e6aab
Author: Saverio Palmieri <Saverio Palmieri>
Date:   Thu Jan 12 19:58:47 2017 -0200

    Added locale files for PT (Portuguese) language
@dmcweeney
Copy link

@dmcweeney dmcweeney commented Mar 23, 2017

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
Copy link

@parismiguel parismiguel commented Mar 25, 2017

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
Copy link
Member

@karelz karelz commented Mar 25, 2017

@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
Copy link

@parismiguel parismiguel commented Mar 25, 2017

@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
Copy link
Member

@davidsh davidsh commented Mar 25, 2017

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

@parismiguel
Copy link

@parismiguel parismiguel commented Mar 25, 2017

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?

image 1

@karelz
Copy link
Member

@karelz karelz commented Mar 25, 2017

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
Copy link
Member

@karelz karelz commented Mar 25, 2017

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
Copy link
Member

@karelz karelz commented Mar 25, 2017

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
Copy link
Member

@karelz karelz commented Mar 25, 2017

To everyone: I have created a new issue dotnet/corefx#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
Copy link

@parismiguel parismiguel commented Mar 25, 2017

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

@karelz
Copy link
Member

@karelz karelz commented Mar 25, 2017

@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
Copy link

@parismiguel parismiguel commented Mar 25, 2017

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
Copy link

@Workshop2 Workshop2 commented May 15, 2017

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
Copy link
Member

@karelz karelz commented May 15, 2017

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)

LHCGreg referenced this issue in LHCGreg/mal-api Jul 8, 2017
See https://github.com/dotnet/corefx/issues/11100.

If a .NET 4.6 app references a package that uses System.Net.Http, it
would get:

Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 1.1.x milestone Jan 31, 2020
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Dec 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet