Control over migration script generation

[yzinc]

Question

After migration to .net 9 I faced with unexpected result in migration script.
Context, I'm generating sql migration script using next command

dotnet ef migrations script --project <project-name> --configuration Release --idempotent --startup-project <start-up-project> --output migration.sql --context <context-name>

Using .net8 I get

migration8.txt

but, using .net9 I get

migration9.txt

All migrations performs in SINGLE transaction, with only ONE GO statement. I didn't found any information about this changes and how it can be reconfigured. Honestly those changes are breaking for my project and I forced to looking some kind of workaround.

Highly appreciate for any advice/information.

Your code

Stack traces

Verbose output

EF Core version

9.0.1

Database provider

No response

Target framework

No response

Operating system

No response

IDE

No response

[cincuranet]

@maumar Do we have this documented somewhere? I see only Exception is thrown when applying migrations in an explicit transaction, which has basically same root cause. But for users it might not be clear that this affects script as well.

[roji]

Dup of #35096? Though @yzinc it would be good to know exactly why the single transaction breaks your application.

[cincuranet]

Not exactly dup, but related.

[yzinc]

@roji Main issue is that all migration treated as single scope due to single batch and single transaction. So If you add some custom migration script with variable declaration, all variables accross all migrations have to be with unique names.

Here is example of exception I've got.

The variable name '@roleId' has already been declared. Variable names must be unique within a query batch or stored procedure.

More context, if some migrations need to be performed regulary due to some business needs or whatever. Usually some C# code are written to optimize this process and if variables declarations are required to perform such operations in each regular migration will have same variable name.

Previously it was not a problem due to own transaction and batch scope. But now it's a problem which do not allow to run migrations at all without some "hacks".

[roji]

Thanks @yzinc.

@cincuranet how do you see this as different from #35096?

[cincuranet]

AFAICT #35096 is not specifically about script.

[roji]

I'm not sure this one is specifically about script either - AFAICT you'd encounter the exact same problem try to apply the migration in some other way (e.g. dotnet ef database update).. It seems to be just another example of something that doesn't work when the same transaction is used across all migrations.