-
Notifications
You must be signed in to change notification settings - Fork 549
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
Lambda variable identifier treated as an unknown identifier #606
Comments
Root cause has been identified: I have a (very) complex object called ClaimDto, which has its own implementations. One child object is the ClaimLine, as referenced above:
It turns out that the I uncovered this when screwing around with the expression:
I also tried by renaming my interface's I suppose my immediate solution would be to cast my |
The reason that Solution A (source of the expression, with tests) worked was because Solution A only had references to the interface and used mock objects to test expressions in RulesEngine locally. Solution B consuming the expressions have the complicated object model, which has conflicting types between the interface's |
I've got a resolution for my solution: I need to do the following for single-instance objects:
and for lists:
I would raise that a suggested feature request would be to specify the type to evaluate a given object as for an additional It looks like there is such a constructor on
|
i made some changes to my fork which may affect this question |
@BardezAnAvatar, I'm having the same issue. I didn't quite get what you eventually did to resolve it. Thank you! |
I had to use the casting syntax for DynamicLINQ, to ensure that the objects are evaluated explicitly as interfaces and not the objects that tbey are. So, by casting to an interface, they use the interface properties, not the class properties. |
Where does this casting happen? Do you do it directly in this LINQ expression |
You use the |
this fork is no longer maintained, please move your issue to a fork that is maintained |
I've an interesting scenario that is driving me nuts:
I have a model that I am registering to RulesEngine via parameter (
line
) that consists of:IReadOnlyList<string> Modifiers { get; }
Any expression that accesses this (in a .NET 6 project/solution) is encountering the following:
Oddly, in a separate solution that generates this expression, I am able to load the above without issue in my integration test project. Taking the same expression over to my other solution, however, yields the above exception when running RulesEngine. Both solutions use the exact same NuGet version of RulesEngine (5.0.3), using the same Workflow serialization/deserialization.
With tinkering, it seems that the specific reference of
l
that is a problem is on the left-hand side of the lambda, not the.Contains(l)
statement.The text was updated successfully, but these errors were encountered: