Run each analyzers/source-generators in a separate process

[Eli-Black-Work]

My understanding is that currently, source generators and analyzers are loaded into and run inside the main VS/MSBuild process.

It seems like there could be a lot of advantages to running each analyzer/source-generator in a separate process 🙂

• No NuGet package version conflicts.
  • Currently, if AnalyzerA has a strict dependency on ExampleNuGet 4.0.0 and AnalyzerB has a strict dependency on ExampleNuGet 4.1.0, then MyProject is unable to depend on both AnalyzerA and AnalyzerB.
• Analyzers/source-generators could no longer be restricted to .NET Standard 2.0.
• Analyzers/source-generators could be run in parallel and across multiple cores.
  • (This might already happen, via multiple threads instead of multiple processes)

I'm sure this has already been considered, but I think it'd make for an interesting discussion, nonetheless, and maybe something productive can come out of it 🙂

[jasonmalinowski]

Analyzers/source-generators could be run in parallel and across multiple cores.

We already are doing this, just via threads. Please make sure your generator is thread safe!

It seems like there could be a lot of advantages to running each analyzer/source-generator in a separate process 🙂

If by "separate process" you mean each gets its entirely own process (n generators means n processes), that would have a lot of overhead. Creating all the SyntaxTrees and SemanticModels isn't cheap, and we get a lot of performance wins by being able to share those between analyzers and generators. As it stands, we actually are running generators in two places in VS: the main VS process and our OOP process, and just having two is already more expensive than we'd like. Getting that back down to one process is the main goal here.

No NuGet package version conflicts.

Once we get more stuff moved to .NET Core this goes away, since we're able to isolate things better there with AssemblyLoadContexts. It also allows us to do much more sane unloading. We're currently working on getting our OOP process moved over, at which point we're going to look at getting generators running in just that process.

Analyzers/source-generators could no longer be restricted to .NET Standard 2.0.

Is this causing a specific limitation? We have this limitation currently not just because of VS, but also because of VS Code and other ecosystem tools that aren't all on .NET Core.

[PathogenDavid]

Is this causing a specific limitation?

It's never a showstopper, but when most of your day-to-day work is being done in .NET 6/7 it can be pretty ugh to regress to the good ol' days of .NET Framework 4.7.2/.NET Core 2.0. (It's especially ick if you're a goody two-shoes and follow the blessed path of limiting yourself to C# 7.3.)

VS Code and other ecosystem tools that aren't all on .NET Core.

My understanding is this is no longer true in newer versions of OmniSharp. (You can still run it in Mono/.NET Framework mode, but it's no longer the default.)

Is there anything affecting most developers besides Visual Studio and Visual Studio's copy of MSBuild that is stuck on .NET Framework?

[jasonmalinowski]

Is there anything affecting most developers besides Visual Studio and Visual Studio's copy of MSBuild that is stuck on .NET Framework?

It's Visual Studio. Technically the MSBuild one doesn't matter as much since the compiler can run on .NET Core independently, and it's only the compiler process actually loading the generator.

[PathogenDavid]

Cool, thanks for the clarification!