Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long Compilation Time and Large Designer Files in EF Core 7 Project #33137

Closed
haoyk opened this issue Feb 22, 2024 · 4 comments
Closed

Long Compilation Time and Large Designer Files in EF Core 7 Project #33137

haoyk opened this issue Feb 22, 2024 · 4 comments

Comments

@haoyk
Copy link

haoyk commented Feb 22, 2024

I am developing a project using EF Core 7, which involves around 300 tables and over 200 migrations. Each migration's Designer file is exceptionally large, leading to extended project compilation times. I am seeking advice on how to address and optimize this issue.

@ajcvickers
Copy link
Member

Duplicate of #2174

@ajcvickers ajcvickers marked this as a duplicate of #2174 Feb 22, 2024
@roji
Copy link
Member

roji commented Feb 22, 2024

@haoyk the Designer file being exceptionally large points to you possibly including large seeding data or similar, which is highly discouraged (see seeding docs).

@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Feb 28, 2024
@babriSakaiTech
Copy link

@haoyk the Designer file being exceptionally large points to you possibly including large seeding data or similar, which is highly discouraged (see seeding docs).

Hi Roji, even without seeding any data, designer files get huge quickly in large applications. For instance, there are 500+ tables in my current project, and every designer file is 30k+ lines (~1MB). This leads to over 2 minutes of build time (instead of a few seconds without the designer files).

For now, I've added a condition to unload all designer files from the project in debug mode, and only load the last few ones when actively creating new migrations. A proper official fix would be welcome though.

@roji
Copy link
Member

roji commented Mar 27, 2024

For now, the only solution we can propose is to periodically squash your migrations, i.e. begin over - that makes sense when you know that all production servers are aligned on the latest migration, and keeping the history has very little value - see the docs for that. #2174 tracks a more first-class experience for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants