Add infrastructure for trimming and NativeAOT test apps.

[AndriySvyryd]

Part of #29761

Based on dotnet/aspnetcore#48024

The tests themselves are disabled as there are still lots of warnings that are now treated as errors.

[AndriySvyryd]

cc @eerhardt

[roji]

@AndriySvyryd this is really nice! Is this a copy-paste of the technique used in the runtime for this kind of tests? If so, it may be good to push for making this reusable across the repos (/cc @eerhardt).

[eerhardt]

I'm confused at the intention here. There are 2 kinds of trimming/aot tests:

1. Tests that analyze your whole library and ensure there are no trimming/aot warnings.
2. Tests that execute a specific scenario under trimming/aot and ensure the scenario works correctly.

Which type of tests are these? If it is the latter (2), then these are going to have to change. You don't put .csproj files in the test directory, but instead use a XX.TrimmingTests.proj file that imports the trimmingtests.props/targets files. When you dotnet test that project, it will generate .csproj files that are published and executed.

[AndriySvyryd]

Which type of tests are these?

Both. The EndToEnd tests should reference most of the code and ensure there are no warnings, the other tests would be specific scenarios.

You don't put .csproj files in the test directory

Why not? Having the .csproj makes the tests easy to author, and from the command line they work the same as a .proj as it imports the trimmingtests.props/targets files

[eerhardt]

Why not?

Because you are conflating the 2 scenarios. In the 2nd scenario, you have multiple Main methods - one for each scenario you are trying to test. How can you build 5 Main methods into a single .csproj?

[AndriySvyryd]

How can you build 5 Main methods into a single .csproj?

I don't, the 'Build' target is overridden to do nothing, so VS will just ignore it when building, even if there are compilation errors.

[eerhardt]

the 'Build' target is overridden to do nothing

That's why you don't use a .csproj. .csproj is supposed to build C# code into a .NET .dll or .exe.

[AndriySvyryd]

That's why you don't use a .csproj. .csproj is supposed to build C# code into a .NET .dll or .exe.

You are right, but pragmatically .csproj is more useful as there's better support for it across IDEs.

[AndriySvyryd]

Is this a copy-paste of the technique used in the runtime for this kind of tests? If so, it may be good to push for making this reusable across the repos

It's similar, but I added support for shared files in subfolders and for PackageReference.

However, the way it's run differs. For efcore they run during Test, in runtime they run during Build, in aspnetcore they run during Test on a delayed build. So, unifying the source code wouldn't be trivial.