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
Problems with ASP.NET projects when consuming .NET Standard assets #25770
Comments
cc: @AlexGhiondea @karelz FYI |
Adding @AngelosP who is going to help with this. |
Internal work item ID 595443. Scheduled meeting for Monday to discuss next steps. |
i had this issue and had to install vcredist2015/2017 to fix it |
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 |
@JanEggers that doesn't at all sound like the same issue. Thank you @joperezr and @AngelosP for getting this on the radar. |
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) |
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 |
@joperezr FYI, the issue seems to be fixed when targeting the recently released .NET 4.7.2 |
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 😄 |
@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 One example of such a package is: https://github.com/Antaris/RazorEngine .. It has a dependency on |
@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 |
@joperezr here you go .. I can also post a minimal repo up on github if you like, let me know. |
thanks a lot! I'm taking a look at the binlog now, I'll let you know if that is not enough. |
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. |
Thanks @joperezr |
It seems like this error is related to the issues I'm facing with ASP.NET Core targeting .NET 4.7.2 |
@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:
On a side note, unlike described in dotnet/sdk#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 |
Adding app.config with a bindingRedirect carries over to the My recommendation would be that if a user created app.config is detected, the compiler should respect any
|
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. |
@joperezr is this issue still tracking an external issue (see label)? dotnet/sdk#2221 is already closed so I'm wondering if this issue is actionable on our side. Thanks |
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. |
Thanks for the explanation. Given this issue isn't actionable anymore, I'm closing it. |
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:
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 #24382 as it was dicussed on this comment: https://github.com/dotnet/corefx/issues/25773#issuecomment-378341475
cc: @AlexGhiondea
The text was updated successfully, but these errors were encountered: