Various trimming warnings in DotNext.Metaprogramming #217
Comments
|
Hi @alexrp , |
|
Is there any reason in principle why it couldn't work? Obviously there would be some responsibility on my own part to root some |
|
Almost every method in the library should be marked with |
|
Hmm, I don't quite follow. Wouldn't you just need to annotate the API surface of the library with I think So, in other words, I think there is value in DotNext.Metaprogramming adding these annotations because they would help the trimmer's analysis. But also, adding Does this make sense? |
Because it doesn't work in general. For instance, [DynamicDependency(DynamicallyAccessedMemberTypes.PublicMethods, typeof(Task<>))]This is a valid declaration of open type in C#, however I'm 95% sure that IL trimmer doesn't understand that. I mean it doesn't understand that it need to keep all public methods for any instantiation of type |
|
It seems there was some work done recently related to open generics: dotnet/runtime#96648 That said, I don't actually know if this at all addresses your specific example of preserving In the worst case, I think DotNext.Metaprogramming could embed a root descriptor file that preserve By the way, the log in the original issue is with I wonder why |
It's done for There are lot of complex cases not covered with attributes. For instance, |
I suppose applying dependency attributes to the
I am not actually opposed to doing this, by the way. The fundamental problem here is that, even if I do this, I am still left with all these trim analysis warnings coming from DotNext.Metaprogramming. AFAIK, the only way I can silence them is by suppressing all trimmer warnings, even from my own assemblies and other third-party dependencies, which is not good. 🙁 |
No. It works with |
|
Ok, I see what you mean. Thinking a bit more about it, I can't think of a good solution there either. What do you think about best-effort annotations? I.e.:
It seems like this would bring the best user experience here. Depending on APIs used, there would still be some work for the user to do to preserve reflected-upon types/members, but at least there would no longer be any unactionable/unsuppressible trim analysis warnings. The warnings that would be there for |
I tried this approach several times and it requires a lot of work to analyze each case accurately. Sad to hear that |
If I can find the time to go through the library and do this, would you take a PR for it? No promises that I can get the approach to work either, but I can at least try.
Yeah, I initially thought that this mode was what I wanted for dependencies like this that aren't marked trimmable. But then you just get unsuppressible analysis warnings as shown here. It seems that, either way, there's just no winning unless you annotate the library. It's honestly a pretty annoying design on the part of the trimming infrastructure. |
I'll submit initial PR so you can be a co-author to continue this work. Anyway, this library probably will never be AOT compatible. |
That's fine. I wouldn't even try to use S.L.E with AOT; that seems like a recipe for a bad time. I'm just hoping we can get basic trimming somewhat working (even if it still requires some effort from the user side) so I can reduce the size of my published (JIT) app. |
|
Done, draft PR is opened (see above). |
I just tried turning on trimming for my app, and noticed some warnings coming from DotNext.Metaprogramming:
At first glance, it seems like most of these can be fixed by plumbing the right attributes through.
The text was updated successfully, but these errors were encountered: