-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
NRE in GetExplicitInterfaceImplementations when building dotnet/runtime #46575
Comments
FYI @safern |
OK, for a bit there we weren't sure if this bug was still present. But I think this CI run proves that it is: https://dev.azure.com/dnceng/public/_build/results?buildId=772143&view=logs&jobId=a2760323-e082-593b-18aa-f95a2816e578&j=a2760323-e082-593b-18aa-f95a2816e578&t=0fbc4e79-59cd-554b-7461-d6af1a16e28d |
We have added a workaround to the compiler which we should remove once we and our customers are ready to consume a .NET 5 runtime that has the fix. |
@RikkiGibson and @jaredpar just FYI aspnet/extensions is hitting this as well:
|
The latest compilers from the VS 16.8 channel should not have this issue. Is there a PR which updates the roslyn dependency for that repo? |
Yes, we're updating it to the same version as dotnet/runtime. |
Could you please link the PR? |
This is one: dotnet/aspnetcore#25545 @Anipik do you have the one for extensions? |
FYI: @dougbu in case you don't want to downgrade |
(I hope to get dotnet/aspnetcore#25545 in as soon as I hear from my co-workers about the macOS timeouts we're also hitting and that I'm changing there. But, we can follow up later if necessary and I may not hear back today.) Choosing a newer version of Microsoft.Net.Compilers.Toolset and leaving it unpinned in aspnetcore and aspnetcore-tooling is our current plan for the master branches now that arcade and aspnetcore use the same Mastro++ channels for this dependency (thanks @mmitche❕). But, based on our offline discussion about different versions used in the RC2 branches, I lean toward choosing a single version of this dependency for runtime, aspnetcore, aspnetcore-tooling, and extensions ASAP i.e. pinning them all at the same version (ignoring whatever arcade chooses from here on). So, @Anipik @ericstj @safern will runtime and extensions move to something between |
Since we don't need a compiler feature in runtime or extensions I don't think we will put up an update just to get a "newer" compiler in RC1/2 however we can do it in runtime or arcade master to dog food |
I had meant to use this issue to track removing the workaround once we had a version of dotnet/runtime with the fix. We might be ready to do that now, so maybe I'll just give it a try and send the PR later this morning. |
Version Used: 81c5d71
Steps to Reproduce:
.\Build.cmd -pack -configuration Release
in Roslyn, then set up a dotnet/runtime enlistment to use your locally build compiler. You may use branch https://github.com/RikkiGibson/runtime/tree/use-local-roslyn as a starting point. NOTE: you must build a release package to repro this bug and change theRestoreAdditionalProjectSources
path from Debug to Release.Once that is complete, run
.\Build.cmd -subset libs
to repro the bug.Expected Behavior:
Builds without errors
Actual Behavior:
The text was updated successfully, but these errors were encountered: