New issue

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

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

Already on GitHub? Sign in to your account

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

Closed
kierenj opened this Issue Jul 31, 2017 · 46 comments

Comments

Projects
None yet
@kierenj

kierenj commented Jul 31, 2017

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:

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

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

This comment has been minimized.

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

This comment has been minimized.

Tornhoof commented Aug 16, 2017

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
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.1" newVersion="4.1.1.1" />
      </dependentAssembly>
  • 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

This comment has been minimized.

Tornhoof commented Aug 16, 2017

The current workaround is probably:

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

Then it uses the dll from the build extensions directory and not the one from Nuget.

@kierenj

This comment has been minimized.

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

This comment has been minimized.

Tornhoof commented Aug 16, 2017

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.

@karelz

This comment has been minimized.

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.

cc @weshaggard @ericstj @mellinoe

@kierenj

This comment has been minimized.

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

@ericstj

This comment has been minimized.

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

@danmosemsft

This comment has been minimized.

Member

danmosemsft commented Aug 16, 2017

@karelz

This comment has been minimized.

Member

karelz commented Aug 16, 2017

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

@Sc0tTyXL

This comment has been minimized.

Sc0tTyXL commented Aug 30, 2017

-- deleted --

@karelz

This comment has been minimized.

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

This comment has been minimized.

aliveli186 commented Sep 8, 2017

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.

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

Any help?

@edgarleonardo

This comment has been minimized.

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:

  1. I deleted all Dependent Assambly and update all nugets UPDATE-PACKAGE -projectName -reinstall.

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

@Robula

This comment has been minimized.

Robula commented Nov 13, 2017

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

This comment has been minimized.

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

This comment has been minimized.

edgarleonardo commented Nov 13, 2017

@mckelvj

This comment has been minimized.

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

This comment has been minimized.

Robula commented Nov 13, 2017

We eventually got past this by moving from VS2015 to VS2017 and using <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>.

Voodoo.

@tompazourek

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

TonyValenti commented Nov 21, 2017

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

@karelz

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

albigi commented Mar 6, 2018

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

@karelz

This comment has been minimized.

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

This comment has been minimized.

misterspeedy commented Mar 7, 2018

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:

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

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

This comment has been minimized.

misterspeedy commented Mar 8, 2018

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

@tompazourek

This comment has been minimized.

tompazourek commented Mar 8, 2018

@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

This comment has been minimized.

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.

Seen here: https://github.com/Microsoft/dotnet-framework-early-access/blob/master/release-notes/build-3052/dotnet-build-3052-changes.md#bcl

@joperezr

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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.

@joperezr

This comment has been minimized.

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.

@AlexGhiondea

This comment has been minimized.

Member

AlexGhiondea commented Mar 26, 2018

@tompazourek let me try and answer your question.

The way we version .NET Standard is by rev’ing the assembly version when a new API is added. That helps keep versioning somewhat sane. When a platform implements .NET Standard, it has to add the assemblies that make up .NET Standard to its implementation.

So far so easy. The challenge is that in .NET Framework we cannot easily bump assembly versions as .NET Framework has additional versioning constraints that stem from the fact that it is a Windows component, i.e. can be deployed and upgraded by Windows Update.

The .NET Framework runtime has a mechanism (called a unification table) that helps ensure that assembly versions unify. For instance, if your application references System.Runtime 4.0.0.0 as a direct reference and System.Runtime 4.0.10.0 via an indirect reference, the unification table ensures that a single version of System.Runtime.dll will be loaded by your application. This ensures that there is a single type loaded for a given type identity. This is described here: https://msdn.microsoft.com/en-us/library/db7849ey(v=vs.100).aspx.

When we added support for .NET Standard 2.0 (and consequently .NET Standard 1.x) to .NET Framework 4.7.1 we had to satisfy requirements from both .NET Standard (bumped assembly version) and .NET Framework/Windows (don’t bump the assembly version). So we modified this unification table to allow us to:

  1. Keep the assembly versions as 4.0.0.0
  2. Rev-up the surface area of those same assemblies (we have validation in place to ensure the API surface area is strictly additive to ensure backward compatibility).

This change allowed us to support compiling against the higher version of the assembly version but still keep the assembly as version 4.0.0.0 at runtime. As @joperezr said, normally we’d consider those implementation details of the platform.

However, .NET Framework also comes with the exact binding policy. That allows customers to tweak the binding behavior, for which we generally recommend binding redirects as it is declarative and toolable.
Unfortunately, the runtime has to treat them as The One True Answer, i.e. those override any unification that happens magically via the table. In other words, binding redirect generation has to have the same behavior. And this is where implementation details start to bleed into the developer experience. We’d like to fix that, but that requires changing the binding policy which is extremely hard to do in a compatible way (read: close to impossible).

We also had a couple of bugs in this space (which this thread is about). Because of those bugs, there is a need to have binding redirects (when running on .NET Framework 4.7.1) for 12 assemblies (including System.Net.Http).

All of the issues were addressed in the .NET Framework 4.7.2 release (you don’t need to have binding redirects when targeting 4.7.2).

@tompazourek

This comment has been minimized.

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?

@joperezr

This comment has been minimized.

Member

joperezr commented Mar 27, 2018

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

This comment has been minimized.

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

@karelz

This comment has been minimized.

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!

@Serjster

This comment has been minimized.

Serjster commented Jun 19, 2018

I tried all of the solutions listed in this page while targeting 4.7.2:

  <system.web>
    <authentication mode="None" />
    <compilation debug="true" targetFramework="4.7.2" />
    <httpRuntime targetFramework="4.7.2" />
    <customErrors mode="Off" />
  </system.web>

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.

@joperezr

This comment has been minimized.

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.

@AlexGhiondea

This comment has been minimized.

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

This comment has been minimized.

Serjster commented Jun 20, 2018

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

This comment has been minimized.

carlmacdiarmada commented Jul 9, 2018

Strange error, it can also be produced by having a malformed app.config input. the issue I had was

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

The error was gone after I split them and bumped the newVersion to 4.0.0.0

Thanks for the insight here.

@BrainSlugs83

This comment has been minimized.

BrainSlugs83 commented Oct 2, 2018

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

@joperezr

This comment has been minimized.

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.

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