Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RulesEngine - Guid ToString not passing rule #653

Closed
sianmace opened this issue Feb 3, 2025 · 2 comments
Closed

RulesEngine - Guid ToString not passing rule #653

sianmace opened this issue Feb 3, 2025 · 2 comments

Comments

@sianmace
Copy link

sianmace commented Feb 3, 2025

I have been using RulesEngine for some time and now have some failing tests when upgrading to v5.0.5

I have replicated the issue in .net Fiddle for both
v5.0.0 - No issue - rule passes - https://dotnetfiddle.net/G0TEtu
and v5.0.5 - Rule does not pass - https://dotnetfiddle.net/ey6kLE

This is a crude simplification of the rule im using in my own tests, just to prove the issue.

The parameters i pass in - one is an object with a collection of guids
the other parameter is a list of strings to match to.

It seems that a == i.ToString() is not returning true
but as you can see in the code, if i execute the same thing as code, it does.

Like i say, this is an introduced change as was working previously as demonstrated in the examples above

Any ideas?

@pbhal
Copy link
Contributor

pbhal commented Feb 24, 2025

@sianmace - Reviewed the bug and we are working on a fix for this.

@pbhal
Copy link
Contributor

pbhal commented Feb 24, 2025

@sianmace - The issue occurs due to the breaking change introduced in the new versions of System.linq.dynamic.core where the members are not accessibly on non-primitive types.

Reference: zzzprojects/System.Linq.Dynamic.Core#410

One possible solution is to add the custom types in ReSettings and turning off UseFastExpressionCompiler (as fastexpressioncompiler is causing runtime errors)

Link to .NET fiddle where the evaluation is true - https://dotnetfiddle.net/IQQEVG

We will look at if it makes sense to include custom type handler within the library itself for cases like these.

@pbhal pbhal closed this as completed Mar 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants