.NET Framework and Core for Application Development
View All Tags
A request that normally takes a millisecond failed after exactly 15 seconds with error connecting: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. MySQL itself was fine and nearly idle. All the app's connections were taken, by requests that were never going to finish.
I set a short CommandTimeout, expecting an error when a statement ran too long. Instead, the request never answered at all. MySQL had finished long ago, and the connection sat idle, out of reach of everything else. If you're on Oracle's MySql.Data, any async statement slower than CommandTimeout can do this, including a default of 30 seconds behind a row lock.
I had EnableRetryOnFailure turned on, so I assumed a deadlock or a short outage would be retried. With Oracle's MySQL provider, nothing was retried, ever, and no message says so. The provider asks each error whether it's temporary, and MySqlException always answers no. The fix is one argument.
Part 2 created the tables, and they're still empty. In this part the API starts using them: you'll insert, read, change and delete rows through real endpoints, and read the SQL that EF Core sends to MySQL for every one of them. You'll also turn MySQL's refusals, such as a duplicate name, into clear HTTP answers, and stop two people from silently overwriting each other's changes.
When an UPDATE sets a column to the value it already has, did it affect the row? MySQL can answer either way, and a connection string option decides which you get. With Oracle's connector, the default is "yes", and that matters more than it looks. Turn the option on, and EF Core starts throwing an exception on some ordinary saves.
ASP.NET Core can generate an OpenAPI document from your endpoints, and what it can work out by itself is a list of paths. It can't know that an endpoint "deletes a category that has no products", or that it can answer 409. Four small methods add what's missing. This guide uses them, and shows the JSON that comes out.
logger.LogInformation("Archived product {ProductId}", id) works, but with stricter analyzers it stops the build with CA1848. The replacement is a [LoggerMessage] method: you declare one line, and a source generator writes the rest. Each message gets a name, an event ID and a level in one place, and the call looks like any other method.
Taking an EF Core entity as a request body, and returning one as a response, is less code. It also ties your API to your database, and hands clients control of columns you never meant to share. Here are three real failures of that approach, on a real API, and the small records that prevent them.
On your machine you want to see every SQL statement. In Production you don't: it's noise, and it costs money to store. ASP.NET Core reads appsettings.json, then the file for the current environment on top of it, so one setting in each gives you both. This guide does that for EF Core's SQL log, and checks it in both environments.
DateTime.UtcNow is easy to call and hard to control. Code that checks "is this overdue?" gives a different answer every day, and you can't ask it about next month. TimeProvider, built into .NET 8 and later, is a clock you pass in. Your app uses the real one, and anything else can use a clock that says whatever you need.
