ILLink rooting assemblies with forwarded types

[kotlarmilos]

Description

Rooting input assemblies is not enough when trimming with ILLinker forwarded types. It is required to root all forwarded assemblies as well.

Test case:

[Theory]
[InlineData("mscorlib")]
[InlineData("System.Threading.Overlapped")]
public static void ShimsHaveOnlyTypeForwards(string assemblyName)
{
    Assembly assembly = Assembly.Load(assemblyName);

    Assert.Empty(assembly.GetTypes());
    Assert.Empty(assembly.GetManifestResourceNames());
    Assert.NotEmpty(assembly.GetForwardedTypes());
}

[vitek-karas]

The product behavior is by design here - I think the test case in question just needs special consideration if running as "Trimmed" - or maybe we should just disable it. The things it's doing are specifically against what trimming/AOT supports, so not supporting this test case in that setup seems OK to me.

[filipnavara]

I had problem with this behavior in production so maybe there should be some additional consideration on how to handle this. My scenario involved System.Windows.Forms / System.Drawing and the type forwarders there. There are serialized resources that depend on the forwarders being kept after trimming (eg. resource references System.Windows.Forms.Padding and the real type is System.Windows.Forms.Primitives.Padding). I realize that this is currently an unsupported scenario, but I still think that some consideration should be given to it and how to handle it (eg. optional switch to keep the type forwarders in specific assembly).

[kotlarmilos]

I think the test case in question just needs special consideration if running as "Trimmed" - or maybe we should just disable it.

We can skip the test if trimming is enabled.

My scenario involved System.Windows.Forms / System.Drawing and the type forwarders there. There are serialized resources that depend on the forwarders being kept after trimming (eg. resource references System.Windows.Forms.Padding and the real type is System.Windows.Forms.Primitives.Padding). I realize that this is currently an unsupported scenario, but I still think that some consideration should be given to it and how to handle it (eg. optional switch to keep the type forwarders in specific assembly).

I agree that adding an ILLInk warning message or an optional switch could be beneficial. Currently, it may be unclear to customers what has happened and how to resolve the issue.