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.

When a container misbehaves, the first thing to read is what it printed. docker compose logs shows that output for any service in your compose.yaml: all of it, the last few lines, only the last few minutes, or live as it happens. This guide runs each option against a real MySQL 9.7 container and explains what you're looking at.

Unable to create a 'DbContext' of type 'Dewiride.Inventory.Data.InventoryDbContext'. The exception 'Unable to resolve service for type 'Microsoft.EntityFrameworkCore.DbContextOptions`1[Dewiride.Inventory.Data.InventoryDbContext]' while attempting to activate 'Dewiride.Inventory.Data.InventoryDbContext'.' was thrown while attempting to create an instance. The useful part is the line printed just before it: the app's own startup code had failed, so EF Core's tools couldn't get the DbContext the normal way. Here's how I ran into it with a migrations bundle, why --connection didn't help, and the fix.

NU1608: Detected package version outside of dependency constraint: Pomelo.EntityFrameworkCore.MySql 9.0.0 requires Microsoft.EntityFrameworkCore.Relational (>= 9.0.0 && <= 9.0.999) but version Microsoft.EntityFrameworkCore.Relational 10.0.14 was resolved. The message spells out the problem: the newest Pomelo MySQL provider is built for EF Core 9, and the project runs EF Core 10. That isn't a version to nudge; it's a provider that doesn't support your EF Core yet.

dotnet package update --vulnerable is .NET 10's way to move vulnerable packages to a fixed version in one command. In my solution it printed error: Restore failed, then Unhandled exception: Specified method is not supported., and stopped. The crash message is misleading; the cause is documented: the command restores to do its work, and TreatWarningsAsErrors turned NuGet's own vulnerability warning into a restore error.

error NU1903: Warning As Error: Package 'Newtonsoft.Json' 12.0.3 has a known high severity vulnerability, https://github.com/advisories/GHSA-5crp-9r3c-p9vr NuGet's built-in audit found a published security advisory for a package version the project uses, and because warnings were errors, restore stopped. The fix is one version change. Getting there took me two failed attempts first, and both are worth knowing.

System.IO.IOException: Failed to bind to address http://127.0.0.1:5190: address already in use. The app is fine; the port isn't free. Something else, very often another copy of the same app, is already listening on it. Here's how I found what held the port, stopped it cleanly, and when to pick another port instead.

error IDE0044: Make field readonly appeared the first time I made the build check code style. The rule is right more often than not: the field was set once and never changed, so the compiler can promise that it never will. Here's what the rule checks, why it was an error rather than a hint, and the fix.

error NU1109: Detected package downgrade: Microsoft.EntityFrameworkCore.Relational from 10.0.12 to centrally defined 10.0.11. Update the centrally managed package version to a higher version. In a solution with Central Package Management and transitive pinning, the central file asked for an older version of a package than one of the dependencies needs. The two lines under the message show exactly who wants what.

error: NU1202: Package Microsoft.EntityFrameworkCore 11.0.0-rc.3.26522.148 is not compatible with net10.0 (.NETCoreApp,Version=v10.0). Package Microsoft.EntityFrameworkCore 11.0.0-rc.3.26522.148 supports: net11.0 (.NETCoreApp,Version=v11.0) The package was fine, and so was the project; they were made for different .NET versions. The message names both, and dotnet package add refused before it changed anything.