MudBlazor: `GetLabelString` does not satisfy 'DynamicallyAccessedMemberTypes.PublicProperties'

Yes sorry to be so pedantic about it but I really wanted to push the point that just using a type in user code should not be relied upon. Its good to talk to people who have knowledge of this. Theres not a lot of information around. I thought the issue with MS was very informative. I would just like to try to do the “right” solution now even if it works as is now. We have breathing space for this anyway since the type of change they are suggesting would probably be aligned with a new major version. Even then I will presume the new level of trimming will be configurable so it may just be in net8 we set the trimming mode to what net7 was.

I can certainly understand how it would not be easy to annotate Member.Type because it would depend on what you were using Type for. I am not even sure the linker understands how to descend inside the expression anyway.

I think AOT for the whole UI framework is overkill particularly as you then pay a significant cost on size and probably we don’t need the extra speed. However who knows what the future of Blazor will be. Maybe it will all be compiled to native wasm at some stage.

I don’t think we are far off in the library (DataGrid aside). There are however some suppressions that assume instantiating means types and properties can be reflected upon that may need to be revisited.

You will notice that all the PRs I did were all annotating DAM which sometimes is a bit more thinking but gives the best solution now and in the future.

I also noted that the analyser did not pick up https://github.com/MudBlazor/MudBlazor/pull/5711 Thank you for trimming the Docs as that picked it up fairly quickly.

DataGrid is a problem however. It is very loose with its configuration often using strings and reflection where I am sure there are better type safe solutions.

You could convert DataGrid to a non trimmable extension maintained by the author since any changes that make it more trim friendly are likely to be breaking.

That would mean writing a new grid though which is too much work for most people. Or we could partially redesign the column bindings so they were trim friendly. I particularly like QuickGrid by Steve Sanderson as a starting point.

I have still not given up on the Validation and Label problem We still haven’t explored a code generator solution.

Another idea I am exploring

Expression<Func<TModel [DymanicallyAccesedMembers(DynamicallyAccessedMemberTypes.PublicProperties) ,T>> expression

With the configuration

For= "model => model.SomeProp"

and doing typeof(TModel) or something probably its a dead end I havent really started yet

Thanks for listening 😃

I did small tests, and this code is safe the way we use it. The custom attribute doesn’t get trimmed unless the property is trimmed. The property won’t be trimmed if it’s used like we do

For="@(() => model.Name)"

The warring happens because the Expression.Type(https://github.com/dotnet/runtime/blob/215b39abf947da7a40b0cb137eab4bceb24ad3e3/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/Expression.cs#L97) missing the annotation. There is nothing we can do. But the underlying type of model will not be trimmed because we are using it. Just ignore by now.

UPD: vitek-karas gave more detailed explanation on why it cannot be annotated for Expression.

Question asked on StackOverflow