76 posts tagged with "Command Line Interface"

Change an entity, forget dotnet ef migrations add, and the code and the database quietly disagree until something fails. EF Core has a command that catches exactly that: dotnet ef migrations has-pending-model-changes. This guide shows both of its answers, what it actually compares, how to use its exit code in a build, and how it proves that a refactor of your model configuration changed nothing.

Before applying, reverting or scripting migrations, you need two answers: which migrations exist in the code, and which ones this database already has. dotnet ef migrations list gives both in one list. This guide reads its output, including the (Pending) marker, gets the same list as JSON, lists without a database, and looks at the __EFMigrationsHistory table where EF Core keeps the record.

dotnet ef database update applies migrations straight to a database. Often you want the SQL instead: to read exactly what will run, to have a database administrator review it, or to apply it where the tools can't reach. dotnet ef migrations script generates that SQL from your migrations. This guide covers every form of the command with real scripts for MySQL, and shows why reading the SQL catches problems the C# migration hides.

Keeping the DbContext and its entities in a class library, separate from the web API, is a clean way to structure a .NET C# solution. It also means dotnet ef needs to know about two projects, not one, and the tools' errors when it doesn't are some of the most searched in EF Core. This guide explains the two roles, shows all three errors live, and gives the command that works.

Until .NET 10, even a three-line C# program needed a project file. Now dotnet run hello.cs runs a single .cs file directly, and a line at the top can pull in NuGet packages. It's perfect for small tools and quick tests, like checking that a database connection string works. This guide writes one, adds a package, shows where .NET builds it, and turns it into a normal project when it outgrows one file.

By default, every dotnet command uses the newest .NET SDK on the computer. That's fine until a teammate or a build server has a different one, and the same project starts behaving differently. A global.json file at the root of your repository settles which SDK the project uses. This guide creates one with .NET 10, then tries every rollForward value against the real SDK installed on this computer, so you can see which ones pass and which fail before you choose.

Before you create or build a C# project, it helps to know which .NET versions your computer has. One dotnet command answers each question: which SDK your project will use, which SDKs and runtimes are installed, and whether any of them needs an update. This guide runs each one on a Mac with .NET 10 and explains every line of output.

dotnet ef, the command-line tools for Entity Framework Core, is usually installed once for the whole computer. Installed as a local tool instead, it's pinned to an exact version in a small file inside your repository, so every developer and every build machine runs the same version as the project's EF Core packages. This guide installs it that way with .NET 10, shows every command's real output, and adds the one package the tools need in your project.

A table with a dozen columns doesn't fit in a terminal, and the mysql client's boxed output wraps into lines nobody can read. Ending the statement with \G instead of ; prints each row vertically, one column: value per line. This guide shows the difference on a real MySQL 9.7 table, and the client option that makes every result vertical.

Sometimes you need to look inside a running container: check a tool's version, read an environment variable, or poke around its files. docker compose exec runs a command inside a container that Compose started, without stopping it and without installing anything on your computer. This guide runs it against a real MySQL 9.7 container, from a one-line command to a full interactive shell.