# dotnet/corefx

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.

# System.Net.Http package 4.3.2 - redirect to 4.2.0.0, assembly loading failure #22781

Closed
opened this Issue Jul 31, 2017 · 46 comments

Projects
None yet

### kierenj commented Jul 31, 2017 • edited

 I know there's been a few issues with System.Net.Http, but after some searching I couldn't find anything that seems to relate to, or remedy, my issue. I'll be happy to move this somewhere else, provide more details, etc, as necessary. I have some .NET Framework 4.6.1 class libraries and ASP.NET MVC projects which reference this package: When they run, I get: System.BadImageFormatException : Could not load file or assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ----> System.BadImageFormatException : Could not load file or assembly 'file:///C:\Program Files (x86)\Microsoft Visual Studio\Preview\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\System.Net.Http.dll' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ----> System.BadImageFormatException : Cannot load a reference assembly for execution.  My workaround is to manually overwrite the assembly redirects which seem to be automatically generated very frequently whenever I update a number of NuGet references, with this:   I'd like to either be able to use this latest version of the package without manually doing this, to understand why 4.2.0.0 is not working by design, or do whatever reconfiguration is necessary to stop the workaround being overwritten. If it's a helpful clue, netfx.force.conflict also appears in my bin folder at certain time (nuget restore?). A clean does not clear it away, but manually deleting the bin folder lets the project run successfully. Most of all, I'd like to feel less helpless / have the tools or knowledge to work out why this is happening by a logical process of elimination / deduction. I've been using and trying to find a way to get us on board the .NET Core train for quite a while. This is our first production project and is utilising some new .NET Core / .NET Standard libraries we have for some parts, and .NET Framework for others. It's been a very difficult experience so far, specifically any time .NET Framework assemblies are referencing netstandard ones. Through bashing against this kind of error for several weeks, I am piecing together facts and workarounds for NuGet versioning, redirects, reference assemblies, type forwarding, build file flags and a myriad of other nuggets. However, my knowledge is still evidently full of gaps. Is there a single place - or even a recommended set of places - where I can learn everything I need to know to have a project set up in this way? The knowledge set required to diagnose build and runtime errors in this kind of scenario so far seems huge, but I/we need to build this expertise internally. (Visual Studio 2017 15.3 Preview 6)

### kierenj commented Aug 14, 2017

 Do let me know if there's a better place to post this/ask for help. I'm not sure if that's the case, or if this is just low prio (not for me, but I appreciate there's lots of work to do..), or if maybe it's slipped through the gaps - I notice this issue only has one tag, whereas 99% of issues seem to have many. Also, let me know if I can provide any more information. Thanks

### Tornhoof commented Aug 16, 2017 • edited

 I ran into that too. Looks like that Visual Studio 2017 15.3 is shipping with a .NET 4.6.x System.Net.Http.dll with internal assembly version 4.2.0 and the latest Nuget Package assembly version is 4.1.1 for NetFX. Warning message is the same: Consider app.config remapping of assembly "System.Net.Http, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.1.1.1" [c:\users\tornhoof\documents\visual studio 2017\Projects\NetHttpRepro\NetHttpRepro\bin\Debug\System.Net.Http.dll] to Version "4.2.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\System.Net.Http.dll] to solve conflict and get rid of warning. Microsoft needs to release an updated nuget package with a version of 4.2.0.0. Steps to reproduce: Create .NET 4.6 project Add reference to Nuget System.Net.Http (V 4.3.2) package Add binding redirect to   Compile (no warnings) According to Project references the Assembly version of System.Net.Http.dll is 4.1.1.1 Add reference to e.g. latest System.Threading.Tasks.Dataflow Compile Expected result: No warnings Actual result: Consider app.config remapping of assembly "System.Net.Http, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.1.1.1" [c:\users\tornhoof\documents\visual studio 2017\Projects\NetHttpRepro\NetHttpRepro\bin\Debug\System.Net.Http.dll] to Version "4.2.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\System.Net.Http.dll] to solve conflict and get rid of warning.

