Replies: 1 comment 2 replies
|
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. |
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
@rockfordlhotka
Currently we have suppressed many of the trim warnings in CSLA. The following are suppressed:
IL2026 IL2055 IL2057 IL2060 IL2070 IL2072 IL2075 IL21111 IL3050I looked into what it would take to resolved them. Many of them cannot be fixed without re-thinking interfaces like
IDataPortalServer'sUpdatemethod's obj parameter. Right now the parameter isSystem.object, something outside of our control.The problem is in DataPortal.cs (Csla.Server.DataPortal) that implements
IDataPortalServer. It the implementation of theUpdatemethod it calls intoCsla.Reflection.ServiceProviderMethodCaller.FindDataPortalMethodpassing in an objectTypeto the targettype parameter. That parameter in theFindDataPortalMethodmethod 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
Updatemethod's parameter of typeSystem.object. We can't decorate that.Three ways to fix come to mind. All three of these require
IBusinessObjectand all derived types to be annotated with theDynamicallyAccessedMembersif 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:
IDataPortalServer'sUpdate method toIBusinessObjectfromSystem.Object. Breaking change for anyone who created a custom implementation of any of these interfaces, ugh...IDataPortalServer's interface to useIBusinessObjecton .Net 8+, all lower versions still useSystem.Object. More backward compatible, only causes a potential issue when revving .Net version to 8+. Ugly code with lots more #ifs.IDataPortalServerinterface alone so parameter is stillSystem.Object. In the Update method if .Net 8+ we check to see if the obj parameter is castable toIBusinessObject. It not we throw some sort of invalid parameter exception. If it is of typeIBusinessObjectwe cast it to that type and callGetTypeon 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
All reactions