The remaining trimmer warnings are around usage of System.Reflection such as:
Create an Invoker type from an original type via Type.Assembly.GetType()
Create a Type based on a ParameterInfo.ParameterType and/or create instances
Use Type.MakeGenericType()
Use Type.MakeArrayType()
The trimming warnings themselves all indicate that these types "might be trimmed", in that nothing explicitly preserves them. However, we have a plethora of custom trimmer steps that work to preserve these types involved in Java interop, such as:
One day, in a perfect world, we could remove these trimmer steps and completely rely on the trimmer's warnings & attributing mechanisms. That day doesn't have to be today -- as our goal is begin surfacing trimmer warnings to users in their own code and dependencies.
With these warnings ignored, we can fully enable analyzers with:
As the MSBuild property does this for us, in addition to enabling analyzers.
I don't think we should enable $(IsAotCompatible) quite yet, as Java.Interop.dll likely won't work yet on NativeAOT, and this places metadata that says an assembly is supported. We should just use the $(EnableAotAnalyzer) analyzers for now, so we don't introduce new issues.
Fixes: https://github.com/xamarin/java.interop/issues/1157
The remaining trimmer warnings are around usage of System.Reflection such as:
Create an
Invoker
type from an original type viaType.Assembly.GetType()
Create a
Type
based on aParameterInfo.ParameterType
and/or create instancesUse
Type.MakeGenericType()
Use
Type.MakeArrayType()
The trimming warnings themselves all indicate that these types "might be trimmed", in that nothing explicitly preserves them. However, we have a plethora of custom trimmer steps that work to preserve these types involved in Java interop, such as:
One day, in a perfect world, we could remove these trimmer steps and completely rely on the trimmer's warnings & attributing mechanisms. That day doesn't have to be today -- as our goal is begin surfacing trimmer warnings to users in their own code and dependencies.
With these warnings ignored, we can fully enable analyzers with:
We can then remove:
As the MSBuild property does this for us, in addition to enabling analyzers.
I don't think we should enable
$(IsAotCompatible)
quite yet, asJava.Interop.dll
likely won't work yet on NativeAOT, and this places metadata that says an assembly is supported. We should just use the$(EnableAotAnalyzer)
analyzers for now, so we don't introduce new issues.