Closed KirillOsenkov closed 1 month ago
No clue what could happen here. That entire method is:
protected override Task<ImmutableArray<CodeAction>> GetCodeActionsAsync(
Document document, SyntaxNode node, CancellationToken cancellationToken)
{
var service = document.GetLanguageService<IGenerateVariableService>();
return service.GenerateVariableAsync(document, node, cancellationToken);
}
The only thing that could null ref would be if we got a null document or GetLanguageService failed. The latter can't fail as this is exported for just C# only. The former also can't happen as we would only have a Document to get into the C# case to begin with. This isn't actionable in the current state. We'll need a dump or something.
ah OK I have it under debugger.
The call to GetLanguageService
Microsoft.CodeAnalysis.Workspaces LayeredServiceUtilities.PickService Line 37
Microsoft.CodeAnalysis.Workspaces MefLanguageServices.<TryGetService>b__12_0 Line 67
System.Collections.Immutable ImmutableInterlocked.GetOrAdd
Microsoft.CodeAnalysis.Workspaces MefLanguageServices.TryGetService Line 67
Microsoft.CodeAnalysis.Workspaces MefLanguageServices.GetService Line 53
Microsoft.CodeAnalysis.CodeStyle.Fixes CodeStyleHostLanguageServices.GetService
Microsoft.CodeAnalysis.CodeStyle.Fixes ProjectExtensions.GetLanguageService
Microsoft.CodeAnalysis.CodeStyle.Fixes DocumentExtensions.GetLanguageService
Microsoft.CodeAnalysis.CSharp.CodeStyle.Fixes CSharpGenerateVariableCodeFixProvider.GetCodeActionsAsync
This is the code that fails to find the service: https://github.com/dotnet/roslyn/blob/244b7e544a168ab5c610791336638a8e51abe748/src/Workspaces/SharedUtilitiesAndExtensions/Workspace/Core/Workspace/Mef/LayeredServiceUtilities.cs#L37
assemblyQualifiedName
is:
Microsoft.CodeAnalysis.GenerateMember.GenerateVariable.IGenerateVariableService, Microsoft.CodeAnalysis.CodeStyle.Fixes, Version=4.12.10.42208, Culture=neutral, PublicKeyToken=31bf3856ad364e35
it comes from
...\AnalyzerAssemblyLoader\ae96c9d5722b4b3eaeba100b0377bbde\86391754-9220-4ba8-98ef-406e465fa4f3\Microsoft.CodeAnalysis.CodeStyle.Fixes.dll
whereas the service in the services list has the ServiceType metadata:
Microsoft.CodeAnalysis.GenerateMember.GenerateVariable.IGenerateVariableService, Microsoft.CodeAnalysis.Features, Version=4.11.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
since it's comparing the entire string, the comparison fails, and so the service isn't found.
The analyzers involved do come from the SDK: C:\Program Files\dotnet\sdk\9.0.100-rc.1.24452.12\Sdks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CSharp.CodeStyle.Fixes.dll
I can't share the dump here but it's available privately.
This one also has the service, but with the wrong full name: https://github.com/dotnet/roslyn/blob/244b7e544a168ab5c610791336638a8e51abe748/src/CodeStyle/Core/CodeFixes/Host/Mef/CodeStyleHostLanguageServices.MefHostExportProvider.cs#L19
The full name here is also: Microsoft.CodeAnalysis.GenerateMember.GenerateVariable.IGenerateVariableService, Microsoft.CodeAnalysis.Features, Version=4.11.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
It's likely because the host IDE uses Roslyn 17.11.2, whereas the analyzers are from 17.12 already, and the code fixes have been moved down three months ago: https://github.com/dotnet/roslyn/pull/74567
So we're in the torn state.
Repro:
<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
in the .csprojfoo;
I'm not sure it's actionable unless there's a bug in the services lookup logic where it uses the wrong identity for a service (the one from the IDE vs. the one from the CodeFixes analyzers)
@JoeRobich does your work with a torn sdk help here?
Yes, VS and VSCode should no longer load the CodeStyle analyzers or fixes. See https://github.com/dotnet/roslyn/pull/75250
So Roslyn hosts are expected to just not load the CodeStyle analyzers from the SDK, right?
So Roslyn hosts are expected to just not load the CodeStyle analyzers from the SDK, right?
Right, the VS hosts carry the Features layer assemblies which contain the same analyzers and fixes. This change will be in 17.12 along with other work to help torn state issues between VS and SDK.
Wait, I'm confused. Didn't @CyrusNajmabadi move these down in https://github.com/dotnet/roslyn/pull/74567
The PR description is a bit lacking there so I'm not sure where it moved from and to.
Saw this in the wild in someone's logs, no line number or repro unfortunately, but perhaps simple eyeballing or adding nullable could fix this.