Hard to simulate target frameworks with the ReferenceAssemblies type

[jaredpar]

I have some cases in the C# compiler where I have a set of DLLs that I want to use as ReferenceAssemblies. Yet I can find no reasonable way of doing this unless I first format them on disk as a NuPkg file. That seems very counterintuitive to me. Effectively most calls in ReferenceAssemblies come down to ResolveAsync which returns a collection of MetadataReference objects. Yet if I start with a collection of MetadataReference I can't find a way to reasonable create a ReferenceAssemblies object.

This is making it hard to adapt some of our tests where we often need to simulate target framework assembly sets that translate up to the IDE layer.

Am I missing an easy way to make this happen? I'm willing to do the translation from in memory MetadataReference to a set pattern on disk if that's the only way. It seems quite wasteful though. It's effectively round tripping from memory, to disk only to put the exact same objects back in memory again.

[jmarolf]

We could add an API that is essentially "I know what I am doing let me construct my own compilation". In general the ReferenceAssemblies API was where so users wouldn't need to get this right. They can just say "give me the .NET 6 reference assemblies" and move on.

This is making it hard to adapt some of our tests where we often need to simulate target framework assembly sets that translate up to the IDE layer.

Is this set arbitrary or is it intended to represent a shipped set of assemblies (such as Portable7) that we have no API for today?

[jaredpar]

They can just say "give me the .NET 6 reference assemblies" and move on.

They can only do this though if they have those restored on disk. That is awkward for certain of the ref assembly sets. Most notably:

1. netstandard2.0 it can be awkward to use this unless you're actually targeting netstandard2.0 because it can alter your build artifacts
2. netstandard1.3 there is no good definition of what all packages make up this target framework
3. Microsoft.NetCore.App.Ref can interfere with SDK targets where the version is considered

Is this set arbitrary or is it intended to represent a shipped set of assemblies (such as Portable7) that we have no API for today?

The initial problem we hit is trying to move some tests to target net60 preview 7. That is the first set of reference assemblies that have a corelib which contains the feature flag for abstract static in interface.

I filed this bug both for that but also because it feels very odd that I couldn't solve this problem. After all I have all of the MetadataReference for net6.0 in hand, why can't I create a ReferenceAssemblies instance that uses it? Ideally one that doesn't require round tripping to disk.

[sharwell]

@jaredpar The ReferenceAssemblies type is designed for use with reference assemblies from NuGet. If you want to provide your own assemblies, you can:

1. Pass in an empty ReferenceAssemblies instance that establishes the target framework, e.g. new ReferenceAssemblies("custom0.1")
2. Provide the full set of compiler assemblies to TestState.AdditionalReferences