### Tornhoof commented Aug 16, 2017

 The current workaround is probably:   Then it uses the dll from the build extensions directory and not the one from Nuget.

### kierenj commented Aug 16, 2017

 @Tornhoof indeed I think you're encountering the more common issue with System.Net.Http (#9846 I think covers it) ? I wonder if you had the "can't load a reference assembly" error? When I use the workaround you posted, that's the result - I need to redirect from 0.0.0.0-4.2.0.0 to 4.0.0.0 for some reason. What's more, this redirect is overwritten when I perform certain nuget actions. Additionally, I get a netfx.force.conflicts.dll file dumped in my bin folder, which breaks runtime, and isn't deleted with the clean operation. Did you get the same?

### Tornhoof commented Aug 16, 2017 • edited

 I had a can't load assembly error once after starting, as soon as I started a rebuild I received the other error about incompatible libraries. The library referenced in your error is the reference dll, which can never start as far as I know, it's a stripped library. In both of our cases VS 15.3 is the culprit and in both our cases a new nuget package should probably fix it. But you might be correct that they are two individual errors. I'll leave that up to the maintainers to decide.
Member

### karelz commented Aug 16, 2017

 The 2 errors seem different to me. @kierenj the first one suggests something is trying (by mistake) to load a reference assembly at runtime. We need to find out what and why. Is there a minimal repro? @Tornhoof your second repro looks like something reproducible without any .NET Standard. It is pure .NET 4.6 problem. Can you please file a separate issue and tag me? Can you please clarify which latest System.Threading.Tasks.Dataflow nuget package did you reference? (to be super-clear) I wonder if some package(s) we shipped on Monday has wrong reference to System.Net.Http, or something like that.

### kierenj commented Aug 16, 2017

 @karelz I will advise. Could I sheepishly suggest there may be 3 issues (with reference to my final 3 paragraphs)?
Member

### ericstj commented Aug 16, 2017

 Root cause of this appears to be similar to #23229. Nothing should be trying to load reference assemblies for execution. Your workaround of redirecting to the framework version will potentially break some libraries. We need to root cause the very first error in order to get the correct fix. Would it be possible for you to share a full callstack for that BadImageFormatException and potentially an isolated repro? The reason for the internal version of System.Net.Http dll is because the new netstandard2 support for desktop is shipping in the toolchain (MSBuild). We're trying to eliminate the need for packages. First step is to get the dlls added automatically to the existing frameworks. Next step is to get all the dlls in the framework (so that bindingRedirects and app local copies of these go away completely).
Member

### danmosemsft commented Aug 16, 2017

 /cc @weshaggard
Member

### karelz commented Aug 16, 2017

 @kierenj what is the 3rd one? Debugging tools?

Closed

### Sc0tTyXL commented Aug 30, 2017 • edited

 -- deleted --
Member

### karelz commented Aug 30, 2017

 @Sc0tTyXL if your problem is related to #23306, please move your post there (incl. delete this one). When we mix up issues together (like in this issue), it lowers the chance of follow up and resolution as things get messy and hard to separate ...

### aliveli186 commented Sep 8, 2017 • edited

 I have a click-once winforms app using .NET 4.7 (has .netstandard 2.0 references) which fires the following exception on the client side: ************** Exception Text ************** System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. File name: 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. File name: 'System.Net.Http, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'  I attached (Add As Link) the "System.Net.Http.dll" which is version 4.2.0.0 from: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\System.Net.Http.dll" But this time the app fires the following exception on the client side: ************** Exception Text ************** System.BadImageFormatException: Could not load file or assembly 'System.Net.Http, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) File name: 'System.Net.Http, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.BadImageFormatException: Cannot load a reference assembly for execution.  When I add the binding redirect to app.config I receive the same error "System.BadImageFormatException" as above.   Any help?

Closed

### edgarleonardo commented Oct 3, 2017

 I was experiencing this issue after upgrade the .NET framework from 4.6.2 to 4.7, after digging around on several forums and the internet for a while and trying a lot, I found a solution and consits in two steps: I deleted all Dependent Assambly and update all nugets UPDATE-PACKAGE -projectName -reinstall. After the first step, I checked every missing assambly that throw me an exception in runtime and realize that in some cases the framework has a dll in our local machine that has nothing to do with the nuget then I deleted all local's dll references and install it from the nuget. After cleaning from the missing dll taking them from the Nuget my project run without any issue. Hope that help you.

Closed

### Robula commented Nov 13, 2017 • edited

 I'm experiencing this issue also. I have a NuGet package that has netstandard1.6 and net462 as dependencies. When using this package in a net462 project I experience the issue described here. Is there a preferred work around? Would downgrading System.Net.Http help with this? Thanks

### mckelvj commented Nov 13, 2017

 I found that the Assembly bindings in the App.Config were the problem. You can resolve the issue by either commenting out or remove those. It appears that they are not being created correctly by the package manager.

### edgarleonardo commented Nov 13, 2017

 Reinstall all nugget and the problem should get fixed El nov. 13, 2017 9:39 AM, "John McKelvey" escribió: … I found that the Assembly bindings in the App.Config were the problem. You can resolve the issue by either commenting out or remove those. It appears that they are not being created correctly by the package manager. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#22781 (comment)>, or mute the thread .

### mckelvj commented Nov 13, 2017

 Nope sorry. I used a variety of deleting, adding and/or updating the nugget packages and it never cleared the problem. Some of the assembly registrations created are incorrect, most notably those identified earlier in this stream. When you remove and reinstall the nugget packages it does not clean-up those invalid entries, and you still get the "can't load a reference assembly". Manually deleting the assembly registrations will remove the invalid entries, and solve the problem.

### Robula commented Nov 13, 2017 • edited

 We eventually got past this by moving from VS2015 to VS2017 and using true. Voodoo.

### tompazourek commented Nov 14, 2017

 I had some issues with assembly redirects as well. I resolved it by updating to the latest .NET Framework 4.7.1, VS2017, and not having any references to NuGet package assemblies for assemblies that are already part of .NET Framework. My projects are targetting the full .NET Framework, and it works better when they, for example, reference the System.Net.Http assembly from the .NET Framework instead of the System.Net.Http NuGet package. It can happen that you use some third party library that requires you to use the System.Net.Http NuGet package, because the package is not correctly targetting the latest .NET Framework and has the dependencies wrong (I noticed this with Google.Apis for example). In those cases, I just manually changed the reference in my project to the framework assembly.

### shaulbehr commented Nov 19, 2017

 I'm having the same grief. Lost two working days to this problem. Eventually I solved it (I think!) by going into \Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib and \Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref and copying all DLLs in those folders (other than netstandard.dll) into a subfolder, just to hide them away from my compiler!

### TonyValenti commented Nov 21, 2017

 +1 for @shaulbehr 's solution. Been bashing my head against this for days!

Closed

Member

### karelz commented Jan 18, 2018

 @shaulbehr @TonyValenti the preferred workaround is to add manual binding redirect - see #22781 (comment) If it is not working for you (or anyone), please let us know - we would be interested in minimal repro for such case. Thanks!

### ZubyH commented Mar 4, 2018

 The binding redirect was the only way I could get around this issue. Really was a headache for days, glad I can get past the roadblock though.

### albigi commented Mar 6, 2018 • edited

 @karelz we are seeing a similar issue when from an empty ASP.NET WebAPI project we add the System.Composition.Runtime NuGet and implement a dummy ActionFilterAttribute from System.Web.Http. In some way we end up referencing 2 distinct System.Net.Http (I believe one is from System.Web.Http, the other from .NETStd2 referenced in turn by System.Composition.Runtime). The conflict appears to only get resolved by adding an assembly redirection to the latest version of System.Net.Http. Is this something that 2.1.0 will possibly fix? Thanks! is this a known problem? if yes will it be addressed in 2.1.0? (I can provide repro and tracing if it can be useful)
