Skip to main content
Jagdish Kumawat
Founder @ Dewiride
View all authors

Fixed: "error CS1593: Delegate 'RequestDelegate' does not take 2 arguments" in a Minimal API

· 5 min read
Jagdish Kumawat
Founder @ Dewiride

A small minimal API endpoint wouldn't compile: error CS1593: Delegate 'RequestDelegate' does not take 2 arguments. My lambda had two parameters, as lambdas do, so the message made no sense at first. It's about the lambda's return value: TypedResults.NotFound() and TypedResults.Ok(…) have different types, so C# can't tell what the lambda returns, and ends up trying a different MapGet overload.

Fixed: "error CS1929: 'DbSet<Category>' does not contain a definition for 'FirstOrDefaultAsync'" in .NET 10

· 5 min read
Jagdish Kumawat
Founder @ Dewiride

The build stopped with error CS1929: 'DbSet<Category>' does not contain a definition for 'FirstOrDefaultAsync' and the best extension method overload 'AsyncEnumerable.FirstOrDefaultAsync…' requires a receiver of type…. ToListAsync failed with a different message, CS0411. On .NET 10, both mean the same simple thing: the file is missing using Microsoft.EntityFrameworkCore;.

Fixed: "The query uses the 'First'/'FirstOrDefault' operator without 'OrderBy' and filter operators" in EF Core

· 6 min read
Jagdish Kumawat
Founder @ Dewiride

FirstOrDefaultAsync() returned a row, and EF Core logged a warning with it: The query uses the 'First'/'FirstOrDefault' operator without 'OrderBy' and filter operators. This may lead to unpredictable results. The word "first" needs an order to mean anything, and SQL doesn't give you one by itself. An OrderBy or a Where makes the warning go away, and the answer reliable.

Fixed: "The query uses a row limiting operator ('Skip'/'Take') without an 'OrderBy' operator" in EF Core

· 7 min read
Jagdish Kumawat
Founder @ Dewiride

My paging endpoint answered 200 OK, and the log had a warning: The query uses a row limiting operator ('Skip'/'Take') without an 'OrderBy' operator. This may lead to unpredictable results. It's right to warn. Without ORDER BY, MySQL returned the rows in the order of whichever index it happened to read, so the next query could give a different page. Adding a fully unique sort fixes it.

Fixed: "Expression 'COLLATE utf8mb4_bin' in the SQL tree does not have a type mapping assigned" in EF Core with MySQL

· 7 min read
Jagdish Kumawat
Founder @ Dewiride

I added StringComparison.OrdinalIgnoreCase to a Contains in an EF Core query, to make sure the search ignored case. With Oracle's MySQL provider, it failed with an unusual message: Expression '[SqlExpressions.SqlFunctionExpression] COLLATE utf8mb4_bin' in the SQL tree does not have a type mapping assigned. The search was already ignoring case, because the column's collation does. Removing the argument fixed it.

Fixed: EF Core StartsWith Finds Nothing While Contains Works (Case-Sensitive with Oracle's MySql.EntityFrameworkCore)

· 7 min read
Jagdish Kumawat
Founder @ Dewiride

A search for usb with Contains found five products named USB-C …. The same search with StartsWith found none, and neither threw an error. With Oracle's MySQL provider for EF Core, StartsWith and EndsWith compare with a case-sensitive collation, while Contains uses the column's own, which ignores case. EF.Functions.Like gives you a prefix search that follows the column.

Fixed: "Sequence contains more than one element" with EF Core SingleOrDefaultAsync

· 6 min read
Jagdish Kumawat
Founder @ Dewiride

SingleOrDefaultAsync threw InvalidOperationException: Sequence contains more than one element. The "OrDefault" in the name only covers zero rows. Single means "there's at most one", and when MySQL returns two it treats that as a bug and says so. Usually it's right: the filter is missing or too loose.

Fixed: "Sequence contains no elements" with EF Core FirstAsync

· 5 min read
Jagdish Kumawat
Founder @ Dewiride

A request for a category that doesn't exist answered 500, with InvalidOperationException: Sequence contains no elements. The database was fine, and so was the SQL: it ran and found nothing. FirstAsync treats "nothing" as an exception. For an ID a client sent, nothing is a normal answer, so the code should use FirstOrDefaultAsync and reply 404.

Fixed: "Cannot access a disposed context instance" in EF Core

· 6 min read
Jagdish Kumawat
Founder @ Dewiride

An endpoint started some work in the background and answered 200 OK straight away. Half a second later the log said ObjectDisposedException: Cannot access a disposed context instance. The DbContext belongs to the request: when the request ended, ASP.NET Core disposed of it, and the background task was still holding it. Background work needs a context of its own.