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

Binder throw ambiguous match exception for object with read only indexer property that has two implementations in base class #502

Open
AlesDo opened this issue Sep 28, 2023 · 2 comments
Labels

Comments

@AlesDo
Copy link

AlesDo commented Sep 28, 2023

Version Information

Software Version(s)
Bogus NuGet Package 34.0.2
.NET Core? 7.0.11
.NET Full Framework?
Windows OS? 11 Pro 22621.2283
Linux OS?
Visual Studio? 17.8.0 Preview 2.0

What locale are you using with Bogus?

en

What is the expected behavior?

Should not throw exception when enumerating properties.

What is the actual behavior?

System.Reflection.AmbiguousMatchException is thrown

Please provide a stack trace.

at System.RuntimeType.GetPropertyImpl(String name, BindingFlags bindingAttr, Binder binder, Type returnType, Type[] types, ParameterModifier[] modifiers)

Any possible solutions?

Yes it is possible to ignore the indexer properties where the check for parent class properties is performed.
Have created a branch in my fork with a unit test and a possible solution.

How do you reproduce the issue?

By using fluent syntax with an object that has two read only indexers that are defined in a base class.
Have created a branch in my fork with a unit test and a possible solution.

Do you have a unit test that can demonstrate the bug?

Yes.
Have created a branch in my fork with a unit test and a possible solution.

Can you identify the location in Bogus' source code where the problem exists?

Yes.
Binder.cs line 114. Because both indexers have same default name Item resolving PropertyInfo by name fails.

If the bug is confirmed, would you be willing to submit a PR?

Yes.

@bchavez bchavez added the bug label Oct 8, 2023
@addixon-cnhi
Copy link

I've run into this bug just this week and am curious if there's intent on a fix in an upcoming release? I can work around by adding a protected set; to the property, but would love to not have to do this as it reduces the integrity of the instantiated class.

@bchavez
Copy link
Owner

bchavez commented Apr 16, 2024

@addixon-cnhi I haven't dived into this particular issue yet, but I suspect one workaround might be to create your own Binder:

The Binder is responsible for reflecting over / introspection of T in Faker<T> to determine what properties/fields are available on T. Also, the original post has a branch with some of the changes that seem to have worked around the original issue.

You can supply your custom Binder here in new Faker<T>(binder: MyCustomBinder):

Let me know if that helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants