Compiler Trim Warnings

[Bowman74]

@rockfordlhotka

Currently we have suppressed many of the trim warnings in CSLA. The following are suppressed:
IL2026 IL2055 IL2057 IL2060 IL2070 IL2072 IL2075 IL21111 IL3050

I looked into what it would take to resolved them. Many of them cannot be fixed without re-thinking interfaces like IDataPortalServer's Update method's obj parameter. Right now the parameter is System.object, something outside of our control.

The problem is in DataPortal.cs (Csla.Server.DataPortal) that implements IDataPortalServer. It the implementation of the Update method it calls into Csla.Reflection.ServiceProviderMethodCaller.FindDataPortalMethod passing in an object Type to the targettype parameter. That parameter in the FindDataPortalMethod method is decorated with:

[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors)]

Wherever that type comes from also has to be decorated. If we look back at the Update method we find this line where the type is gotten:

objectType = obj.GetType();

OK, so in order to clear this warning we need to make sure that obj, whatever it is, is similarly decorated. So we look back and find that obj is the Update method's parameter of type System.object. We can't decorate that.

Three ways to fix come to mind. All three of these require IBusinessObject and all derived types to be annotated with the DynamicallyAccessedMembers if on .Net 8+. This will require user code for business objects to also have annotations if they don't want the same warnings, which makes that they would have to tell the compiler not to get rid of all those apparently dead wood data portal methods.

Here are my ideas on ways to fix:

• (Probably not) Change the parameter type of the IDataPortalServer's Update method to IBusinessObject from System.Object. Breaking change for anyone who created a custom implementation of any of these interfaces, ugh...
• (Breaking update for .Net version 8+ only, worse for maintenance) Change the IDataPortalServer's interface to use IBusinessObject on .Net 8+, all lower versions still use System.Object. More backward compatible, only causes a potential issue when revving .Net version to 8+. Ugly code with lots more #ifs.
• Leave the IDataPortalServer interface alone so parameter is still System.Object. In the Update method if .Net 8+ we check to see if the obj parameter is castable to IBusinessObject. It not we throw some sort of invalid parameter exception. If it is of type IBusinessObject we cast it to that type and call GetType on that, clearing the warning.

There are other possible solutions like using [DynamicDependency]. Microsoft does not recommend this but it is a possibility.

https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/prepare-libraries-for-trimming

[rockfordlhotka]

I've created an issue based on this discussion, because at least some part of this has to happen in v9.0 because it will be a breaking change.

#4425

[StefanOssendorf]

Or we postpone it until V10 - we are not bound to the .net release cycle ;)

[rockfordlhotka]

Or we postpone it until V10 - we are not bound to the .net release cycle ;)

True, though to me what we're discussing here (ICslaObject plus data portal interface changes) is actually not that big a deal for 99.999% of users, and so I'd rather do it now if it will allow us to move forward.