Member

### karelz commented Mar 6, 2018

 The underlying problem is actually in VS tooling (not causing conflicts to resolve them and auto-generate binding redirects), it is not a bug in .NET Core itself (hence it does not matter if you have .NET Core 2.0 or 2.1). @joperezr in which VS version should the fix show up?

### misterspeedy commented Mar 7, 2018 • edited

 Just in case it helps anyone - I had this issue when running a worker role in the Azure simulator (VS2017 15.4.3). As suggested elsewhere the workaround was to add this to the Worker Role's app.config:   Some important points to note: I had to use newVersion of 4.0.0.0 even though the version of System.Net.Http that was lying around in the packages folder was 4.3.0. The redirect had to be in the App.config of the cloud service. I haven't tried this on real Azure yet. <-- Edit. I have now and it worked.

### misterspeedy commented Mar 8, 2018

 Just had to add this to another, somewhat separate project. Seems to be a widespread issue.

### tompazourek commented Mar 8, 2018 • edited

 @misterspeedy Note that when you're talking about version 4.3.0 it's just a version of the NuGet package. The assembly inside the 4.3.0 NuGet package actually has different assembly version, like 4.1.1.0. One thing is still not clear to me: Why does the latest version of .NET Framework (4.7.1) contain version 4.0.0.0 of System.Net.Http when there have been newer versions since long time ago?

### mbp commented Mar 8, 2018

 I believe this is due to be solved in .NET 4.7.2: Increment the assembly version of System.Net.Http and System.IO.Compression to be compatible with netstandard 2.0 and the compatibility package.
Member

### joperezr commented Mar 19, 2018

 Just in case anybody is still hitting this when targeting 4.7.1, we released today VS 15.6.3 which should fix the issue and automatically generate the right binding redirects for you. Why does the latest version of .NET Framework (4.7.1) contain version 4.0.0.0 of System.Net.Http when there have been newer versions since long time ago? 4.0.0.0 is the assembly version inbox because Desktop assemblies on the GAC need to be 4.0.0.0. This is an inner implementation detail, so even though its assembly version is 4.0.0.0, the API it has actually matches the latest one for other frameworks: 4.2.0.0

### phillip-haydon commented Mar 25, 2018

 I downvoted, I upgraded to latest version of VS this morning (15.6.4) and then updated all my projects to 4.7.1 and the binding redirect never happened, had to manually do it. So i don't believe it's fixed in 15.6.3

### tompazourek commented Mar 25, 2018

 @joperezr It's not really just an inner implementation detail if all the assembly binding redirects rely on having correct assembly versions. If the assemblies in GAC have their versions all wrong (e.g. it says it is 4.0.0.0 instead of 4.2.0.0), it's expected that there will be all kinds of problems with it, like the stuff that we're discussing in this thread. Can you please shed some light on why it is done this way? Cheers.
Member

### joperezr commented Mar 26, 2018

 I downvoted, I upgraded to latest version of VS this morning (15.6.4) and then updated all my projects to 4.7.1 and the binding redirect never happened, had to manually do it. @phillip-haydon do you mind sharing a diagnostic log of your build? I have definitely tested and made sure that 15.6.3 produces binding redirects automatically, so I believe that there might be something else going on. A diag log would help diagnose what the problem is.
Member

### tompazourek commented Mar 27, 2018

 @AlexGhiondea Thank you for explaining this, I understand it a bit better now. Can you please provide a list of those 12 assemblies that might need the binding redirects on 4.7.1?
Member

### joperezr commented Mar 27, 2018 • edited

 List is: System.Data.Common.dll System.Diagnostics.StackTrace.dll System.Diagnostics.Tracing.dll System.Globalization.Extensions.dll System.IO.Compression.dll System.Net.Http.dll System.Net.Sockets.dll System.Runtime.Serialization.Primitives.dll System.Security.Cryptography.Algorithms.dll System.Security.SecureString.dll System.Threading.Overlapped.dll System.Xml.XPath.XDocument.dll  That said, if you are using our latest VS release, you shouldn't need to add them yourself, since the tooling will add the binding redirects if they are required.

