How to get this working with VS Code

[JackUkleja]

I've just added the package to a vanilla class library in latest VS Code. I'm a little rusty with this stuff, but I can't for the life of me figure out how to get the code generation working. I've followed the instructions with the NativeMethods.txt but nothing happens on build. The animated gif indicates it should generate some code.

[AArnott]

What do you mean by "nothing happens on build"? VS Code doesn't build code. The build happens with the .NET CLI, and that works:

What I see failing isn't the build, but that Omnisharp, which provides the C# language service experience in VS Code, isn't running the code generation in memory, such that VS Code shows squiggles and "Problems" as if the code gen hadn't happened, although the build actually works.

I don't know what it would take for VS Code to take source generators into account. That is probably a good question for the Omnisharp folks. As I don't know anyone who works on that, I wonder if @jinujoseph has any ideas.

[jasonmalinowski]

Alright will take a look next week.

[jasonmalinowski]

And by "next week" I clearly meant "a month or two". Sorry about that. 😢

So sticking a debugger onto the Omnisharp process, it appears the generator is throwing an exception. We also seem to be eating the exception rather than reporting it, so we'll need to fix that! But the exception is:

Could not load file or assembly 'System.Numerics.Vectors, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Which seems to point to the first problem: the generator package is packaging dependencies like System.Text.Json, but isn't packaging dependencies of System.Text.Json (namely System.Numerics.Vectors):

CsWin32/src/Microsoft.Windows.CsWin32/Microsoft.Windows.CsWin32.targets

Lines 23 to 35 in e67e9c5

	<Target Name="PackBuildOutputs" DependsOnTargets="ResolveProjectReferences;SatelliteDllsProjectOutputGroup;SatelliteDllsProjectOutputGroupDependencies">
	<ItemGroup>
	<!-- Analysis of C# projects -->
	<TfmSpecificPackageFile Include="$(TargetPath)" PackagePath="analyzers\cs\" />
	<TfmSpecificPackageFile Include="@(ReferencePath)" PackagePath="analyzers\cs\" Condition=" '%(FileName)%(Extension)' == 'YamlDotNet.dll' " />
	<TfmSpecificPackageFile Include="@(ReferencePath)" PackagePath="analyzers\cs\" Condition=" '%(FileName)%(Extension)' == 'Microsoft.Bcl.AsyncInterfaces.dll' " />
	<TfmSpecificPackageFile Include="@(ReferencePath)" PackagePath="analyzers\cs\" Condition=" '%(FileName)%(Extension)' == 'System.Text.Json.dll' " />
	<TfmSpecificPackageFile Include="@(ReferencePath)" PackagePath="analyzers\cs\" Condition=" '%(FileName)%(Extension)' == 'System.Text.Encodings.Web.dll' " />
	<TfmSpecificPackageFile Include="@(SatelliteDllsProjectOutputGroupDependency)" PackagePath="analyzers\cs\%(SatelliteDllsProjectOutputGroupDependency.DestinationSubDirectory)" Condition=" '%(SatelliteDllsProjectOutputGroupDependency.DestinationSubDirectory)' != '' " />
	<TfmSpecificPackageFile Include="@(SatelliteDllsProjectOutputGroupOutput->'%(FinalOutputPath)')" PackagePath="analyzers\cs\%(SatelliteDllsProjectOutputGroupOutput.Culture)\" />
	<TfmSpecificPackageFile Include="%(_ResolvedProjectReferencePaths.Identity)" PackagePath="analyzers\cs\" />
	</ItemGroup>
	</Target>

So that probably should be updated to copy in the dependency. Why does this not matter for the command line compiler? Because command line Roslyn already ships System.Numerics.Vectors and has a binding redirect from the version CsWin32 is using to the version Roslyn ship.

I tried copying the version used into the NuGet package to test locally and found it still doesn't work. The second problem seems to be that Omnisharp isn't handling the dependencies like I'd expect it to. Omnisharp does ship System.Numerics.Vectors, but doesn't have a binding redirect. In this case, I'd expect that the analyzer assembly loader should kick in, hook AssemblyResolve and provide the correct version. But if I look at the Omnisharp's "did I hook resolve" flag in the dump I see that's unset, which makes me think we also have a Omnisharp bug here as well. I'll file a bug momentarily for that.

I can confirm if I hack in a binding redirect into the Omnisharp the generator then works.

[jasonmalinowski]

Ah, the Omnisharp code was copy/pasted from Roslyn, which had a bug: dotnet/roslyn#53166

[AArnott]

Thanks. I filed #261 to track your suggested change in our package.

[jasonmalinowski]

And I've filed dotnet/roslyn#53672 to track the next fix we need to make in Roslyn (and by extension Omnisharp) to make this work.

[BinToss]

I've decided to open an issue on OmniSharp/omnisharp-roslyn since the previous thread ended with several resolved Issues while seemingly not resolving this one.
dotnet/vscode-csharp#5080