.Net Plaform Standard implementation on .Net 4.6.1 has version inconsistency for System.Net.Http

[andriysavin]

I created a netstandard1.4 library (csproj) which uses System.Net.Http, and the highest available netstandard1.3 listed in NETStandard.Library meta package references System.Net.Http v4.1.0.
I reference this library from a .Net Core console app which targets net461, and the latter has System.Net.Http v4.0.0.0 in GAC. During build I get a warning regarding library versions conflict, and at run time get a FileNoFoundException: "Could not load file or assembly 'System.Net.Http, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies."
Also, in project references (in solution explorer) System.Net.Http v4.0.0 is shown. This looks pretty confusing, since I expect that once I referenced NETStandard.Library and target netstandard, I should not care about such versions consistency, since .NET Platform Standard docs claim that netstandard 1.4 is supported by net461 and higher, and netstandard 1.3 is supported by net46 and higher.

UPDATE: I was also able to reproduce this problem when the library is xproj-based.

Here is the link to the sample project which reproduces the bug

[davidsh]

cc: @ericstj @stephentoub @CIPop

One thing to keep in mind is that with the System.Net.Http 4.1 NuGet package, System.Net.Http is completely an OOB package. Even on .NET Framework (Desktop), using the System.Net.Http 4.1 package replaces the use of the .NET Framework System.Net.Http binary in the GAC. This is unlike most of the other CoreFx packages on Desktop which are facades and actually use the GAC'd binaries.

We OOB'd System.Net.Http in CoreFx in order to provide a more expansive API surface that would work against .NET Standard 1.3 and above.

I'm not sure if this totally relates to the problem you are experiencing but it might be related to the version conflicts you appear to see.

[andriysavin]

@davidsh I see what you mean. But what I see in reality is slightly different. I tried to change library target to netstandard1.2 (which also references System.Net.Http v4.1.0 in metapackage), and in this case all works (no exception at run time). However, in spite of what you say, I observe (in Modules) that System.Net.Http v4.0.0 is loaded from GAC. So in both cases System.Net.Http v4.1.0 is not present. This frustrates me even more.

[neoaisac]

