New Analyzer to avoid StringComparison

[EdLichtman]

When using DbSet.Where(x => x.Equals(y)), then the dotnet recommended rules give a warning that you should have the code implement a String Case Comparison, such as: DbSet.Where(x => x.Equals(y, StringComparison.OrdinalIgnoreCase))

When you TreatWarningsAsErrors, like my company, you're left with disabling the pragma, or, using the == comparator.

However, our company has historically required you compare strings with .Equals, instead of == based on our coding conventions.

The problem is, if we're comparing 2 values that are strings, we shouldn't find out at runtime that a problem occurs if we include OrdinalIgnoreCase. It would be far better to find out at development time.

I'd like to see an analyzer that requires that you use == instead of .Equals if your delegate within the Linq statement compares string values. Or, if it's possible to counteract CA1309, then a rule that counteracts it if you're within that statement.

[roji]

@EdLichtman there are several things that make this more complex than it seems.

First, from a feasibility/implementation point of view, the analyzer would need to identify string Equals specifically within EF LINQ queries (as opposed to other LINQ queries, e.g. regular LINQ-to-object or possibly even other non-EF queryable providers). This isn't an easy thing to do (at least, not efficiently), and we don't currently have that capability. See "Scenarios requiring identifying EF Core LINQ queries" in #22086.

But more importantly, the requirement to not use Equals isn't universal by any means, even within EF. First, some databases are case-insensitive by default (e.g. SQL Server), while others are case-sensitive (e.g. PostgreSQL, SQLite). An analyzer therefore can't propose that you replace Equals(x, StringComparison.OrdinalIgnoreCase) with equality, since that would could change the meaning of the query, depending on your database. And making the analyzer aware of the database being targeted is even a more difficult problem (not to mention that the same code could be used against multiple providers).

In fact, the Cosmos EF provider actually does support StringComparison.OrdinalIgnoreCase, since that makes sense on that particular database (it does not for relational databases, where column collations are usually the right way to manage case sensitivity, see docs).

The problem is, if we're comparing 2 values that are strings, we shouldn't find out at runtime that a problem occurs if we include OrdinalIgnoreCase. It would be far better to find out at development time.

I agree that ideally you get analyzers identifying all problems for you - but that's unfortunately not always feasible. Doing proper testing can ensure that such runtime errors are located very early as well.

[ajcvickers]

Note from triage: this is not something we plan to support.