### Nagendracv commented Apr 26, 2018

 Still same issue here. Tried using 4.6.2 as well as 4.7.1. Sad the issue is still not addressed Happens wherever there is Cors package installed which has a dependency on webapi.client package and which depends on System.Net.Http 4.2
Member

### karelz commented Apr 26, 2018

 @Nagendracv the problem should be fixed if you use latest VS tooling. There are 2 known exceptions: ASP.NET projects (tracked in #28833) and Service Fabric projects (not sure if we have tracking bug created yet - #25773 (comment)). If you think you're not in either of those scenarios, please file a new issue with details about your repro, so that we can take a look. Thanks!

Closed

### Serjster commented Jun 19, 2018

 I tried all of the solutions listed in this page while targeting 4.7.2:   And still having the error in Azure App Service: Could not load file or assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Assembly Load Trace: The following information can be helpful to determine why the assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' could not be loaded.
Member

### joperezr commented Jun 20, 2018

 @Serjster do you mind producing an msbuild.binlog and attaching it here so that we can investigate and diagnose what is going on with your project? In order to produce one, simply run msbuild yourProject.csproj /t:rebuild /v:m /bl from a Developer command prompt.
Member

### AlexGhiondea commented Jun 20, 2018

 @Serjster it looks like Azure App Service does not yet run on .NET Framework 4.7.2 Azure/app-service-announcements-discussions#37

### Serjster commented Jun 20, 2018 • edited

 Thanks for the reply, that definitely helps clarify such things... you would hope that ASP.NET would be smart enough to give a meaningful error message about the right version not being available instead of forcing, who know how many hours now on troubleshooting... come on Microsoft it can't be that hard to make this experience less painful... anyways, hopefully this helps the next guy who comes across this.

### carlmacdiarmada commented Jul 9, 2018

 Strange error, it can also be produced by having a malformed app.config input. the issue I had was   The error was gone after I split them and bumped the newVersion to 4.0.0.0 Thanks for the insight here.

Closed

Closed

### lazcool added a commit to SkillsFundingAgency/das-commitments that referenced this issue Aug 21, 2018

 try different binding redirect from dotnet/corefx#22781 
 2b89c53 

### lazcool added a commit to SkillsFundingAgency/das-commitments that referenced this issue Aug 21, 2018

 try and add a binding redirect for the web role for system.net.http 
see
dotnet/corefx#22781 (comment)
https://blogs.msdn.microsoft.com/friis/2014/05/15/webrole-entry-point-and-config-file/
https://azure.microsoft.com/en-us/blog/new-full-iis-capabilities-differences-from-hosted-web-core/
 da0dd89 

Open

### BrainSlugs83 commented Oct 2, 2018

 This is still broken in .NET 4.7.2 with Visual Studio 2017 (15.8.5). :(
Member

### joperezr commented Oct 2, 2018

 Unfortunately, System.Net.Http has caused different sets of issues for apps, which explains why this issue is now a sum of a bunch of different root causes for different problems. Anyone facing a problem with System.Net.Http, I think we would benefit from logging a new issue along containing a small repro of the problem (if possible), a description, and a build log. If we find that two of those issues are the same, we can dupe them after root-causing them. I don't really think that piling up on this same issue for every problem with System.Net.Http will help us in any way. @BrainSlugs83 Do you mind opening a new issue with the description of your project and the error that you are getting so that we can take a peek? I would expect that most problems with System.Net.Http be fixed with 4.7.2 and the new VS.

### Sc0tTyXL referenced this issue Oct 9, 2018

Closed

#### Block NuGet package #7378

to join this conversation on GitHub. Already have an account? Sign in to comment