I'm currently working on a data-heavy (lots of models, sprocs, data movement, and most importantly to this question, migrations) backend API. After 10 weeks of dev work, we've generated (via migrations) 141 Designer.cs files with 522,713 LoC.
Along the way we've noticed our build times balloon. It now takes 2 minutes for a clean rebuild and 4 minutes for a server restart (via dotnet watch run) after a single file change. Autocomplete in the IDE is nearly worthless. It takes minutes for the code analyzers to recognize that we've fixed a compile problem in a file and stop marking it as an error.
Just out of curiosity, I deleted all the Designer files. My clean build dropped to 15 seconds. In reading up, it sounds like we can squash our migrations. That said, before I head down this route I wanted to check and see: what's the best way to handle the code bloat from the auto-generated, migration-related Designer files?
Don't delete the designer file, it can cause unexpected things to happen when applying migrations.
Try moving them into another project. Set the output directory of that project to be the same as your main application:
<PropertyGroup>
<BaseOutputPath>..\WebApplication1\bin\</BaseOutputPath>
</PropertyGroup>
Then tell EF where to find the migrations:
services.AddDbContext<BlogContext>(
options => options.UseSqlServer(
Configuration.GetConnectionString("DefaultConnection"),
x => x.MigrationsAssembly("MyMigrationsAssembly")));
If you apply migrations at runtime (not reccomended), you'll need to remember to build the migrations project before running the app.