-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Make MonoGame trimming/AOT compatible as-is #8104
Comments
One of the warnings we should fix (this one is from DesktopGL builds):
Pushed a fix for this one #8105. It was making macOS builds to crash with AOT compilation. |
I was looking at this, in particular something a la this . That approach may not be scalable and may be error prone (better approach is to add the correct attribute at the class-level). Is this along the lines of what you are thinking? |
That approach used to work with old .NET <= 4.5, but modern .NET will see the trick and trim this out from the assembly. So we need to come up with something else. Related proposal #8014. Though the intended solution as per the latest .NET release is to mark types with |
There is another issue related to NativeAOT vs BRUTE that we need to fix beside trimming compatibility: #7872 |
Oh, it seems I forgot to merge the fix: #7895 |
I wonder if a long term solution is to use a source generator (simple one, not using Roslyn) that uses reflection only at compile time collecting data to be fed into the runtime code. Similar to 'protobuf-net' etc. This requires adding a MG attribute that can both help capture reflection data and help mark those classes/generics and mark them as dynamic to prevent the compiler from optimizing away these out for the linker. |
The issue is that base stuff C# types are written differently depending on if you use newer or older mgcb, because its found in different base namespaces between dotnet, .NET, .NET Framework and mono. This is written inside the content files themselves, so either a |
There are three separate problems here: one is a stable name for the classes referred to in the mgcb; another is ensuring all classes potentially used by mgcb are not optimized away during compilation; and importantly no use of reflection for NativeAot. To solve all these problems, one approach is to limit the use of reflection during compilation, use that reflection to collect stable base class names (which means respecting the current content type reader name as expected by the code linked above), stick it in a static read only list that is autogenerated and used by the runtime. E.g. static readonly Dictionary<string, CreatorFn> _mapTypenames The string->CreatorFn will allow constructing the type for the provided stable class name used by the mgcb with no reflection nor Activator.CreateInstance use and be safe for AOT. |
MonoGame has a very stable code in regard to what gets dynamically loaded from its own types or not (and otherwise has already been avoiding reflection in all the other parts of the code). These types haven't changed in years so I believe that we should be safe by just adding Other than that, we should be safe now, we already fixed the few outstanding compatibility issues. For good measure, we should enable The only problem remaining is marking those types with the attribute to be able to add If anything fails beyond that, it is likely due to user code, and not to MonoGame itself. In that regard, users will see in their build log that the trimmer raised warnings. All we can do is adding a documentation about trimming pointing to the official .NET documentation so that users know how to fix those warnings in their own code. |
It's not about what mgcb writes, the latest mgcb writes the correct types for the latest .NET, aka. If your game is compiled against mono or .NET Framework, If your game is compiled against .NET Core or .NET, These are some core .NET types we are talking about here, like |
Thanks for the discussion, sounds good! |
any possible solution for the current public release of monogame? Edit:
|
Please! This would be very useful. Also, it'd be great to have a section to explain preventive good practices for people willing to port to consoles down the road but not having development kits yet. Something along the lines of "avoid doing this and that so porting to consoles is easier", similar to what FNA does on their wiki. |
We started some documentation to help prepare for console porting: https://docs.monogame.net/articles/preparing_for_consoles.html |
Game developers are likely to be willing to produce apps using either the
PublishTrimmed
orPublishAot
build options (both being forced when building for gaming consoles). Right now, this requires projects using MonoGame to root the MonoGame assembly so that commonly dynamically loaded types (e.g. typically anything loaded with the Content Pipeline) are properly linked by adding this to their .csproj definitions:There's a couple of problems with this approach:
We should try building MonoGame with
<EnableTrimAnalyzer>true</EnableTrimAnalyzer>
, verify if any IL warnings related to trimming / AOT scenarios show up, and fix them.Once those warnings are fixed, we will be able to mark the MonoGame library as
<IsAotCompatible>true</IsAotCompatible>
(which also sets<IsTrimmable>true</IsTrimmable>
). This way users will know that MonoGame has been tailored to support trimming / AOT scenarios and won't have to add anything to their .csproj.As a side note, users willing to have their game running on consoles should also aim at fixing any warnings generated by enabling
<EnableTrimAnalyzer>true</EnableTrimAnalyzer>
because console games are built using AOT compilation (we should add this to the documentation to prepare people for building for consoles).The text was updated successfully, but these errors were encountered: