-
Notifications
You must be signed in to change notification settings - Fork 223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Test] Enable trimming and AOT analysis for the whole project. #830
base: master
Are you sure you want to change the base?
Conversation
@Numpsy let me have a look at these exceptions here, pretty sure it comes from code I wrote a while ago |
I came to the same conclusion. Don't think it can actually be fixed. I think something we could think about is to create a separate NuGet package for the classes in @EliotJones what do you think? |
Is it possible to use a preprocessor directive to remove these classes when targetting AOT builds? Not really familiar with AOT stuff. |
ew might be able to create our own |
I'd also be fine removing these from the main code base and creating/managing a |
I'm unclear if it's possible to avoid any of the issues by using A consuming application might then be able to avoid some issues by configuring its trimming settings to ensure that anything that it's actually using is always kept. |
I think the RequiresUnreferencedCode is the most sensible. We are passing the warning from the xml lib to the consuming app. Makes sense to me |
Sounds good to me, presumably the consumer only gets warnings if actually using annotated methods/members? |
Yes this is how I understand it too. It's up to the consumer to make sure everything okay with AOT. We can have a 2nd look once people start using exporters in AOT |
That's the idea. (e.g. I didn't see these warnings when I created #664 as I wasn't calling the functions from my app) |
Enable both trimming and AOT analysis for the whole solution, to see if it finds any more possible issues on top of the ReflectionStateGraphicsFactory situaiton.
Running it locally, I get this set of additional warnings:
I'm not sure If those can all be fixed inside the library, or if it might need the functions to be attributed so that the issues get reported to external callers (I haven't looked at it in any more details than this)