How to handle huge efcore migrations designer files that is slowing down build and IDE

4.3k Views Asked by At

I currently have an efcore 2.1 project with about 230 entities and about 350 migrations. Every time i add an efcore migration, a designer file is created. This file is approximately 535 kb and growing (150mb total for alle designer files). This makes the IDE slow and unresponsive, refactoring is a no go, it also makes the build process slower. If i delete all designer files, the build goes down from 110 to 20 seconds, and the IDE gets snappy again.

however, once I delete all designer files, i'm not able to work with the "dotnet ef database" command.

I have also previously merged all migrations. this worked, except there were some issues doing this in a team setting (had to run manual commands on each developer machine, no team members could have any unsynced migrations etc) and it is only temporary as the migrations start piling up again after a while.

I am curious if there are other projects with the same problem, and how they work around this?

4

There are 4 best solutions below

12
On BEST ANSWER

Now, in the future, it's possible to add an .editorconfig file to the Migrations folder, with the following contents:

# All files
# Sets generated code for all migrations
[*]
generated_code = true

It will disable all analyzers, which makes my IDE much happier with all the migrations.

Note: requires Visual Studio 16.5

0
On

I think your question is a duplicate of Recommended way to clean old Entity Framework Core migrations and Entity Framework Core: Is it safe to delete Migration.Designer.cs if we will never Revert a migration?. The whole topic is discussed in various answers on these threads.

I suggest to consider my answer in order to get your IDE snappy again and to reduce compilation time. And in the long run, it seems good practice to roll-up all migrations into one from time to time. If this is not urgent in your case, you might want to wait for this feature (planned for .NET 6) that allows you to do so in a simpler way.

1
On

You can use another assemblies to manage migrations.

0
On

You can try to purge your migration files. I sometimes use it to keep the data module small and compilable. You can find this link useful.