Invoking SGen creates a dependency on the repo local's shared framework

[ViktorHofer]

When using the repo local SDK ($(DotNetTool)) to invoke dotnet-Microsoft.XmlSerializer.Generator which dynamically (via reflection) loads the test assembly Microsoft.XmlSerializer.Generator.Tests.dll we create a dependency between the repo local shared framework and the test assembly.

This surfaces in the following error locally:

  .NET Xml Serialization Generation Utility, Version 6.0.0]
  Assembly 'C:\git\runtime2\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.
C:\git\runtime2\src\libraries\Microsoft.XmlSerializer.Generator\tests\Microsoft.XmlSerializer.Generator.Tests.csproj(45,5): warning : Fail to generate C:\git\runtime2\artifacts\bin\Microsoft.XmlSerializer.Generator.Tests\net5.0-Debug\Microsoft.XmlSerializer.Generator.Tests.XmlSerializers.cs
C:\git\runtime2\src\libraries\Microsoft.XmlSerializer.Generator\tests\Microsoft.XmlSerializer.Generator.Tests.csproj(46,5): error MSB3030: Could not copy the file "C:\git\runtime2\artifacts\bin\Microsoft.XmlSerializer.Generator.Tests\net5.0-Debug\Microsoft.XmlSerializer.Generator.Tests.XmlSerializers.cs" because it was not found.

The exact cause is that the call to Type.GetTypes fails with an ReflectionTypeLoadException saying that references with assembly version X can't be resolved.

This likely has to do with us bumping the assembly version of our shared framework assemblies to 6.0.0 while the SDK still uses 5.0.0 shared framework assemblies.

There are couple of options:

1. Don't feed an assembly to sgen that compiles against the very latest. Use ie a netcoreapp3.1 test helper assembly.
2. Don't invoke sgen during the test assembly's compilation at all.
3. Downgrade the test assembly (which is the input to sgen) to netcoreapp3.1. This is problematic as we would also need to downgrade TestUtilities and add support for testing non $(NetCoreAppCurrent) configurations (unreleated but we might want do this anyway at some point, similar to .NETFramework testing).
4. Upgrade to a 6.0 SDK. This would fix the issue temporarily but it would re-appear with 7.0.

This needs to be sorted out now as it already started to happen on my machine and because I thought it was related to one of my PRs I already lost multiple hours on that. Others will start noticing this soon as well.

cc @ericstj @Anipik @safern

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[ericstj]

1. Don't feed an assembly to sgen that compiles against the very latest. Use ie a netcoreapp3.1 test helper assembly.

This sounds better to me. We could make it netstandard2.1 or net5.0. It can be a helper assembly with just the types that sgen is operating on. My inclination is netstandard2.1 since it would work for source-build.

2. Don't invoke sgen during the test assembly's compilation at all.

This is done today because sgen produces C# which then needs to be compiled and we don't have a full SDK on the test machines.

3. Downgrade the test assembly

I'm not a fan of this for the reasons you called out. Also it doesn't work well for source build.

4. Upgrade to a 6.0 SDK

Although this would kick the can, it might buy time if the real issue here (#630) was fixed.

cc @mconnew @HongGit

[ericstj]

@ViktorHofer is this something you're blocked on now?

This likely has to do with us bumping the assembly version of our shared framework assemblies to 6.0.0 while the SDK still uses 5.0.0 shared framework assemblies.

I don't think we've done this yet, right @Anipik?

[safern]

This is done today because sgen produces C# which then needs to be compiled and we don't have a full SDK on the test machines.

Whenever we move to VSTest on CI, we will now have a full SDK on test machines... so maybe we can consider that option once we move to VSTest?

[ViktorHofer]

Whenever we move to VSTest on CI, we will now have a full SDK on test machines...

Not anymore, I reverted that change as we now consume VSTest directly via a transport package.

[ViktorHofer]

is this something you're blocked on now?

No, I'm not blocked by this at all. It's just something that devs will stumble upon locally.

[safern]

Not anymore, I reverted that change as we now consume VSTest directly via a transport package.

Ah that is true 😢

[ericstj]

It could be considered, you'd still need to figure out how to run the compiler (with appropriate references) in helix. IMHO we should make the smallest possible investment here to workaround this. The right fix is #630

[GrabYourPitchforks]

I've marked this issue blocking because it's now affecting my ability to create local builds.

C:\runtime.io\> .\build.cmd -s clr -c Release ; .\build.cmd -s libs+libs.tests -rc Release
<< snip >>
C:\runtime.io\src\libraries\Microsoft.XmlSerializer.Generator\tests\Microsoft.XmlSerializer.Generator.Tests.csproj(43,5): error : Fail to generate C:\runtime.io\artifacts\bin\Microsoft.XmlSerializer.Generator.Tests\net6.0-Debug\Microsoft.XmlSerializer.Generator.Tests.XmlSerializers.cs
C:\runtime.io\src\libraries\Microsoft.XmlSerializer.Generator\tests\Microsoft.XmlSerializer.Generator.Tests.csproj(44,5): error MSB3030: Could not copy the file "C:\runtime.io\artifacts\bin\Microsoft.XmlSerializer.Generator.Tests\net6.0-Debug\Microsoft.XmlSerializer.Generator.Tests.XmlSerializers.cs" because it was not found.
    0 Warning(s)
    2 Error(s)