runtime: Problems with ASP.NET projects when consuming .NET Standard assets

It has been reported by users that if you are building an ASP.NET web app which consumes an asset that is .NET Standard-based, the app may encounter errors at runtime given that it can’t find assemblies. This is an example of the errors one might get when hitting this issue:

System.IO.FileNotFoundException occurred HResult=0x80070002
Message=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.

One other symptom of this is that your project will complain that it needs some binding redirects added to your web.config, which you will have to add by double-clicking the warning from the error list in VS.

The reason behind what is happening is that because of this known issue we end up requiring a few extra assemblies to be loaded in order to be able to run a .NET Standard-based component on .NET Framework. Because of how ASP.NET handles deployments, in some scenarios these extra files won’t be copied over to the application directory, causing most of the issues.

This issue is created so that we can track the problem separate from issue dotnet/runtime#24382 as it was dicussed on this comment: https://github.com/dotnet/corefx/issues/25773#issuecomment-378341475

cc: @AlexGhiondea

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 8
Comments: 23 (12 by maintainers)

Most upvoted comments

Adding app.config with a bindingRedirect carries over to the *.exe.config file, however the AutoGenerateBindingRedirects rewrites the specified newVersion from 4.0.0.0 to 4.2.0.0. I’ve figured out a working workaround which involves compiling the project with AutoGenerateBindingRedirects on, copying the *.exe.config file’s content to app.config, then editing that and turning AutoGenerateBindingRedirects off.

My recommendation would be that if a user created app.config is detected, the compiler should respect any bindingRedirect.newVersion if there is any, rather than forcibly re-resolving it.

AutoGenerateBindingRedirects is useful for any other non-conflicting dependencies, so turning it completely off just to solve a single issue rather than only manually overwriting the problematic values doesn’t seem intuitive.

kanadaj on Jun 11, 2018

Ok, thanks again for reporting the issue and for the log. I have figured out what is going on in your case, basically, you are hitting two tooling issues which I will go ahead and log for this (one is a SDK issue, the other is a NuGet targets issue). A simple workaround for now, is to add this to your .csproj:

  <ItemGroup>
    <PackageReference Include="System.Net.Http" Version="4.3.3">
      <ExcludeAssets>All</ExcludeAssets>
    </PackageReference>
  </ItemGroup>

I have reproed your issue locally and this workaround did work for me. Let me know if it doesn’t work for you. Also, I’ll make sure that the SDK team fixes the tooling issues so that this workaround is not required any longer.

joperezr on May 4, 2018

Has there been any permanent fix for this discovered yet? I’ve had these same errors reported at runtime whether targeting net46x, net47, or net47x, including net472. Concerning net472, in some cases but not all forcing a redirect of system.net.http to 4.0.0.0 seems to help, but not always.

CoderNumber1 on Mar 19, 2019

It seems like this error is related to the issues I’m facing with ASP.NET Core targeting .NET 4.7.2

kanadaj on Jun 11, 2018

Thanks @joperezr

mscrivo on May 4, 2018

This is occurring for us in Service Fabric projects as well as ASP.NET projects (and the bindings need to be flipped if we run EntityFramework migrations in the Package Manager Console. Then flipped back if we want to run our app). Also, every time a package updates it reverts to a binding we DON’T want, it is super annoying and all of our developers are frustrated with it - myself included 😉

Also posted this here: https://github.com/dotnet/corefx/issues/25773

philcarbone on Apr 7, 2018

cc: @AlexGhiondea @karelz FYI

joperezr on Apr 5, 2018