[DO NOT MERGE]: IKeyValueCollection as IReadOnlyList

[kronic]

Implement IKeyValueCollection as IReadOnlyList

[dwcullop]

Please add some description to your PR (describe what you are changing and why). It doesn't have to be long, but it is for posterity.

[JakenVeina]

Looks like the build failures are complaining about calling LINQ methods on objects that now support direct calls (E.G. .Count() versus .Count), and only in Tests code. Another case of the analyzers being overly-aggressive, probably, but should be an easy fix. Do those errors not show up on your end?

[dwcullop]

Looks like the build failures are complaining about calling LINQ methods on objects that now support direct calls (E.G. .Count() versus .Count), and only in Tests code. Another case of the analyzers being overly-aggressive, probably, but should be an easy fix. Do those errors not show up on your end?

I'm guessing he might not if he's using ReSharper and not VS. The build failures on the server can show what changes need to be made.

[glennawatson]

Rider will have the same build errors as VS. The analysers work on both. Use rider all the time.

[kronic]

@dwcullop @glennawatson @JakenVeina ready for review

[JakenVeina]

Still need to drop the two members on IKeyValueCollection instead of having them shadow the inherited ones.

There's also now a test failure happening, coming from the fact that you changed a public API within the library. The way this works is that the test runs code from the third-party library PublicAPIGenerator, which reflects upon the entire library and dumps a reproducible text version of every publicly-accessible type and member it finds into a text file. Then we call on the XUnit.Verify package to compare that file against the last-known-good file embedded within the project. If they're different at all, the test fails, and what SHOULD happen is that you should get prompted with a side-by-side diff of these files, for you accept changes into the last-known-good file. This last bit is very environment-dependent. For me on Windows, for example, it launches WinMerge with the two files.

If you're not getting any prompt to compare the diffs and accept them as changes to the API file, you can just edit the file directly. The file can be found at \src\DynamicData.Tests\API\ApiApprovalTests.DynamicDataTests.DotNet8_0.verified.txt, and the generated file to compare against should be right next to it, it's just not checked into the repository.

This is all an extra bit of clerical work that helps everyone make sure there aware of when breaking changes are occurring. In this case, we already have breaking changes merged into main, so the next release will have to be a new major version, so pulling this shouldn't be an issue, especially since it's only binary-breaking, not compile-breaking. @RolandPheasant agree?

If you'd rather one of us make the rest of the changes, I'd be completely fine with that. I'm not sure if the branch has been setup to receive commits from upstream maintainers.

[kronic]

@JakenVeina done

[RolandPheasant]

@JakenVeina let's hold back a couple weeks on merging this, so we can apply other breaking changes as part of a big version release.

[kronic]

@RolandPheasant ping