-
Notifications
You must be signed in to change notification settings - Fork 10.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
[Announcement] Known issue in 3.0.2 and 3.1.1 for ASP.NET Core #18334
Comments
Oops, meant to lock the issue in aspnet/Announcements, not here. |
Workaround doesn't work as adding
Gives the following build error
|
Experiencing the same issue as @benaadams above. Nuget indicates that there isn't a 3.1.1.1 version of Microsoft.AspNetCore.Razor.Runtime, but that's the error I see in my own exception.
This is breaking on a line during local debug within ConfigureServices with the following:
Per a related issue, I did indeed update Microsoft.AspNetCore.Authentication.AzureAD.UI to 3.1.1 when experiencing this issue. As they were mentioned in the other issue, we're running x64 here and we do not use Microsoft.AspNetCore.Identity.UI. |
Same here. Just upgraded my app from 2.1 to 3.1 and getting this error. |
@wtgodbe @JunTaoLuo it looks like we may have missed a case here. Can one of you take a look and see if there is a workaround here? |
The issue may affect all of the *.UI packages so we'll need to update the announcement. As for the errors, I'm surprised it's missing M.A.Razor.Runtime since it is included in the 3.1.1 runtime. I'll try reproducing the issue and report back. |
We are getting the same error after upgrading our app from 2.2 to 3.1:
We solved it locally by removing [Authenticate] attribute from our controllers. But Azure App Service instance (Windows, east2) is still giving this error. |
I downgraded the version of Microsoft.AspNetCore.Authentication.AzureAD.UI from 3.1.1 to 3.1.0 and it is working now. A similar issue is described here #18401 (comment) |
@benaadams @iSeiryu did you install the latest 3.1.1 shared framework when you updated your *.UI packages to 3.1.1? |
@JunTaoLuo No issues among my solution when I downgraded to 3.1.0, only an issue in 3.1.1. |
@WhitWaldo does this repro if you upgrade both the AspNetCore runtime & Microsoft.AspNetCore.Authentication.AzureAD.UI to 3.1.1? Or only if you upgrade Microsoft.AspNetCore.Authentication.AzureAD.UI? |
@Pilchie I believe we need to update this issue to state that you must update your AspNetCore runtime if you want to update your dependency on any of the affected packages, as otherwise there won't be an assembly available with the |
@wtgodbe I had upgraded all AspNetCore packages to 3.1.1 (commented on this issue last night following this upgrade) and this morning downgraded them all to 3.1.0 (worked fine after the collective downgrade). I haven't tried just upgrading or downgrading the one package (M.A. A.AzureAD.UI). |
@JunTaoLuo issue might be secondary transitive dependencies; so this is coming from a (local) library I include that has a FrameworkReference reference e.g. <ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup> And it uses the attribute At a guess this would be similar issue with |
@WhitWaldo I believe you also need to download the 3.1.1 AspNetCore runtime, which you can do from here. The affected 3.1.1 packages won't work with the 3.1.0 runtime. |
We had a lot of problems with this issue:
We've had this issue for a week until we finally found this page with a possible fix of downgrading AzureAD.UI package today. People were threatened to be fired over it (this is a HUGE project).
|
To me it wasn't very clear that installing 3.1.1 packages from nuget requires having a 3.1.1 runtime installed, which is currently not available on azure app services and pipeline runners. Projects do compile on runners with 3.1.0 without a problem (as SCD and FDD), but they can not be run afterwards. It seems like this wasn't clear to others around here too so possibly it might be worth considering to state this clearer in the docs/announcement. Additionally I think it would be great to provide docs for the workaround solutions to get this working in app services immediately with an example, i.e. like this:
|
@wtgodbe yes looks like its issue installed runtime being 3.1.0 and not 3.1.1 Can this dependency issue be trapped and indicated earlier in some manner? e.g. why is NuGet allowing me to install libraries that will be incompatible. Is it because its depending on |
Or perhaps the frameworkreference in libraries needs to accept versions rather than being unversioned so it can be detected at compile time? <FrameworkReference Include="Microsoft.AspNetCore.App" /> e.g. it should be <FrameworkReference Include="Microsoft.AspNetCore.App" version="3.1.0" /> Which could then error saying it needs to be 3.1.1? <FrameworkReference Include="Microsoft.AspNetCore.App" version="3.1.1" /> |
Removing Microsoft.AspNetCore.Identity.UI from the project solves the issue for me. |
However, with 3.1.1 installed after upgrading packages System.TypeLoadException: Method 'CommonGetWellKnownType'
in type 'Microsoft.CodeAnalysis.CSharp.CSharpCompilation'
from assembly 'Microsoft.CodeAnalysis.CSharp, Version=3.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
does not have an implementation.
at Microsoft.CodeAnalysis.Razor.CompilationTagHelperFeature.GetDescriptors()
at Microsoft.AspNetCore.Razor.Language.DefaultRazorTagHelperBinderPhase.ExecuteCore(RazorCodeDocument codeDocument)
at Microsoft.AspNetCore.Razor.Language.RazorEnginePhaseBase.Execute(RazorCodeDocument codeDocument)
at Microsoft.AspNetCore.Razor.Language.DefaultRazorEngine.Process(RazorCodeDocument document)
at Microsoft.AspNetCore.Razor.Language.DefaultRazorProjectEngine.ProcessCore(RazorCodeDocument codeDocument)
at Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.Process(RazorProjectItem projectItem)
at Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.RuntimeViewCompiler.CompileAndEmit(String relativePath)
at Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.RuntimeViewCompiler.OnCacheMiss(String normalizedPath)
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.DefaultPageLoader.LoadAsyncCore(PageActionDescriptor actionDescriptor)
at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageLoaderMatcherPolicy.ApplyAsyncAwaited(CandidateSet candidates, Task`1 actionDescriptorTask, Int32 index)
at Microsoft.AspNetCore.Routing.Matching.DfaMatcher.SelectEndpointWithPoliciesAsync(HttpContext httpContext, IEndpointSelectorPolicy[] policies, CandidateSet candidateSet)
at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.<Invoke>g__AwaitMatch|8_1(EndpointRoutingMiddleware middleware, HttpContext httpContext, Task matchTask) Which needs the following in the .csproj to resolve <PackageReference Include="Microsoft.CodeAnalysis.Common" Version="3.4.0" />
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="3.4.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="3.1.1" /> |
This is because we made a mistake in building some of these binaries, so they accidentally have a dependency on binaries in 3.1.1. We've addressed that for the upcoming 3.1.2. Instead of inventing features for NuGet or FrameworkReferences, let's just fix the bug so that things work as intended 😉
😢. Thanks for letting us know. I'll work on updating the announcement today with some more scenarios. |
Just switching azure app service to x64 did NOT resolve the problem for me FYI reverding ad UI to 3.1.0 resolved it |
This normally wouldn't be the case, but the bug described by this issue has caused certain 3.1.1 packages to be incompatible with the 3.1.0 runtime, and vice versa. We have a fix for the issue that will ship with 3.1.2 in February |
did not work for me. I was using Azure App Service on Linux with .NET Core 3.1 Runtime. Edit: Seems that the container was still using version 3.0.0. Ended up SSH-ing in and manually installing runtime 3.1.1 Edit2: obviously it did not work, since the container was restarted 👎 |
Yes
First time in a while that I have visited |
Even with SDK 3.1.101 I had to move back to 3.1.0 for AzureAD.UI package. Just an FYI. |
There are two issues:
|
Can y’all prioritize getting 3.1.2 on Azure App Service please? We’re still waiting for 3.1.1 global rollout and SDK |
please prioritize |
Same issue on creating a new web app from template using visual studio 2019 version 16.4 : |
|
This should be fixed in the 3.1.2 release that was published today (2020-02-18). Please file a new issue on https://github.com/dotnet/aspnetcore if you are still seeing issues. |
Packages and Shared Framework
Scenario
If your project has a package reference that transtively references certain assemblies in the Microsoft.AspNetCore.App shared framework
that are also available as NuGet packages and executes on a runtime other than 64-bit Windows, you will receive a runtime exception at the time the assembly is loaded with a message like:
Workaround
Reference the package for the assembly which is failing to load explicitly in your application.
List of assemblies impacted:
Identity UI
Scenario
Alternatively, if you use the Microsoft.AspNetCore.Identity.UI package and executes on a runtime other than 64-bit Windows, you will receive a runtime exception at the time the Microsoft.AspNetCore.Http.Features assembly is loaded with a message like:
Workaround
Reference the Microsoft.AspNetCore.Http.Features package explicitly in your application.
Azure App Service
Note that by default Azure App Service runs websites in an x86 Windows environment, so you might see these issues when you deploy to
Azure App Service, even if your app works locally on your 64-bit Windows development machine. To workaround, you can either apply one of
the workarounds above or configure your app to run in a 64-bit environment. See the documentation for details.
See also
aspnet/Announcements#398 which is still present in these releases.
The text was updated successfully, but these errors were encountered: