-
Notifications
You must be signed in to change notification settings - Fork 4.1k
ArgumentException when running diagnostic service on .net core #46687
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
Comments
FYI @mavasani |
Are you somehow passing in empty analyzers? I can handle a graceful bail out to return zero diagnostics when queries with zero analyzers, but I think there might be something on your side to investigate why there are no analyzers being passed in. Note that the current implementation for all invocations into remote side has validation on in-proc side to not even call into the remote side for no analyzers or all suppressed analyzers case. |
More specifically:
|
Paging in @tmat. I had an offline sync with Gen, and the issue seems to be happening in the roslyn/src/Compilers/Core/Portable/DiagnosticAnalyzer/DefaultAnalyzerAssemblyLoader.Core.cs Line 41 in 6afb1ee
Basically, we export the compiler diagnostic analyzer from roslyn/src/Compilers/CSharp/Portable/Compilation/CSharpCompilerDiagnosticAnalyzer.cs Lines 11 to 15 in 6afb1ee
Attempting to load analyzer assembly |
@tmat thoughts? |
|
@genlu There are multiple possible fixes depending on what we want our policy of loading analyzer assemblies and their dependencies to be. |
In this week's design meeting, it was decided this issue didn't need review. |
@JoeRobich This was marked for design review based on @tmat's comment here: #46687 (comment). Do you recall why this was marked as not needing review? |
The analyzer driver on .NET Core needs to create an Assembly Load Context (ALC) for each unique directory containing one or more analyzer references. This should eliminate the conflict. |
@mavasani In the meeting @sharwell said that it seemed like an implementation detail and he had a proposal for the compiler team.
Also, recommend using the AssemblyDepenencyResolver within the custom load context. This is a change (dotnet/format#1128) we recently made in dotnet-format to load the Razor source generator dependencies as they no longer ship in the same folder. This class will load them from the "deps.json" that is packaged with the assembly being loaded. |
Hey @mavasani, any update on this? |
Only happens when runing on servicehub core, don't repro on desktop. Deployed code is based on this PR #46026
servicehub log
The text was updated successfully, but these errors were encountered: