roslyn-sdk
roslyn-sdk copied to clipboard
Hard to simulate target frameworks with the ReferenceAssemblies type
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.
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?
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:
-
netstandard2.0
it can be awkward to use this unless you're actually targetingnetstandard2.0
because it can alter your build artifacts -
netstandard1.3
there is no good definition of what all packages make up this target framework -
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.
@jaredpar The ReferenceAssemblies
type is designed for use with reference assemblies from NuGet. If you want to provide your own assemblies, you can:
- Pass in an empty
ReferenceAssemblies
instance that establishes the target framework, e.g.new ReferenceAssemblies("custom0.1")
- Provide the full set of compiler assemblies to
TestState.AdditionalReferences