Proposal: Add Silverlight runtime detection and assembly resolution support

[SychicBoy]

I would like to propose adding first-class support for Silverlight assemblies to AsmResolver's runtime detection and assembly resolution infrastructure.

At present, DotNetRuntimeInfo can parse a target framework identifier such as Silverlight,Version=v5.0, but Silverlight is not represented as a known runtime in the same way as .NET Framework, .NET Core, or .NET Standard. As a result, the existing runtime and resolution infrastructure does not appear to distinguish Silverlight from the other supported frameworks when selecting a corlib or assembly resolver.

This can be relevant when analysing or rewriting legacy Silverlight assemblies, where framework references should be resolved against the corresponding Silverlight reference assemblies rather than a regular .NET Framework installation.

A possible initial scope would be Silverlight 4 and 5, including:

• Recognizing Silverlight as a distinct runtime in DotNetRuntimeInfo.
• Correctly detecting Silverlight assemblies from their target framework metadata.
• Selecting the appropriate corlib identity.
• Providing a way to locate and resolve Silverlight framework/reference assemblies.
• Adding tests using actual or representative Silverlight assemblies.

Before working on an implementation, I would like to ask what architecture would be preferred for this.

Would a dedicated Silverlight resolver/path provider, similar to the existing .NET Framework and .NET Core implementations, be appropriate? Alternatively, would it be preferable to extend or generalize the existing reference-framework resolution infrastructure to accommodate Silverlight?

I would be interested in implementing this if the feature is considered appropriate for the project.

[Washi1337]

In my books, more support for more frameworks is always better.

I am not too familiar with Silverlight internals, but given that it is a different framework all together (with probably its own assembly probing/resolution algorithm), it seems appropriate to indeed introduce new separate resolvers for this. That is, a new SilverlightAssemblyResolver, potentially paired with a SilverlightPathProvider somewhat akin to DotNetFxPathProvider so that we can also support Moonlight backed assemblies later for non-Windows workflows. We should also aim to extend from AssemblyResolverBase without breaking changes if possible. Otherwise, simply implementing IAssemblyResolver is fine.

Part I am unsure about is adding unit tests. Ideally, CI/CD should have silverlight/moonlight installations so that we can run them on every commit as well. I am not sure how easy it is to get silverlight in our runners. If that doesn't work, we may need to resort to SkippableFact unit tests.