280 posts tagged with "C#"

In a freshly cloned .NET project, dotnet ef stopped with Unable to retrieve project metadata. Ensure it's an SDK-style project. It's an SDK-style project, and the message sent me looking in the wrong place. The real clue is the line above it, NETSDK1004: Assets file … not found: nobody had run a restore in this copy yet.

dotnet ef database update printed The model for context 'InventoryDbContext' has pending changes., then No migrations were applied, then Done., and exited with code 0. My new column wasn't in MySQL. That message has two possible causes, and with this provider it won't stop a script, so it's easy to miss.

I created a migration, and the very next command said The migration 'AddProductVersion' was not found. The file was right there in the Migrations folder. The cause was a flag I'd added to save a few seconds: --no-build makes the EF Core tools use the last compiled DLL, and that DLL was older than the migration.

I sent a product price of 9.999 to my API, and it answered 201 Created with a price of 10.00. No error, no warning: MySQL rounded the amount to fit its DECIMAL(12,2) column, even in strict mode, and raised only a note that EF Core never shows. For money, silently changing the number isn't acceptable, so the API now refuses it.

A long category name made my API answer 500, with Data too long for column 'Name' at row 1 in the log. MySQL was right to refuse it: the column is varchar(100), and the name had 101 characters. The problem was that the request got as far as MySQL at all. A validation attribute stops it first, and the client gets an answer it can act on.

Right after I added a property to an EF Core entity, every request that touched that table answered 500, and the log said MySqlException: Unknown column 'p.Version' in 'field list'. The code built without a problem, because the C# was fine. The table simply didn't have that column yet: changing the class doesn't change the database until a migration does.

Part 1 connected a .NET C# Web API to MySQL, but the database is still empty. This part describes the inventory data as C# classes and lets EF Core migrations create the matching MySQL tables, with the column types, keys, indexes and constraints you'd otherwise write by hand. You'll read the SQL before it runs, apply it, change the model and add a second migration, and then check every table from inside MySQL.

dotnet ef database update is fine on your own machine, but a server shouldn't need the .NET SDK, the source code and the EF Core tools just to update its database. A migrations bundle packs your migrations and the code that applies them into one executable you can copy anywhere. This guide builds one, runs it, and then runs it the way Microsoft recommends for deployments, which taught me two things the hard way.

builder.Services.AddDbContext(...), options binding, validation, retries, health checks: Program.cs fills up fast, and the database setup ends up scattered between other features. ASP.NET Core's own answer is the AddXyz method: AddControllers, AddHealthChecks, AddOpenApi. You can write your own the same way, as an extension method on IServiceCollection. This guide builds one for an EF Core database, calls it with one line, and shows its startup checks catching mistakes.

When an EF Core query is slow or a save fails, the first question is: what SQL did it actually send? In an ASP.NET Core app you usually don't need to add anything to find out: EF Core already writes every command to the log. This guide shows where it appears, how to turn it down when it's too noisy, and how to see the parameter values, carefully.