Does illink walk through resource files?

[kant2002]

I have this warning in WinForms

winforms\src\System.Windows.Forms\src\System\Resources\ResXDataNode.cs(129,28): error IL2077: 'name' argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicParameterlessConstructor
' in call to 'System.ComponentModel.Design.ITypeResolutionService.GetType(String, Boolean, Boolean)'. The field 'System.Resources.DataNodeInfo.TypeName' does not have matching annotations. The source value mu
st declare at least the same requirements as those declared on the target location it is assigned to.

This is indication that Type name stored in resource file require PublicParameterlessConstructor to be useful. I have dilemma, either I annotate that code as unprovable and apply RUC on the method. Or if illink can look at aseembly resources and read type name and keep public parameterless constructors to that type, that maybe useful.

[vitek-karas]

Trimmer doesn't see into resources. It sees them as binary blobs. I know that one way .NET can use to store "objects" in resources is binary serializer, which has lot of problems with trimming - not counting that it's obsolete. I don't know what WinForms uses in
this case though.

We intentionally didn't put much effort into this, since there are basically endless possibilities of which format the resource blob could use to serialize stuff.

[vitek-karas]

Also - design-time stuff should probably not care about trimming - as in, I can't see how we would get into a situation where design-time stuff runs against trimmed app. I vaguely remember that we thought about this in component model, but I don't remember the details. Maybe @eerhardt remembers?

[eerhardt]

See #1878 for why this and other APIs in ComponentModel were annotated with PublicParameterlessConstructor.

In general, I just annotated the code in the assembly so the trimmer wouldn't warn. I didn't give consideration to "Design" or "runtime" code - it is code that is available to call, so it is annotated as best as it can be.

[kant2002]

Essentially I should assume that any typename from resources maybe not preserved, and I have to annotate this code with RUC. Correct?

[eerhardt]

Yes, unless you can prove some other way that the Type will be preserved. Reading a type name from a file (like a resources file) and trying to find it isn't guaranteed to work.

[kant2002]

That's fine. Given that .resx/.resources approach does not have love, that's all I can do. Just want to clarify, since whole trimming has a lot of details, and I do not want mark whole WinForms with RUC 😄

[vitek-karas]

I do not want mark whole WinForms with RUC

That would definitely be bad. I would be curious how widespread this is in WinForms (resource loading that is). For example, maybe we should consider a feature switch in this case - just like we've done for generic resource reading in BCL. I guess what I'm saying is that RUC is not the only solution :-).

[eerhardt]

If you know all the types, you can add DynamicDependency attributes to the code to preserve the types.

another approach is a linker extension that reads the resource files and marks the types. Maui uses those a decent amount.

Yet another approach would be a code generator that generated a “factory” method to create all the types. The linker would see the type used in code and not trim the type.

[vitek-karas]

Personally I would vote for source generator... linker extensions are problematic and we should get rid of them over time if at all possible.

[kant2002]

code generator for ResX files possible out of scope, since that's require somehow teach designer and CodeDom source generator to use that source generat.. I would agree that's easiest way in technical term, but let's see what perspective @RussKie can bring to the table, and who else he can summon to discuss things.

[MichalStrehovsky]

Given this is a BinaryFormatter scenario, I think some work will have to be done around it either way. Based on the old obsoletion plan, this was supposed to happen in .NET 7 for WinForms. I don't know where those plans stand now.

https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/binaryformatter-obsoletion.md#net-7-nov-2022

[kant2002]

There no better plans then dotnet/winforms#6267 .

[agocke]

Closing as no longer relevant. BinaryFormatter is still a problem and will need a solution outside the linker.