Bad core generation on `ef migrations add lc`

[davhdavh]

Bug description

Running ef migrations add with a migration with lower case migration names and warnings as errors, leaves the project in a unrecoverable state.

Your code

>dotnet ef migrations add test
Build started...
Build succeeded.
Done. To undo this action, use 'ef migrations remove'
> dotnet ef migrations remove
Build started...
Build failed. Use dotnet build to see the errors.



1>...\20250411090328_test.cs(8,26): Error CS8981: The type name 'test' only contains lower-cased ascii characters. Such names may become reserved for the language.
1>...\20250411090328_test.Designer.cs(16,19): Error CS8981: The type name 'test' only contains lower-cased ascii characters. Such names may become reserved for the language.

Stack traces

Verbose output

EF Core version

9.0.3

Database provider

NA

Target framework

.NET 9.0

Operating system

na

IDE

v17.13.4

[roji]

This is by design. The name of the migration becomes the name of the .NET type EF generates for that migration; if you've opted into the warning wave which produces, and also activated warnings-as-errors, then this is indeed an error and you need to instead choose migration names that comply. Use PascalCase naming instead (so dotnef ef migrations add Test).

[davhdavh]

Which made sense prior to C#13. Now it should auto capitalize the first letter to avoid conflicts. That will also avoid any problems with actually using an existing keyword.

[roji]

We generally avoid trying to detect and fix problematic names that users give to migrations, because that's not possible in the general case. For example, a common thing that people do is give the name of an existing type such as DateTime, which then conflicts. Or their own type, which we can't possibly detect.

Though it's true that for this kind of case, which is becoming universally "wrong" in C# and which we can detect, it may make sense for us to handle it. Leaving open for us to discuss in design.