Command Line Interface Tools and Techniques
View All Tags
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.
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.
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.
error CS0246: The type or namespace name 'Dewiride' could not be found (are you missing a using directive or an assembly reference?) The compiler ends the message with a question, and it's a good one: those are the two usual causes. The name in quotes and the line number tell you which one you have. Here are both, from the same .NET 10 project, and the fix for each.
MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file. I got it from a plain dotnet build, seconds after converting a solution to the new .slnx format. The conversion had worked; it had also left two solution files in one folder, and MSBuild won't guess which one you mean.
I built an EF Core migrations bundle, ran it, and got three lines instead of migrations: Failure processing application bundle. Failed to determine location for extracting embedded files. DOTNET_BUNDLE_EXTRACT_BASE_DIR is not set, and a read-write cache directory couldn't be created. The bundle was fine. The folder it extracts into, ~/.net, had belonged to root since 2023.
The migration '20261103044430_MakeDescriptionRequired' has already been applied to the database. Revert it and try again. If the migration has been applied to other databases, consider reverting its changes using a new migration instead. dotnet ef migrations remove checks the database before it deletes anything, and this migration was in it. The message holds both fixes: one for your own development database, one for every other database.
Your target project 'Dewiride.Inventory.Api' doesn't match your migrations assembly 'Dewiride.Inventory.Data'. Either change your target project or change your migrations assembly. dotnet ef built the solution, then refused to write the migration, because it would have put the files in a project where EF Core would never look for them. The message offers two fixes; one of them moves your migrations to the web project, and it's usually not the one you want.
