Make DllImportGenerator unit tests' compilations use live refs

[elinor-fung]

• Add property (TestRunRequiresLiveRefPack) to indicate live refs should be copied to test output, such that they get included in the helix work item payload.
• Make DllImportGenerator unit tests use the live-built references during test run when compiling for the latest .NET version

Resolves #60605

@AaronRobinsonMSFT @jkoritzinsky

[AaronRobinsonMSFT]

@ericstj @danmoseley @stephentoub @safern - this approach is what all source generators should use for unit testing. The DllImport source generator has unit tests that check several snippets and this approach allows us to add new APIs in a PR and immediately test them using the live build.

[ericstj]

this approach is what all source generators should use for unit testing

Today other source generators are running the generators on the build machine rather than the test machine.

runtime/src/libraries/System.Text.Json/tests/System.Text.Json.SourceGeneration.Tests/System.Text.Json.SourceGeneration.Roslyn4.0.Tests.csproj

Line 6 in 5993a3a

<ProjectReference Include="..\..\gen\System.Text.Json.SourceGeneration.Roslyn4.0.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />

Is there a reason you decided to run the compiler on the test machine instead? Were you wanted to generate test code on the fly?

cc @eerhardt @layomia

[stephentoub]

Today other source generators are running the generators on the build machine rather than the test machine

The regex tests are executing the generator on the test machine, building against the implementation assemblies to avoid the hassle of using refs.

[jkoritzinsky]

We wanted to follow Roslyn best practice and use the Roslyn SDK testing APIs (at least the ones that were available when we started working on the source generator) to test our generator and analyzers.

We have separate tests that run the generator on the build machine, but we wanted some tests that ran as unit tests because the debugging experience is significantly better in VS when your entrypoint is an xunit test.

[AaronRobinsonMSFT]

We wanted to follow Roslyn best practice and use the Roslyn SDK testing APIs (at least the ones that were available when we started working on the source generator) to test our generator and analyzers.

This was the key point for us. The Roslyn team's "best practices" were our guide in most if not all decisions and this fell out of that.

/cc @jaredpar @chsienki

[elinor-fung]

I though the unit tests were running the generator on the test machine?

https://github.com/dotnet/runtime/blob/5993a3a033af58ec6b749312028e763d5ac20296/src/libraries/System.Text.Json/tests/System.Text.Json.SourceGeneration.Unit.Tests/CompilationHelper.cs

[ericstj]

@elinor-fung -- those are the basic unit tests that are less sensitive to references. I believe their meant to excercise the basic functionality of the generator and cover edge cases like invalid syntax etc that doesn't build correctly.

There's a larger test suite that covers the behavior of runtime with generated code that runs the generator on the build machine. Those actually compile and execute the result. I believe we found it simpler to compile those on the build machine since it makes the tests simpler: they look more like the customer code.