Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Support ContainsKey (as an analyzer is telling us to use it)
See original GitHub issueWhat problem are you trying to solve?
After recently upgrading to .NET 6, there’s a new analyzer prompting you to convert dict.Keys.Contains("foo") to dict.ContainsKey("foo"), but that’s not supported by EF Core, so a quick refactor can have nasty consequences.
Describe the solution you’d like
Can dict.ContainsKey be supported?
I could probably help out with some direction.
(didn’t see any previous issues actually ask for this, sorry if it’s been previously rejected)
Issue Analytics
- State:
- Created 2 years ago
- Reactions:3
- Comments:8 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Triage decision: translating ContainsKey as above is something that is hard for EF Core to support in an efficient way. We will consider adding a diagnostics suppressor to suppress this warning when it appears inside an EF Core LINQ query (best effort). This would depend on having infrastructure for identifying EF Core LINQ queries at compile-time, which we don’t currently have.
The issue seems to be pretty old but I’ve stumbled upon this just today as well. I’d have expected
dictionary.ContainsKey(x)to be internally handled the same asdictionary.Keys.Contains(x). If this is not possible to do in an efficient way,CA1841should take it into account when inside EF LINQ query.