[Test] Enable trimming and AOT analysis for the whole project.

[Numpsy]

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)

[BobLd]

@Numpsy let me have a look at these exceptions here, pretty sure it comes from code I wrote a while ago

[BobLd]

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 UglyToad.PdfPig.DocumentLayoutAnalysis.Export...

@EliotJones what do you think?

[EliotJones]

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 UglyToad.PdfPig.DocumentLayoutAnalysis.Export...

@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.

[BobLd]

ew might be able to create our own #if AOT... haven't looked into that though

[BobLd]

I'd also be fine removing these from the main code base and creating/managing a UglyToad.PdfPig.DocumentLayoutAnalysis.Export NuGet package

[Numpsy]

I'm unclear if it's possible to avoid any of the issues by using DynamicallyAccessedMembersAttribute inside the library, but otherwise it's possible to annotate public methods with RequiresUnreferencedCode such that anyone calling the functions AND doing Trimming or AOT will get a warning themselves, e.g.

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.

[BobLd]

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

[EliotJones]

Sounds good to me, presumably the consumer only gets warnings if actually using annotated methods/members?

[BobLd]

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

[Numpsy]

Sounds good to me, presumably the consumer only gets warnings if actually using annotated methods/members?

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)