Runtime: .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:[email protected]]
Sent: Thursday, July 7, 2016 8:57 AM
To: dotnet/corefx [email protected]
Cc: Eric St. John Eric.St.[email protected]; Mention [email protected]
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.

c# "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 :wink:

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

[jkells]

I see mentions of binding redirects and beta packages in this thread, what is the official workaround? Should I be using the beta package or doing a binding redirect?

[nrjohnstone]

The problem I find now is that everytime I fix the issue by changing the binding redirect to prevent v4.0 being redirected to 4.1.0.0 like this

bindingRedirect oldVersion="4.1.0.0-4.1.0.0" newVersion="4.1.0.0"

as soon as anyone does a nuget package update in the solution then it changes the redirect back to 0.0.0.0-4.1.0.0 which breaks everything again !

[jbarden]

Like many of the comments above, I updated to the latest NuGet packages and was disappointed but unsurprised to still have the issue. However, whilst not a "Fix", I did find that the Microsoft.IdentityModel.Clients.ActiveDirectory package (V3.13.7) still installs System.Net.Http but it is possible to simply uninstall it - everything still works.

[aggieben]

I have a project (say, "Web") which targets net461 and references another project ("Library"), which targets netstandard1.3 and depends on NETStandard.Library 1.6.1 (which pulls in System.Net.Http 4.3.0), and I'm experiencing this issue ("Could not load file or assembly 'System.Net.Http, Version=4.1.1.0, ...'").

[jkells]

@aggieben place this in your app.config or web.config and pray that you don't use any of the API after version 4.0.0

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="4.1.1.0" newVersion="4.0.0.0"/>
      </dependentAssembly>
  </runtime>
</configuration>

[aggieben]

@jkells thanks for the suggestion, but I've already tried that :-( Here's my App.config in the same directory as my project.json:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="System.Net.Http" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
                <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

I haven't looked at Fusion logs yet, so that'll be my next stop.

[jkells]

@aggieben I sent you a message on the ASP.NET Slack

[aggieben]

thanks to some tips from @jkells, I found another project-to-project dependency that was pulling in IdentityModel 2.4.0, which has a frameworkAssembly reference to System.Net.Http.

[mcm-ham]

@aggieben Does your app.config live inside a Class Library project? If so it will have no effect, add this change to the project building the application that references the Class Library project.

