Switch to using the .NET SDK properties that are defined to provide the TFM instead of using the assembly that defines System.Object

[jkoritzinsky]

Switch to using MSBuild properties defined by the .NET SDK or inferring the TFM from the generator version (as it ships with the TFM and is versioned identically) and using another SyntaxProvider to enable us to construct a StubEnvironment object accurately without having to query any information directly from the Compilation object. In addition to fixing #80621, this change effectively enables all of the calculation work here to be done less often in a VS session. Previously we recalculated all of the information per keystroke. Now we'll only recalculate the SkipLocalsInit check when the user provides or removes a SkipLocalsInit attribute in their code or changes their TFM.

We should backport this PR to .NET 7 to ensure good performance in VS.

Fixes #80621

[ghost]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Switch to using MSBuild properties defined by the .NET SDK or inferring the TFM from the generator version (as it ships with the TFM and is versioned identically) and using another SyntaxProvider to enable us to construct a StubEnvironment object accurately without having to query any information directly from the Compilation object. In addition to fixing #80621, this change effectively enables all of the calculation work here to be done less often in a VS session. Previously we recalculated all of the information per keystroke. Now we'll only recalculate the SkipLocalsInit check when the user provides or removes a SkipLocalsInit attribute in their code or changes their TFM.

We should backport this PR to .NET 7 to ensure good performance in VS.

Author:	jkoritzinsky
Assignees:	-
Labels:	area-System.Runtime.InteropServices, tenet-performance, source-generator
Milestone:	-

[jaredpar]

@chsienki PTAL

[chsienki]

LGTM. An alternative approach would be to use the MetadataReferencesProvider to look at System.Runtime or appropriate to figure out the target version rather than relying on the TFM from MSBuild; that would also only change when the user actually changes the TFM, rather than per key stroke, but I think either approach is fine.

[AaronRobinsonMSFT]

An alternative approach would be to use the MetadataReferencesProvider to look at System.Runtime or appropriate to figure out the target version rather than relying on the TFM from MSBuild;

@chsienki Would this mean looking at the version of the System.Runtime assembly?

[jkoritzinsky]

I looked at using the MetadataReferencesProvider. The up-side is that it will work in more scenarios and we won't need to fall back to our "use current assembly version" case as often. However, it looks like it can be a file path or an assembly name, which makes it hard to parse and adds complexity. I think for now, this is the best solution.

[jkoritzinsky]

The timeout is a known issue according to Build Analysis, so I'm going to merge this in.