I have an old project (C#, .Net 4.6.1). We replaced at one moment the references to System.Net.Http for the NuGet package (v4.1.0.0) but when trying to create new HttpConfiguration() it would invariably fail when trying to create the JsonMediaTypeFormatter internally.

The internal error is actually thrown when the JsonMediaTypeFormatter constructor tries to get the JSON MediaTypeHeaderValue which is generated via cloning. The error message is reproduced below:

[VerificationException: Method System.Net.Http.CloneableExtensions.Clone: type argument 'System.Net.Http.Headers.MediaTypeHeaderValue' violates the constraint of type parameter 'T'.]
System.Net.Http.Formatting.MediaTypeConstants.get_ApplicationJsonMediaType() +0
System.Net.Http.Formatting.JsonMediaTypeFormatter..ctor() +79
System.Net.Http.Formatting.MediaTypeFormatterCollection.CreateDefaultFormatters() +49
System.Web.Http.HttpConfiguration..ctor(HttpRouteCollection routes)
...

The requirement the error is talking about is clear in the implementation of CloneableExtensions which is here: http://aspnetwebstack.codeplex.com/sourcecontrol/latest#src/System.Net.Http.Formatting/CloneableExtensions.cs. The restriction is that the MediaTypeHeaderValue must implement ICloneable; or to be more specific mscorlib's System.ICloneable.

It seems that there may be a problem with this interface in the transition to corefx (.NET Core 1.0). The problem (I think, I may be wrong) may be related to the fact that System.Net.Http as of .NET Core defines its own ICloneable interface here: https://github.com/dotnet/corefx/blob/d0dc5fc099946adc1035b34a8b1f6042eddb0c75/src/System.Net.Http/src/Internal/ICloneable.cs.

The comments of that file show the following:

// Implement ICloneable internally.  
// We aren't concerned with exposing this type for lightup on platforms that support ICloneable.
// ICloneable is an unsupported type.

The problem is that this interface is not within a #if #endif block, that targets only .NET Core targets. Thus, if someone (like me) goes to NuGet and uses the System.Net.Http package (version now 4.1.0.0, here: https://www.nuget.org/packages/System.Net.Http/) when using it with the above we will have that error because there are two ICloneable interfaces, and the one expected by the CloneableExtensions class is not the implemented by the System.Net.Http 4.1.0.0 package.

If I'm wrong, I apologise. I hope I'm bringing some light on to this.

[davidsh]

If you are having trouble with System.Net.Http.Formatting APIs, that is not part of CoreFx proper and is not part of the System.Net.Http NuGet package. Those are extension APIs that the asp.net team use and maintain.

So, perhaps you might want someone from the asp.net team to help investigate this.

cc: @davidfowl @danroth27 @stephentoub

[neoaisac]

Maybe I didn't express myself with clarity before.

When we use .NET's 4.6.1 out-of-the-box version of System.Net.Http (v4.0.0.0) everything works fine with the System.Net.Http.Formatting library.

When we use the corefx version (v4.1.0.0) via NuGet, it fails. The error is the one above, hinting that the ICloneable interface is not the same because it does not fulfill the type parameter constraint at CloneableExtensions.

When we revert to v4.0.0.0 things start working again.

Therefore, v4.1.0.0 distributed by NuGet of the System.Net.Http dll is not an OOB package as it breaks compatibility with other packages that, when using v4.0.0.0, work fine.

I'd love to use NuGet's version and get earlier and faster updates, but we can't because of this.

[andriysavin]

@isaacllopisaracil I feel your pain. However, the problem I described originally is different: its not about differences of assemblies, its about finding the assembly. The app crashes at time of JIT-compiling the code which references something from the System.Net.Http (e.g. HttpClient), failing to find and load the assembly.

[neoaisac]

I see that. I will create a new one specifically for this, then, if that's better.

This said, the abovementioned issue was exactly the same one we had when trying to revert to v4.0.0.0 after finding out that v4.1.0.0 is not an OOB package. Visual Studio kept the 4.1.0.0 references even though all NuGet package references and assembly redirections had been removed. The only workaround was to remove the reference altogether and add it again from the installed .NET 4.6.1 set of DLLs in every project using it.

[colin-young]

I seem to be encountering something similar. I've got a set of libraries all build targeting net4.5.2 and I can run those fine in their test harnesses (usually console exe) and unit tests. I am not trying to consume a number of them in a console exe that provides a SignalR hub, targeting net4.5.2. I can build fine (ignoring the version conflicts for now which have to do with Owin and Http), at runtime I get the same could not load file or assembly error, but in my case it is System.ComponentModel.TypeConverter. When I look in the bin folder, I see that DLL there, but inspecting it with PowerShell ([System.Reflection.Assembly]::LoadFrom("...").GetName().Version) I see it is version 4.0.0.0. Looking at the source for that assembly it appears as though the packaging is different between 4.5 and 4.6. Inspecting the NuGet package itself confirms that the net452 folder has version 4.0.0.0 while net462 contains version 4.1.0.0.

What is most odd about it is that the test harness for one of the libraries shows version 4.0.0 of the type converter assembly in the bin folder and it runs just fine.

[ericstj]

4.1.0.0 is the expected version. Try adding a binding redirect to solve the file-not-found at runtime.

Solution explorer is likely showing some direct assembly reference (eg: simple name reference or FrameworkAssembly reference from a NuGet package) this gets trimmed by targets that run at build. /cc @jasonmalinowski

From: colin-young [mailto:notifications@github.com] Sent: Thursday, July 7, 2016 8:57 AM To: dotnet/corefx corefx@noreply.github.com Cc: Eric St. John Eric.St.John@microsoft.com; Mention mention@noreply.github.com Subject: Re: [dotnet/corefx] .Net Plaform Standard implementation on .Net 4.6.1 has version inconsistency for System.Net.Http (#9846)

I seem to be encountering something similar. I've got a set of libraries all build targeting net4.5.2 and I can run those fine in their test harnesses (usually console exe) and unit tests. I am not trying to consume a number of them in a console exe that provides a SignalR hub, targeting net4.5.2. I can build fine (ignoring the version conflicts for now which have to do with Owin and Http), at runtime I get the same could not load file or assembly error, but in my case it is System.ComponentModel.TypeConverter. When I look in the bin folder, I see that DLL there, but inspecting it with PowerShell ([System.Reflection.Assembly]::LoadFrom("...").GetName().Version) I see it is version 4.0.0.0. Looking at the sourcehttps://github.com/dotnet/corefx/blob/master/src/System.ComponentModel.TypeConverter/pkg/System.ComponentModel.TypeConverter.pkgproj for that assembly it appears as though the packaging is different between 4.5 and 4.6. Inspecting the NuGet package itself confirms that the net452 folder has version 4.0.0.0 while net462 contains version 4.1.0.0.

What is most odd about it is that the test harness for one of the libraries shows version 4.0.0 of the type converter assembly in the bin folder and it runs just fine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/corefx/issues/9846#issuecomment-231123422, or mute the threadhttps://github.com/notifications/unsubscribe/AIgUXGQ2FQvlm1Iahq8TaQzV9zIWYO7mks5qTSGxgaJpZM4JE8Nf.

[colin-young]

Thanks! This:

  <dependentAssembly>
    <assemblyIdentity name="System.ComponentModel.TypeConverter" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.1.0" newVersion="4.0.0.0" />
  </dependentAssembly>

did the trick. The existing binding tried to map to 4.0.1.0 instead. It appears that it was added automatically when I updated NuGet references to the RTM bits, since my csproj has AutoGenerateBindingRedirects set to true. I can't figure out where the redirection versions are defined, so I'm not entirely sure where the source of the problem is.

For the record, Solution Explorer isn't showing TypeConverter at all. It's Windows Explorer where I found the DLL. It's included transitively from Microsoft.Extensions.Configuration.Binder.

[davidsh]

@ericstj is there any future action item for this issue or should it be closed now? Is this the experience we expect moving forward for developers? Or is there some improvement we might make (tooling, packages, etc.) to this overall experience of binding redirects confusion.

[andriysavin]

@davidsh If to make .NET Platform Standard code working correctly on every platform developers will have to do tricks with binding redirects, it will be worst experience ever. This will break the idea of transparent code portability. Not to say that in most cases these errors won't be detected until run time (if redirects are not added during package installation).

So far, based on previous posts, to me the problem lies in that the tooling doesn't give priority to the System.Net.Http from the package. For some reason it thinks its OOB (GAC) and should not be copied to the output. If GAC's version of the assembly is different to one in the package (apparently it is according to said earlier), I don't see how binding redirect can safely fix the problem.

[ericstj]

I do have a related issue here: https://github.com/dotnet/corefx/issues/7702. In that issue I suggest trying a workaround package that forces the auto-generate binding redirects in MSBuild to see a conflict. Try that and see if it works for this case.

The place to examine binding redirects written by the build is in the *.exe.config in your output directory.

If you're seeing that NuGet is modifying the app.config in your source directory, that may be the problem (potentially NuGet bug). If you have an existing binding redirect in source the auto-generated one will not take precedence.

[andriysavin]

I tried AutoGenerateBindingRedirects and it gave no result, an app.config is not even created during build. I guess this is because of xproj.

[DaveAurionix]

Going back to the original post, and apologies if I've missed some detail since then ... I get the same error. If I create a netstandard1.4 class library and add a dependency on the System.Net.Http 4.1.0 nuget package, and then reference the netstandard1.4 class library from a net461 console application, I get a runtime error "could not load file or assembly System.Net.Http version 4.1.0".

Looking into project.lock.json for the net461 console app, it seems that inside the System.Net.Http 4.10 nuget package there is a frameworkAssemblies reference added to system.net.http 4.0.0 (in the GAC) which I believe is incorrect. It means that the correct System.Net.Http 4.1.0 DLL is not referenced and therefore is not copied to the output folder, causing the runtime error.

Again, apologies if the discussion has demonstrated that the frameworkReference to s.net.http 4.0.0 is actually correct ... but on the surface the nuspec file for system.net.http 4.1.0 looks possibly buggy for net461 case (and other desktop-framework cases).

[clairernovotny]

Can this be fixed in the 1.0.1 patch that was blogged about instead of waiting for the fall in 1.1? This is really painful.

[davidsh]

This issue is really a duplicate of https://github.com/dotnet/corefx/issues/9884 and we are working on a fix. We hope to fix it in the next few weeks. Not sure if that will make 1.0.1 though.

[clairernovotny]

@davidsh Is it the same thing? As I read the other bug, it was about a missing ICloneable interface. The core issue here is that System.Net.Http isn't being copied to the output directory even when indirectly referenced.

So I have a Netstandard 1.4 PCL that uses HttpClient and I use that in my net461 website. The Sys.Net.Http isn't there at all?

If it's the same issue, then great...but I really would hope this can make 1.0.1 because the fix isn't obvious and HttpClient is a really common type.

[davidsh]

They are related issues. Once we fix the System.Net.Http 4.1 package to link against mscorlib, we will also put back ICloneable (since it is available on "Desktop"). The combination of these fixes will fix the whole problem.

The separate issue of ICloneable not being in CoreFx is being handled separately. That will make pure CoreFx scenarios work better once ICloneable is back in the libraries. But that doesn't impact this issue directly on Desktop, per se.

But the fix needed for System.Net.Http 4.1 package is to "recompile" it for net46 target so that it behaves like a desktop assembly, i.e. using reference assemblies mscorlib and not System.Runtime.

[ameno-]

@davidsh we've run into this exact same issue. Are you still targeting this fix for 1.0.1

[galich]

I do not pretend I understand much on priorities and schedules, but as of today we can't use System.Net.Http 4.1 in .NET Standard 1.4 library. I was under impression that standard is released and works on .NET 4.6.1.

Milestone 1.2.0 tells me April 2017, that's like 8 months in the future. What do we do? Is there a workaround?

[davidsh]

This should be fixed now with dotnet/corefx#10716.

[ericgrover]

So when you say this is fixed now with dotnet/corefx#10716, when will we see an update in the nuget package for this? I hate that nuget has plunged us all back to DLL hell.

[davidsh]

The fix is available as a NuGet package now but only in the MYGET CoreFx dev feed right now.

https://dotnet.myget.org/gallery/dotnet-core

You will also need to explicitly list the System.Net.Http package in your project.json so that it pulls in the latest version from the dev feed:

https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

i.e.

"System.Net.Http": 4.1.1-beta-24422-01,

[galich]

DLL hell.

@ericgrover i feel the same, we have package hell now. Feeds, packages, broken references - that is our major headache now.

@davidsh thanks for clarifications, I'd love to give it another try 😉

[clairernovotny]

@davidsh I'm getting an error with that beta package now:

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.

[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.]
   Microsoft.Owin.Security.OpenIdConnect.OpenIdConnectAuthenticationMiddleware.ResolveHttpMessageHandler(OpenIdConnectAuthenticationOptions options) +0
   Microsoft.Owin.Security.OpenIdConnect.OpenIdConnectAuthenticationMiddleware..ctor(OwinMiddleware next, IAppBuilder app, OpenIdConnectAuthenticationOptions options) +2006
   lambda_method(Closure , OwinMiddleware , IAppBuilder , OpenIdConnectAuthenticationOptions ) +83

[TargetInvocationException: Exception has been thrown by the target of an invocation.]
   System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) +0
   System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) +160
   System.Delegate.DynamicInvokeImpl(Object[] args) +117
   System.Delegate.DynamicInvoke(Object[] args) +12
   Microsoft.Owin.Builder.AppBuilder.BuildInternal(Type signature) +365
   Microsoft.Owin.Builder.AppBuilder.Build(Type returnType) +42
   Microsoft.Owin.Host.SystemWeb.OwinAppContext.Initialize(Action`1 startup) +923
   Microsoft.Owin.Host.SystemWeb.OwinBuilder.Build(Action`1 startup) +136
   Microsoft.Owin.Host.SystemWeb.OwinHttpModule.InitializeBlueprint() +159
   System.Threading.LazyInitializer.EnsureInitializedCore(T& target, Boolean& initialized, Object& syncLock, Func`1 valueFactory) +115
   System.Threading.LazyInitializer.EnsureInitialized(T& target, Boolean& initialized, Object& syncLock, Func`1 valueFactory) +72
   Microsoft.Owin.Host.SystemWeb.OwinHttpModule.Init(HttpApplication context) +104
   System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +567
   System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +218
   System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +370
   System.Web.HttpApplicationFactory.GetPipelineApplicationInstance(IntPtr appContext, HttpContext context) +102
   System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +265

