Runtime: Building libs.tests fails in XmlSerializer.Generator.Tests

[carlossanlop]

I have a clean enlistment synced to the latest runtime commit in master.
I ran .\build.cmd clr+libs -rc release without problem.
When I build .\build.cmd libs.tests -rc release, I get this error:

Assembly 'D:\runtime\artifacts\bin\Microsoft.XmlSerializer.Generator.Tests\net5.0-Debug\Microsoft.XmlSerializer.Generator.Tests.dll' does not contain any types that can be serialized using XmlSerializer.
D:\runtime\src\libraries\Microsoft.XmlSerializer.Generator\tests\Microsoft.XmlSerializer.Generator.Tests.csproj(47,5): error : Fail to generate D:\runtime\artifacts\bin\Microsoft.XmlSerializer.Generator.Tests\net5.0-Debug\Microsoft.XmlSerializer.Generator.Tests.XmlSerializers.cs
D:\runtime\src\libraries\Microsoft.XmlSerializer.Generator\tests\Microsoft.XmlSerializer.Generator.Tests.csproj(48,5): error MSB3030: Could not copy the file "D:\runtime\artifacts\bin\Microsoft.XmlSerializer.Generator.Tests\net5.0-Debug\Microsoft.XmlSerializer.Generator.Tests.XmlSerializers.cs" because it was not found.

Let me know if you need more info.

[msftbot[bot]]

Tagging subscribers to this area: @safern, @viktorhofer
Notify danmosemsft if you want to be subscribed.

[safern]

cc: @ViktorHofer @ericstj -- maybe a fallout from: https://github.com/dotnet/runtime/commit/8790adefae322d2e6d680c8fb3470081bea0da0b

What is weird is that CI is not failing and CI is doing build.cmd libs.tests. @carlossanlop was this in your regular machine or the Surface Pro X?

[ericstj]

Odd. I'd expect serializable types to come from here https://github.com/dotnet/runtime/blob/8892364dffd62c478d398292a4f2699500bbb61c/src/libraries/Microsoft.XmlSerializer.Generator/tests/Microsoft.XmlSerializer.Generator.Tests.csproj#L18

One thing that comes to mind would be that this could happen if you were messing with TargetArchitecture. For instance if you set it to arm64 and built the project (meant to skip) then set it to something else like amd64. It's possible compiler wouldn't rebuild due to incremental, but would try to run the generator.

[ericstj]

Frankly think we shouldn't be conditioning the test this way as it could cause these incremental build issues since the project doesn't represent these as configurations. Instead we should have the condition as attribute on the test.

[ViktorHofer]

Agreed with using runtime detection over compile time exclusion. Probably via an XUnitExtensions attribute? cc @safern

[carlossanlop]

was this in your regular machine or the Surface Pro X?

@safern so far I've seen it in my ARM64 surface, but if I see it in my x64 PC I'll let you know.

[safern]

Then I think that confirms @ericstj statement.

[carlossanlop]

@safern @ericstj I built my x64 PC and I also saw the failure there:

Build FAILED.

D:\runtime\src\libraries\Microsoft.XmlSerializer.Generator\tests\Microsoft.XmlSerializer.Generator.Tests.csproj(47,5): error : Fail to generate D:\runtime\artifacts\bin\Microsoft.XmlSerializer.Generator.Tests\net5.0-Release\Microsoft.XmlSerializer.Generator.Tests.XmlSerializers.cs
D:\runtime\src\libraries\Microsoft.XmlSerializer.Generator\tests\Microsoft.XmlSerializer.Generator.Tests.csproj(48,5): error MSB3030: Could not copy the file "D:\runtime\artifacts\bin\Microsoft.XmlSerializer.Generator.Tests\net5.0-Release\Microsoft.XmlSerializer.Generator.Tests.XmlSerializers.cs" because it was not found.
    0 Warning(s)
    2 Error(s)

Time Elapsed 00:10:11.61
Build failed.
Some builds failed:
        Configuration: release, Architecture: x64

This is the command I used:
.\build.cmd clr+libs+libs.tests -c release -arch x64

[ericstj]

I looked at Carlos's machine. The assembly had the types present. The problem is that the tool was running on an old shared framework.

1. Carlos had the verison of dotnet required by the repo installed machine-wide, so build didn't acquire a local copy.
2. Carlos had a 2.x shared framework installed machine-wide.
3. The tool preferred the 2.0.0 machine-wide framework, which couldn't analyze the net5.0 test assembly.

Ultimately the bug here is that this tool is doing runtime-reflection on build assets:
https://github.com/dotnet/runtime/blob/69b0d160953f5c920e52f021366743623693c158/src/libraries/Microsoft.XmlSerializer.Generator/src/Sgen.cs#L444

This is an age-old problem where a build tool conflates build-framework with target-framework. Instead of doing runtime-reflection, this tool should be changed to read metadata. That should be much easier now with MetadataLoadContext. I suspect that's the root cause of https://github.com/dotnet/runtime/issues/1390.

The reason this regressed was because we stopped using the test-framework to execute the tool. The reason it's only happening for Carlos is the set of things I called out above. Perhaps a workaround would be to change https://github.com/dotnet/runtime/blob/69b0d160953f5c920e52f021366743623693c158/src/libraries/Microsoft.XmlSerializer.Generator/pkg/build/dotnet-Microsoft.XmlSerializer.Generator.runtimeconfig.json#L8 to

  "rollForward": "LatestMajor"

cc @HongGit @StephenBonikowsky @StephenMolloy