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

[joperezr]

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

[joperezr]

cc: @AlexGhiondea @karelz FYI

[AlexGhiondea]

Adding @AngelosP who is going to help with this.

[AngelosP]

Internal work item ID 595443. Scheduled meeting for Monday to discuss next steps.

[JanEggers]

i had this issue and had to install vcredist2015/2017 to fix it

[philcarbone]

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

[mscrivo]

@JanEggers that doesn't at all sound like the same issue.

Thank you @joperezr and @AngelosP for getting this on the radar.

[stevozilik]

Please fix, this is same problem for us.

Running Service Fabric with Asp Net Core, the System.Net.Http (from C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll) 4.2.0.0 overrides the latest 4.1.1.2 (from 4.3.3 System.Net.Http nuget package)

[mscrivo]

I posted this in another issue, but I'll put here now that it's being tracked and in case it's useful, a minimal repo solution: https://github.com/mscrivo/System.Net.Http.Crash

[mscrivo]

@joperezr FYI, the issue seems to be fixed when targeting the recently released .NET 4.7.2

[joperezr]

Yes, we fixed all of the issues we started seeing with the runtime facades on 4.7.2 as we found them, so all of this should be fixed on 4.7.2. That said, we should probably still keep this open for people targeting lower versions. Thanks a lot for checking though 😄

[mscrivo]

@joperezr There is one new issue that I'm now facing. If I have a .NET Framework 4.7.2 project that references both a .net standard 2.0 project and a nuget package that references some package that references an old System.Net.Http package, it will just flat out refuse to build stating that it cannot find System.Net.Http.

One example of such a package is: https://github.com/Antaris/RazorEngine .. It has a dependency on Microsoft.AspNetCore.Razor 1.x which looks like it references an old version of the System.Net.Http nuget package which causes the build to fail. If i remove the reference to RazorEngine, it's happy again. I would love if they updated to AspNetCore.Razor 2.x, but apparently the changes required are too great and progress has stalled, so I'm looking for alternatives.

[joperezr]

@mscrivo do you mind sharing a binlog of your build so I can diagnose what is going on? In order to produce a binlog, you just need to call msbuild yourProject.csproj /bl /t:rebuild from a developer command prompt and that should produce a msbuild.binlog file. If you could share that it would be great.

[mscrivo]

@joperezr here you go .. msbuild.zip

I can also post a minimal repo up on github if you like, let me know.

[joperezr]

thanks a lot! I'm taking a look at the binlog now, I'll let you know if that is not enough.

[joperezr]

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.

[mscrivo]

Thanks @joperezr

[kanadaj]

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

[kanadaj]

@joperezr The workaround works on my local machine, but it doesn't seem to work on Azure with ASP.NET Core when targeting the full .NET Framework. After uploading, I still get this error:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.ApplicationInsights.AspNetCore.DiagnosticListeners.HostingDiagnosticListener.OnBeginRequest(HttpContext httpContext, Int64 timestamp)
   at Proxy_Method_From_<>f__AnonymousType0`2_To_Void OnBeginRequest(Microsoft.AspNetCore.Http.HttpContext, Int64)(Object , Object , IProxyFactory )
   at Microsoft.Extensions.DiagnosticAdapter.ProxyDiagnosticSourceMethodAdapter.<>c__DisplayClass1_0.<Adapt>b__0(Object listener, Object data)
   at Microsoft.Extensions.DiagnosticAdapter.DiagnosticSourceAdapter.Write(String diagnosticName, Object parameters)
   at Microsoft.Extensions.DiagnosticAdapter.DiagnosticSourceAdapter.System.IObserver<System.Collections.Generic.KeyValuePair<System.String,System.Object>>.OnNext(KeyValuePair`2 value)
   at System.Diagnostics.DiagnosticListener.Write(String name, Object value)
   at Microsoft.AspNetCore.Hosting.Internal.HostingApplicationDiagnostics.RecordBeginRequestDiagnostics(HttpContext httpContext, Int64 startTimestamp)
   at Microsoft.AspNetCore.Hosting.Internal.HostingApplication.CreateContext(IFeatureCollection contextFeatures)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequests>d__186`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequestsAsync>d__185`1.MoveNext()

On a side note, unlike described in https://github.com/dotnet/sdk/issues/2221 , I do not actually need to reference the matching .NET 4.7.2 libraries, simply setting an ASP.NET Core project's target to net472 will stop the project from compiling if the System.Net.Http nuget is referenced and I try to instantiate HttpClient. I do not actually need to reference the platform's own package.

[kanadaj]

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.

[CoderNumber1]

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.

[ViktorHofer]

@joperezr is this issue still tracking an external issue (see label)? https://github.com/dotnet/sdk/issues/2221 is already closed so I'm wondering if this issue is actionable on our side. Thanks

[joperezr]

I don't think this issue is actionable on our side. The problem people hit here is that not all deployment strategies take into consideration that there may be additional files that need to be deployed with your app. We control assemblies that get published to the bin folder, so when the netstandard facades are needed we include them there, but not all deployment mechanisms copy those for execution. This issue was mostly logged as a catch-all net for folks using ASP.NET and running into deployment issues leading to assemblies not found at runtime, and has been used for folks to post their repro and for us to help them fix it, but fixes of course vary case-by-case.

[ViktorHofer]

Thanks for the explanation. Given this issue isn't actionable anymore, I'm closing it.