RadzenDataGrid filter on date crashes back-end

I am using the DataGrid with back-end loading of data. The Radzen client is a standalone web assembly with a API-based backend. When passing a filter on a date, the back-end crashes with a rather cryptic message about CultureInfo not being recognized. I added specific types to the dynamic linq in the back-end to solve this. This did make the error disappear but I got another one.

When I examine what the filter looks like, it’s even quite unexpected:

x => ((x.Startdate ?? null) == DateTime.SpecifyKind(DateTime.Parse("2026-01-01", CultureInfo.InvariantCulture, DateTimeStyles.RoundtripKind), DateTimeKind.Unspecified))

It looks as if the statement to parse the date is not executed on the client, but sent to the server, and that the server (for some reason) is unable to correctly interpret it.

With this statement, the back-end code reports: Operator '==' incompatible with operand types 'Object' and 'DateTime''.

This behavior was introduced somewhere in the past 3-4 weeks (Radzen 10.0.? – 10.0.6) (before that, it all worked fine)

Note that on the Radzen demo site, no issue is seen, and the filter statement looks like nothing as what I am seeing (rather a classical compare statement (propertyy) eq (value) - what I expected).

Can anyone point me to what can cause this behaviour?

The property filtered on is a DateTime or a DateTime? (neither works).

Thanks!

It seems that the code for the selector in the where clause that is generated by radzen is not compatible with the system dynamic linq library I use in the backend. The back end has no knowledge of radzen, and as such I did not find any code in the radzen repository that might work with this filter clause. Suggestions are appreciated.

Since v6.0 we abandoned support for Dynamic LINQ library due to vulnerability issues and we’ve added our own parser that supports pure string to C# unlike Dynamic LINQ where the syntax was custom. There are replacements extension methods in the same namespace and you can use them instead.