Huge migration .designer files kills ide/refactorings/analysis

[andrejohansson]

Ask a question

How are we supposed to manage the huge .designer files generated by migrations?

Every migration generates a several megabytes large .designer file. Since this is C# code it completely kills normal operation of IDEs, analyzers and/or refactorings.

While it´s possible to ignore the folder with migrations for things like analyzers, it´s not possible to ignore them from refactorings or from normal build.

So, whats the best practice here? It seems like I'm missing something or have made something wrong

• We seed quite a bit initial data to our db, mostly language resource strings, this is done in OnModelCreating(ModelBuilder modelBuilder). While it´s not changed between the migrations. It is still being copied to designer files.

The things I want is:

• Migrations
• An initial seed
• Ability to use refactorings and analysis without crashing/timing out

Include provider and version information

EF Core version: 3.1.8
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .NET 3.3
Operating system: Windows 10
IDE: JetBrains Rider

[ajcvickers]

@andrejohansson We're currently planning for EF Core 6.0, and better management of migrations is one of the themes we're planning to invest in. We'll discuss your specific concerns in the team and decide if these things are already tracked by other issues or not.

[andrejohansson]

Ok, thanks for the information. I'll see if I can find a workaround for now. Do you have any rough target estimate of when v6 will be released? Like...Q2 next year?

For reference, I have submitted a performance issue for JetBrains and given them some data in order to see if they can make the refactrorings work through these huge files:

https://youtrack.jetbrains.com/issue/RSRP-481570

[roji]

@andrejohansson anything in particular you're doing to get to designer files which are that big?

[andrejohansson]

I seed language strings in the initial db. Then they are replicated over and over again. Is there anywhere else I could/should seed?

[roji]

@andrejohansson seeding large amounts of data is something we specifically don't encourage because of this problem. I'd recommend switching over to manual initialization for that bulk data instead (see the docs).

We should maybe add a note about this to the seeding limitations section in that page.

[andrejohansson]

@roji, is there some way for me to use the HasData methods outside the OnModel... events? If I should do custom seeding it´s nice to have the ability to ensure the data is in a specific way instead of just inserting data blindly?

[roji]

@andrejohansson note that HasData doesn't actually verify your data in the table either - if someone changes the data directly in the database, EF is unaware of it and things get out of sync.

Can you provide more details on what you're looking for? If you want to verify anything about your data before doing seeding, you're going to have to do that yourself by executing queries.

[ErikEJ]

Maybe use a MERGE statement?

[andrejohansson]

@roji are you sure there is no verification done? Because if you create a new migration and have some alterations then the data will be update (I accidentally put a timestamp with DateTimeOffset.UtcNow once, hence got new data on each migration).

Anyway, what we want is a sustainable code-only mechanism to:

1. Seed an initial blank db
2. Seed integration tests (and this should not be included in production dbs)
3. Have the ability to evolve the seed data over time in a controlled and ergonomic way
4. Not destroying roslyn analyzers/ide with huge generated files

I think it´s just been confusing for me of what is the best practice and which things work well together. For example:

• Don´t use EnsureCreated with migrations
• Now, apparently, don´t seed much in OnModelCreating (out of curiosity, what data should be seeded here?)

[roji]

@roji are you sure there is no verification done? Because if you create a new migration and have some alterations then the data will be update (I accidentally put a timestamp with DateTimeOffset.UtcNow once, hence got new data on each migration).

Like with other migrations, the assumption is that seeded data isn't modified directly in the database without going through migrations - if you use migrations to manage it, you're supposed to always use migrations to manage it. If you change the value of some seeded property (e.g. by making it UtcNow), the next time (every time!) you add a migration, EF will detect that change and will generate a new migration to update it; but this happens at add migration time - comparing the new value with the last migration in your codebase (model snapshot), and not at migration deployment time by looking at what's in the database.

So in any case, you'll have implement your custom initialization logic (as in the docs). There are various possible strategies for this, but it's up to you to implement this (via EF Core of course, if you want); what you do is going to depend on how exactly your data can evolve (are rows only added? Do columns need to be modified in existing rows?).

Don´t use EnsureCreated with migrations

This isn't really related to seeding... EnsureCreated and migrations are simply two alternative, incompatible ways to manage your schema and set up a database.

out of curiosity, what data should be seeded here?

Seeding is meant for small, static data that rarely changes. It's unfortunately difficult to define exactly which scenarios work and which doesn't, I'll update the docs page.

[roji]

One more suggestion: you can still leverage EF Core's seeding by manually adding seeding calls into generated migrations yourself - but without having HasData in your model. This will make EF Core automatically perform the appropriate update when the migration is run, but will not include the data in your migration snapshots. It requires a bit more manual work when data changes, but should be quite usable.

[roji]

Duplicate of #21065

[roji]

#21065 already tracks possibly doing something better here, dotnet/EntityFramework.Docs#2416 tracks adding a doc note (which I've just done in dotnet/EntityFramework.Docs#2822.