Microsoft.XmlSerializer.Generator 5.0.0 does not work with WCF Core 3.2.1

[kornelpal]

Description

While evaluating workarounds for #58093, I kept running into errors with Microsoft.XmlSerializer.Generator and WCF Core:

.NET Xml Serialization Generation Utility, Version 5.0.0]
SGEN : warning SGEN1: Could not load file or assembly 'System.ServiceModel.Primitives, Version=4.8.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL'. Reference assemblies should not be loaded for execution.  They can only be loaded in the Reflection-only loader context. (0x80131058)
SGEN : warning SGEN1: Cannot load a reference assembly for execution.
A BadImageFormatException has been thrown while parsing the signature. This is likely due to lack of a generic context. Ensure genericTypeArguments and genericMethodArguments are provided and contain enough context.
Could not load file or assembly 'System.ServiceModel.Primitives, Version=4.8.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Reference assemblies should not be loaded for execution.  They can only be loaded in the Reflection-only loader context. (0x80131058)
Cannot load a reference assembly for execution.

Although seems to be a hack, dotnet/corefx#32403 added a workaround for a similar problem that worked while WCF Core was using netstandard, but broke when WCF Core changed to netcoreapp.

Configuration

.NET 5.0.9
Microsoft.XmlSerializer.Generator 5.0.0
WCF Core 3.2.1
OS/architecture agnostic

Regression?

Yes, worked with older WCF Core releases targeting netstandard.

Other information

I was able make it work by changing the regular expression in the tool to allow the new netcoreapp and net targets too:

string pattern = "\\\\ref\\\\(netstandard|netcoreapp|net)\\d*\\.?\\d*\\.?\\d*\\\\System.ServiceModel.Primitives.dll";

@mconnew recommended a workaround in #1390 (comment) to separate data classes into a dedicated library project that probably could help with this bug too.

Was great if a more generic solution could be found to either load the lib versions automatically or to make the tool work with the ref versions, potentially by loading those into a reflection-only context.

[mconnew]

There's currently work being done to switch to using MetadataLoadContext. Part of the problem is the changes aren't just in the Generator tool, we need changes in some runtime implementation in .NET Core as the Generator passes MemberInfo objects runtime methods which then reflect over it using GetCustomAttributes. This doesn't work with either a reflection based load context or the MetadataLoadContext as it requires instantiation of the attribute instance. So we're working through finding all the code paths and converting them to use GetCustomAttributesData instead. I know this must be frustrating waiting all this time, but it is in progress.

[kornelpal]

I was able to work around the issue by adding the following to the MSBuild (.csproj) file that is referencing the tool:

<PropertyGroup>
  <SGenReferences>$([System.Text.RegularExpressions.Regex]::Replace(@(ReferencePath), `(?'pre'[\\/])ref(?'post'[\\/](netstandard|netcoreapp|net)\d+(\.\d+)*[\\/])`, `${pre}lib${post}`))</SGenReferences>
</PropertyGroup>