[HttpException (0x80004005): Exception has been thrown by the target of an invocation.]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +751
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +150
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +245

[davidsh]

@onovotny Please open a new issue. The problem now is specific to the .NET Framework (Desktop) System.Net.Http.WebRequestHandler inbox reference assembly/contract now being incompatible with the OOB'd System.Net.Http 4.1 package.

Please attach a small repro solution. We need to understand which component is trying to reference the System.Net.Http.WebRequestHandler assembly.

[robertmclaws]

@terrajobst Any idea when this can be dealt with? Since it's a blocking production issue I think it probably needs to be prioritized. Thanks!

[weshaggard]

@weshaggard @ericstj looking at System.Runtime.Serialization.Primitives 4.3.0.0 NuGet package:
In lib\net46 directory there is System.Runtime.Serialization.Primitives.dll (assembly version 4.1.2.0), i.e. overriding the 4.0.0.0 inbox version. Is that sign that we have more than the 2 assemblies overriding inbox assemblies?

Yes that one does override the desktop implementation and we can have a further look at it. It didn't show up in your check because it is a little different from the other 2. The difference with this one is that System.Runtime.Serialization.Primitives is a pure facade on desktop so it isn't really overridding any functionality just adding some.

[karelz]

@weshaggard did you mean that it is NOT pure facade?
If it is pure facade, it can't ADD things. Or am I missing something (again)? :)