Seems partially fixed, new workaround
Installing the latest version of System.Net.Http and System.Runtime.Serialization.Primitives nuget package in the project that builds the exe fixes it for me without the binding redirect trick (that keeps reverting every time there's a nuget package change). It seems without doing this the dll does not appear in the build output. Is this caused by projects referencing version 4.0.0.0 that appear earlier in the build process?

Update:
Still having problems with System.Runtime.Serialization.Primitives in Classic Azure Cloud Service Worker Role for some reason though it works for our ConsoleApp hosting the OWIN app, so having to revert binding redirects back to 4.0.0.0. System.Net.Http appears to be working after installing the nuget package to ensure dll is copied to build output, although we're now running into dotnet/corefx#11100 for a few services.

[JohnGalt1717]

This is still an issue. System.Runtime.Serialization.Primatives is the new culprit of choice now throwing errors. Not sure if System.Net.Http is still an issue but probably is, it just hits that one first now on execution. You guys really need to get ALL of these just working properly in .NET 4.6.x so we don't have to play this dance every time we use nuget to fix this stuff.

[galich]

We've updated referenced packages recently and our MSI build tool started to pick up tons of new DLLs we never needed before. Frankly, having seconds thoughts of if that whole .net core idea is a good one. Permanent issues with HTTP, frequent issues with string.Normalize(), dll hell replaced with package hell that produces dll hell...

Each update is a lottery and i don't feel like a winner. We used to be able to build one .exe and run it on Win7-Win10 out of the box.

[ccicchitelli]

Hello, I believe we've come across this issue as well in System.Net.Http. We've long used it for accessing System.ServiceModel.Channels.Message to use the ToHttpRequestMessage method (as part of our web service authentication process with custom headers). When we upgraded our app to .NET 4.6, this issue started happening. All Nuget packages are up to date as well. (As a side note, I'd point out we usually trail the latest .NET releases by a year or two _specifically_ to avoid this kind of issue.)

The specific error we're getting is as follows:

An exception of type 'System.TypeAccessException' occurred in redacted.exe but was not handled in user code

Additional information: Attempt by security transparent method 'System.ServiceModel.Channels.MessageExtensionMethods.ToHttpRequestMessage(System.ServiceModel.Channels.Message)' to access security critical type 'System.Net.Http.HttpRequestMessage' failed.

Assembly 'System.ServiceModel.Channels, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' is marked with the AllowPartiallyTrustedCallersAttribute, and uses the level 2 security transparency model. Level 2 transparency causes all methods in AllowPartiallyTrustedCallers assemblies to become security transparent by default, which may be the cause of this exception.

I've spent a few hours researching this and the closest I could find is this thread. I've tried various config changes, at both the assembly and .config levels, including those listed here, as potential workarounds but none restored the functionality.

I'd appreciate any suggestions on how to enable a workaround, as we do not need the latest features and are find running the 4.0 DLL in our 4.6 app if that is possible.

TIA!!

[chadwackerman]

Wow, this is bad. I just spent months raising my voice two standard deviations beyond what open source traditionally tolerates in order to get another Sev 1 blocking bug even looked at: https://github.com/dotnet/corefx/issues/11100

Six months later and that production blocking bugfix still hasn't shipped because the overloaded manager himself chooses to be blocked waiting to hear back from some nonsense dependency library with 150 downloads.

And now I see the next problem here waiting to bite me after the other one finally ships.

It is very clear that tests were not written for these components. It is also very clear that the devs are continually shocked by the avalanche of dependencies they unravel as they stumble through this .NET Core rewrite.

I sympathize but people inside Microsoft seem oblivious to the pain they are causing developers. In the event they even see the bug among all the noise here at GitHub (which is simply not designed to handle a project like this) it still takes months for them to ship a fix because of internal mismanagement or tooling problems.

The corefx team finally posted a binary and I couldn't even download it because it's being served up from an overloaded server in Belgium by a company called Tech Tomato. @karelz pops in and says that's the server the whole .NET team uses all day every day and that it works great for him, even over WiFi from Starbucks.

I scratch the surface and it turns out NuGet is downloading 25MB of json and consuming enough memory parsing it to reproducibly crash Visual Studio. In order to update a 178k DLL from Monday night's build to Tuesday night's build. I'm really the first person to notice this? Wow. https://github.com/NuGet/Home/issues/4448

Something ain't right in Redmond these days.

[JohnGalt1717]

Concrete data:

System.net.http and primatives is now OK in ASP.net apps. However you still have to do the whole binding redirect for any unit test projects.

Please get this fixed. It's becoming aajor time suck for no reason because you had to have seen this coming when you built .Net standard.

[galich]

i wonder if there is a way to reopen this issue? or nobody from .net core team is looking here

[chadwackerman]

@JohnGalt1717 binding redirects are also required for the System.Net.Http problem even after the new version ships. Also the package version doesn't match the assembly version so factor that into the chaos as well.

you had to have seen this coming when you built .Net standard.

They replaced the core HTTP component for the entire system, broke everything that touched it, and they didn't even notice. In fact they released several additional versions without noticing, let alone correcting, the open bug.

No, they didn't see any of this coming. You think they saw the msbuild compatibility snafu? Nope, just a bunch of kids thinking minimalist json will solve everything. Worked for making a list of javascript files to compress, why wouldn't it work for build events triggered by Fortran apps linking to a F# library?

Joel Spolsky wrote about this 15 years ago in a post that's been endlessly quoted and misquoted by people on both sides of every code modernization discussion ever since. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

He argues "never" when in fact a list of "do's and don'ts" would have been more helpful. Well 15 years later the .NET team is doing a darn fine job making one half of that list.

[Matthewsre]

I got bit by this nastiness today. @jkells redirects helped me "kick the can" for now. I am on the latest nuget package:
package id="System.Net.Http" version="4.3.0" targetFramework="net461"
A partners library we are using breaks, but I am fortunate to have all of my code working with a binding redirect down to 4.0.

[emirhosseini]

Also having this issue publishing to net461. Had to downgrade to net451. They're saying it'll be fixed in Asp.net Core 1.1.1. I'm not sure I follow what that means exactly. The Mvc NuGet package? That's already set to 1.1.1. What's this thing that's going to be released?

https://github.com/aspnet/Security/issues/1046#issuecomment-277200815

[gimlichael]

I am using Visual Studio 2017 RC and has just created a class library (.NET Standard).

I am referencing my project, Cuemon.Core (https://www.nuget.org/packages/Cuemon.Core.Package) , which is built for .NET Standard 1.4 (so its compatible with .NET Framework 4.6.1 projects), and i am now met with this error message:

Severity    Code    Description Project File    Line    Suppression State
Error   CS1705  Assembly 'Cuemon.Net' with identity 'Cuemon.Net, Version=4.1.2017.0, Culture=neutral, PublicKeyToken=9f6823cab47d945f' uses 'System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Net.Http' with identity 'System.Net.Http, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

This is becoming very confusing and I am starting to loose faith if this will ever work.
I first tried with a .NET Core class library, but this references .NET Standard 1.5, so that was a no go.

Trying to add the app.config does not help ..

[lgrosales]

I was getting the same issue as @andriysavin and both the binding redirect to 4.0 and upgrading to System.Net.Http 4.3 fixed my issue. I decided to go with the upgrade as it's the safest approach.

[JohnGalt1717]

using System.Net.Http 4.3 only solves the issue on web apps. If you use Azure Web Jobs it doesn't solve the problem. If you use desktop apps it doesn't solve the problem.

And System.Runtime.Serialization.Primitives also has issues. (it's still on 4.1.2 even though the package says it's 4.3, the binding redirect is for 4.1.2 that it insists on updating constantly)

And worse, every single time you put in the binding redirects they get overwritten if you update ANY nuget package.

headbang. Microsoft: This still isn't fixed! Fix it right this time please!

[davidsh]

using System.Net.Http 4.3 only solves the issue on web apps. If you use Azure Web Jobs it doesn't solve the problem. If you use desktop apps it doesn't solve the problem.

I think you are running into the larger problem that is described in dotnet/corefx#11100.

We have a larger fix for that issue in the System.Net.Htpp 4.3.1 package that should address the problems you're seeing with Azure Web Jobs and desktop apps.

Please take a look at dotnet/corefx#11100. You can try out the 4.3.1 package from the MYGET feed. It will be published to the main NuGet.Org feed within the next week or so.

[davidsh]

cc: @karelz

[JohnGalt1717]

That still doesn't address: System.Runtime.Serialization.Primitives having the same issues.

[davidsh]

That still doesn't address: System.Runtime.Serialization.Primitives having the same issues.

This GitHub issue was specifically about version inconsistency with System.Net.Http.

If you are having a problem with other libraries, you should first try to make sure you're using the current .NET Core 1.1 packages. And if you still have problems, please open a new issue and include a repro solution including your .CSPROJ and/or project.json files.

[JohnGalt1717]

It's about the endless version issues. Not just one. That was just an example I provided originally. You need to make ALL OF THEM WORK.

If they don't, you don't you don't have a releasable product.

Someone needs to go write a boat load of unit tests for absolutely ALL of these nuget packages and test in all environments on .NET Framework.

[karelz]

This is a long thread, moreover closed for 5+ months.
Can someone please summarize the problem which is left? (ideally with a good description without assumption of prior knowledge)
I would also suggest to create a new issue (with better title properly describing the scope), so that it is easier to follow the problem discussion and loop in the right experts.

Regarding shipping NuGet packages for assemblies which ship inside .NET Framework (which may be the remaining issue here) - this is something which is extremely hard and costly to do. We learned it the hard way, and consumers of the packages are impacted :(.
We are trying to undo the badness as much as we can for System.Net.Http and System.IO.Compression packages. I was told that those are the only 2 packages we did it for. Is that not the case?

[ccicchitelli]

@karelz does this help? https://github.com/dotnet/corefx/issues/9846#issuecomment-276891271

What else can I provide to help clarify/detail the issue?

(I've successfully enabled a workaround by redirecting back to the older version of the library.)

[karelz]

@ccicchitelli sorry, but the comment you referenced is not clear to me. Also it talks only about System.Net.Http, while there are concerns about System.Runtime.Serialization.Primitives above. So I am confused.
It would be great if the issue description can filter out problems caused by dotnet/corefx#11100 (which is being resolved) - the comment you reference seems like it might be actually dupe of dotnet/corefx#11100 (but I may be wrong).

[ccicchitelli]

Actually you're right, I think that issue may be the one (at least for me). One difference is I'm not running a web app, but rather a WCF service within a Windows service. I hadn't seen it before now though. My googlefu failed me. Happy to hear it will be resolved soon!

[JohnGalt1717]

@karelz The issue is that it isn't just System.Net.Http. It's pretty much ALL of the updated .NET Standard compatible versions of these dlls that were once just part of the .net framework.

Any time ANYTHING is done in those that .NET 4.6.2 doesn't support directly, they need to have special shims to make them work right like dotnet/corefx#11100 does for System.Net.Http.

System.Runtime.Serialization.Primatives now has dependencies that cause errors in non-asp.net based projects just like System.Net.Http and thus needs to be fixed because right now it is NOT compatible per the .net standard docs.

All teams working on these modules need to be told that they need to test in all of the same scenarios as dotnet/corefx#11100 and someone on each of those dlls needs to test and fix them and write unit tests so that this doesn't happen again because right now yes System.Net.Http is now fixed. But I still have to hack in binding redirects for System.Runtime.Serialization.Primatives and who knows what next week when they break something else because they're not testing properly.

That's the core issue at hand. Not just one broken one, but many, and many more potentially getting broken.

[tofutim]

@JohnGalt1717 John, I have exactly your issue and I need to make progress. I decided to jump back to 4.3.0 and am stuck at the 4.0.0 requirement for System.Security.Cryptography.Primitives/Algorithms.

10:33:51.156 [Worker#STA_NP] DEBUG TranslationManager - Baidu: Could not load file or assembly 'System.Security.Cryptography.Algorithms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

How do I 'hack in binding redirects' so that I can move forward?

[ccicchitelli]

@tofutim when I did the binding redirect, I also had to manually locate the DLLs to the build folder. For some reason, the MSBuild process wasn't outputting the redirected DLLs or pulling them from the GAC.

[tofutim]

can you tell me more about how to do this? I'm not sure what 'binding
redirect' means.

On Sat, Feb 18, 2017 at 10:53 AM, ccicchitelli [e-mail]
wrote:

@tofutim https://github.com/tofutim when I did the binding redirect, I
also had to manually locate the DLLs to the build folder. For some reason,
the MSBuild process wasn't outputting the redirected DLLs or pulling them
from the GAC.

—
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-280866688, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAJoRjmj1EusAAnWB9r-LQLSOaGsQKaGks5rdz4WgaJpZM4JE8Nf
.

[ccicchitelli]

Then you have some reading to do: https://www.google.com/search?q=binding+redirect

[karelz]

@JohnGalt1717 our plan is to STOP shipping anything that overrides Desktop independently (see https://github.com/dotnet/corefx/issues/9846#issuecomment-280560086). I am not aware of any other NuGet package except System.Net.Http and System.IO.Compression which would ship code for Desktop replacing .NET Framework assemblies. Can you please check that it is true for System.Runtime.Serialization.Primitives (on Desktop)?
cc: @weshaggard

[ccicchitelli]

@karelz What does this mean, exactly? Are the System.Net.Http etc assemblies going to be different on desktop and core? I'm wondering about direct portability?

[karelz]

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

Inbox version:
C:\Windows\Microsoft.NETassembly\GAC_MSIL\System.Runtime.Serialization.Primitivesv4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.Serialization.Primitives.dll

[karelz]

@ccicchitelli it means that Desktop will be behind on new features until it ships update with the new features. Unless there is sim-shipping of 2 products, one of them will be always a bit behind ...
We tried to minimize the "being behind" of Desktop (which has slower shipping cadence) by shipping out-of-box replacements of inbox components, but it is extremely complex, hard and costly - hence not worth the value.

If there is immediate need to ship new functionality on all platforms, the DLL has to be built ON TOP of .NET Standard and cannot replace the one shipped INSIDE the .NET Framework.

Makes sense?

[ccicchitelli]

@karelz thanks, that's perfect.

I think it makes sense that desktop prioritizes stability and consistency first. If customers want the latest and greatest, they can compile for core/standard instead.

Thanks again!!

[JohnGalt1717]

System.IdentityModel.Tokens.Jwt
Microsoft.IdentityModel.Tokens
System.Runtime.Serialization.SerializationPrimatives

All have issues.

[karelz]

@JohnGalt1717 System.IdentityModel.Tokens.Jwt and Microsoft.IdentityModel.Tokens are not part of CoreFX.

@weshaggard @ericstj any comment on System.Runtime.Serialization.Primitives? Did we miss it?

[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 [e-mail]
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.