Also, can you please confirm if this is the last OOB package in CoreFX that overrides Desktop? Or do we have more?

[karelz]

I filed dotnet/corefx#16804 to stop shipping the OOB package.

[weshaggard]

@weshaggard did you mean that it is NOT pure facade?

It is a pure facade inbox on the framework but the one in the OOB package it adds some things that ship in the OOB package. See https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Serialization.Primitives/src/System.Runtime.Serialization.Primitives.csproj#L41 which is the addition of an interface to this library.

We can continue the other discussion at the new issue you filed.

[karelz]

BTW: I filed dotnet/corefx#16823 to review all NuGet packages in CoreFX we ship as Desktop replacements.

@JohnGalt1717 it still does not cover the IdentityModel packages - please follow up on their repos (I personally don't know where they are).

[JohnGalt1717]

I have. And they're now independently fixing. However the issue is that MS as a company is releasing broken stuff without testing it across all platforms that they're supposedly supporting and ensuring it doesn't break stuff when they use the same nuget package. This is a fundamental issue in the entire development team that should be dealt with company-wide.

[karelz]

@JohnGalt1717 yes, we have a test gap on Desktop OOB packagers in CoreFX repo. It does not mean the entire CoreFX or entire company goes untested. These are one off mistakes we as larger .NET team made. The intentions were good - deliver value to customers. Sadly the complexity of CoreFX and the test matrix is so huge that folks shipping those packages didn't realize we are missing testing of certain platform combos.
The important thing is that we react quickly when we understand the underlying problem.

[JohnGalt1717]

Well given the scope of all of the problems and the YEAR + it has taken to this point, I think the team should take this as an abject failure and start some navel gazing so that this doesn't happen again and that there is a strategy to fix this stuff WAY faster.

[karelz]

@JohnGalt1717 I agree that we need shorter time to response on high-impactful problems. Some kind of escalation path. GitHub doesn't have anything like that built-in (beyond votes or monitoring entire repo) - note that this bug does not have any clear indication that it is high-impactful issue, unless you read all the replies, moreover it is closed!
Same goes for dotnet/corefx#11100, it was not widely understood it is high-pri, until it started spin up lots of replies and some angry replies. Even in that case we depend on someone to notice and escalate internally "to the right people". There is no clear guidance how to do that for community :(. I plan to cover all that in the dotnet/corefx#11100 post-mortem.
If you think we need separate discussion on that topic here, please let me know.

[JohnGalt1717]

As long as it's going to be dealt with so that this doesn't happen again I'm good. I'm just staring at about 7 full person-days of wasted time over the past year on this so I need to know that someone is taking this seriously and I'm not going to have to run from group to group getting them to do the right thing anymore.

[karelz]

I am interested in details about your "7 full person-days wasted on this". That is valuable feedback and I can use it to convince others to do the right thing (set the priority). Can you write a short high-level description with estimates of the wasted time? It would be very useful for me.

If you want to help that way, I would suggest to start with shorter description first - I can ask for details in replies if needed. Please target the description high-level (from VS user perspective) to people who didn't hit the problem. Thank you!

[JohnGalt1717]

1. Because modules like System.Net.Http were not properly tested against .NET Full the same Nuget Package was used and marked as still marked as compatible with .NET Full. As a result of this, updating the package resulted in broken code.
2. Because of the delays in getting the issues fixed with these modules, every time you ran nuget (update to this module or not!) and got updates in VS.net, the BindingRedirects that were the only solution while we waited endlessly got updated every time to the wrong values.
3. Because of the wrong values getting put into binding redirects constantly and us missing them by accident we deployed code that didn't work and would crash as a result. This caused us to have to do work to fix the result in data of the crashes. (before we figured out what was going on and put in tests to validate that they were right)
4. As time progressed more and more 3rd party modules depended upon these modules forcing us into standing on our heads to try and make everything work to be able to use these updated 3rd party modules.

All told this is at least (probably way more) 7 developer days wasted trying to sort this out in the first place and then dealing with the fall out while it took a year plus to fix problems (and there are still items outstanding with IdentityModel tokens) that should never have existed if proper testing was done. In the case of IdentityModel.Tokens there is entire functionality missing yet the module is claimed to be compatible with .NET 4.5+.

The lack of urgency for the mess that was being created and complete disregard for the consequences of actions is stunning and needs to never happen again. You're not Apple and you can't treat people like crap and have them love you for it.

[tofutim]

we wasted 3 full person days on this

…

On Thu, Mar 9, 2017 at 10:27 AM, James Hancock ***@***.***> wrote: 1. Because modules like System.Net.Http were not properly tested against .NET Full the same Nuget Package was used and marked as still marked as compatible with .NET Full. As a result of this, updating the package resulted in broken code. 2. Because of the delays in getting the issues fixed with these modules, every time you ran nuget (update to this module or not!) and got updates in VS.net, the BindingRedirects that were the only solution while we waited endlessly got updated every time to the wrong values. 3. Because of the wrong values getting put into binding redirects constantly and us missing them by accident we deployed code that didn't work and would crash as a result. This caused us to have to do work to fix the result in data of the crashes. (before we figured out what was going on and put in tests to validate that they were right) 4. As time progressed more and more 3rd party modules depended upon these modules forcing us into standing on our heads to try and make everything work to be able to use these updated 3rd party modules. All told this is at least (probably way more) 7 developer days wasted trying to sort this out in the first place and then dealing with the fall out while it took a year plus to fix problems (and there are still items outstanding with IdentityModel tokens) that should never have existed if proper testing was done. In the case of IdentityModel.Tokens there is entire functionality missing yet the module is claimed to be compatible with .NET 4.5+. The lack of urgency for the mess that was being created and complete disregard for the consequences of actions is stunning and needs to never happen again. You're not Apple and you can't treat people like crap and have them love you for it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/dotnet/corefx/issues/9846#issuecomment-285436871>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJoRlY6dSRhbAgGiops5sOexcRstrnGks5rkER7gaJpZM4JE8Nf> .

[ccicchitelli]

One day here...but I got lucky in that this thread existed so I found it when googling around for System.Net.Http. For those with similar DLL issues in other modules, they had no reference point.

[galich]

I'm not bothered to count how much time wasted on this, enough to say we wasted a lot more than we should have. It also taught us that NuGet updates are pain and we are more conservative now.

[galich]

@karelz actually I've got a suggestion you might want to pass to the right ears:

Add a button on docs.microsoft.com next to each class/method documentation to report problems and up vote them.

We've made a build, it works on our machines, we deployed it and users started to tell us that things are going wrong. After a while we received FileLoadException with poor reference that System.Net.Http.dll is of wrong version, but it took some time to figure out what platform inconsistency it was and it's next to impossible to track down which library pulled what and which class refers to that broken reference. So there is definitely something to be done about quick diagnostics of such issues, it won't be last time we have this conversation, get prepared ;)

[gimlichael]

@karelz all-in-all, errors related to .NET Platform Standard, .NET Core, UAP and your colleagues constant switching between terms, concepts, standards and what not, I would give a qualified guess of at least 40 hours+ of experience (i will not consider it wasted; annoying, but not wasted).

This is in no way an attack on you as a person; I believe the path you overall has chosen with .NET Standard and Core is an excellent choice - the road for early movers has just been dreadful.

I hope you and your colleagues (just like myself) have learned from this.

On a plusside, I am able to help my colleagues that do not understand why something that should work, does not work.

Like the other users in this thread; everything above 3 months fix time is uacceptable; it should be less than 4 weeks time IMO.

That being said; thank you for the hard work and eventually fix of the problems we have/are experiencing. It is nice to be in touch with you guys eventhough the circumstances are unfortunate.

[bgever]

CC:@karelz

We've been hitting this issue for months now, and it's been definitely several full-time days of headache.

Worst is, it creeps up at the worst possible moment: runtime! No build-time warnings, the whole thing blows up unexpectedly. Sometimes it works on our dev machines, and then it blows up when we deploy to a cloud service (with the instance keeping recycling due to it happening at startup). This is by FAR the worst ever issue that keeps recurring, and there is no end in sight. We've had to postpone deployments because of these problems, affecting the schedule of our software features.

We have trouble with the AAD libraries a lot; Azure KeyVault, the AAD Identity JWT lib, Http 4.0+, and Primitives 4.0+. Because our shared authentication libraries use these, the issue has happened in almost all of our 6+ solutions, having affected 6 people on the team.

The people on our team who have managed to get their solutions to run stable are considered sorcerers of app.config binding redirects and NOBODY dares to touch those. Who wants to be responsible for the next runtime explosion when the customer tries to place an order?!

THIS ISSUE IS VERY REAL! And it's making me wanting to throw my computer out of the window sometimes, but heck, I can't do that because we have a business to run and code to ship! 😠

Is that enough for setting priority? Please, please, please fix this mess!

[TheSamsterZA]

@davidsh @karelz This needs to be reopened and escalated as high up as possible IMO. The impact of these issues are far-reaching and costing everyone time and money.

@karelz I think it would be a good idea to collate and outline very clearly what the issues are and what the plan is in order to fix this, similar to what you did with https://github.com/dotnet/corefx/issues/11100.

[karelz]

@TheSamsterZA I am working on that. Overall feedback on impact is actually very useful for me to explain other team members and higher management that it matters A LOT.

I think we should not reopen this particular issue, I think this is bigger problem than just System.Net.Http. IMO we need a new general issue to track automatic bindingRedirects. I'll try to get to it in next couple of days (it's near the top of my TODO list). I will make sure to reference all the proof of pain from here (extremely valuable!).

[bgever]

@karelz Thanks a lot. Is there any way we can help? Test cases, etc?

[karelz]

For a starter, it would help greatly if you can check if this https://msdn.microsoft.com/en-us/library/2fc472t2(v=vs.110).aspx helps (in all cases).
If it doesn't, we can start exploring how to enable it by default.