efcore: Build is not working after installing .Net5

@konraddysput we’d need more information here - are you seeing only a memory increase or also a build-time speed degradation (which is what is discussed above)? What are the exact numbers for both before and after upgradnig, and which versions? How big is your codebase in MB, and where is the size located (i.e. in the migrations folder?).

If you’d like to pursue this, please open a new issue with all of the above, and preferably some sort of code sample that shows this. For example, you can replace identifiers in your solution to make it publicly-sharable or similar.

I looked a little deeper.

First, apologies - I missed that this repro was using EF Core 3.1. The analyzer in that version has some known issues and was rewritten precisely for performance in 5.0 (#19648). I’ve changed the repro to use EF Core 5.0 and things unsurprisingly look much better. @Alirezanet @dasMulli you’re going to have to use the alpha 5.0 version of the Pomelo MySQL provider, or wait until the final version is released.

@jmarolf I’ve pushed the code to https://github.com/roji/AnalyzerTest, and ran some builds on both my Windows and Linux machines:

Scenario	Windows build time	Linux build time
Baseline (with everything)	1m11s	2m09s
Without Microsoft.EntityFrameworkCore.Analyzers	1m00s	1m07s
Without Microsoft.CodeAnalysis.NetAnalyzers	0m57s	1m53s
Without AnalysisLevel=latest	0m56s	1m40s
Without any analyzers	0m39s	0m42s

Note that in the build analyzer report, the total analyzer execution time (on Linux) is 0.422 and 3.820 seconds.

I’m still confused by the differences I’m seeing between Windows and Linux here. @jmarolf I’d be happy to dig further, but can you confirm that you’re seeing something similar?

BTW the build pins to SDK 5.0.103 via a global.json with rollForward=disable.

@dasMulli

Can you try compiling with a 5.0.200 preview and see if that fixes the issue? There was a compiler bug in 5.0.100 that manifested in patterns that are common in migration files.

• https://github.com/dotnet/roslyn/issues/48886 perf issue around anonymous types
• https://github.com/dotnet/roslyn/issues/49686 perf issue around intersection of nullable reference types and nested lambda expressions

Both of these bugs were triggered by the general structure of EF Core Migration files.

@roji there is a built-in msbuild property to disable .NET analyzers. Setting <EnableNETAnalyzers>false</EnableNETAnalyzers> will cause them to never be added to your project.

Here’s what I’m seeing:

• With SDK 5.0.102, compiling the Persistence project takes 5m3s
• Switching to SDK 5.0.200-preview.21111.2, the time goes down to 2m46s
• At that point, removing all analyzers makes the build time drop to 41s:

<Target Name="DisableAnalyzers" BeforeTargets="CoreCompile">
  <ItemGroup>
    <Analyzer Remove="@(Analyzer)" />
  </ItemGroup>
</Target>

• Specifically removing the EF Core analyzer makes the build time go back up to 2m41s, so there doesn’t seem to be a problem there. However, removing Microsoft.CodeAnalysis.NetAnalyzers makes the build time go down to around 50s:

<Target Name="DisableAnalyzers" BeforeTargets="CoreCompile">
  <ItemGroup>
    <SlowAnalyzer Include="@(Analyzer)" Condition="%(Filename) == 'Microsoft.CodeAnalysis.NetAnalyzers'" />
    <Analyzer Remove="@(SlowAnalyzer)"/> 
  </ItemGroup>
  <Message Text="Removed analyzers from $(AssemblyName): @(SlowAnalyzer)" Importance="high" Condition="'@(SlowAnalyzer)'!=''"/>
  <Message Text="Retained analyzers in $(AssemblyName): @(Analyzer)" Importance="high" Condition="'@(SlowAnalyzer)'!=''"/>
</Target>

/cc @jaredpar @mavasani @sharwell

---

Note that this is a pretty extreme case: the migrations folder weighs 221MB, with ~400 model snapshots weighing 100KB each. We plan to add migration squashing support in 6.0. In the meantime, @dasMulli @Alirezanet it’s recommended you can follow the instructions on how to reset your migrations.

Hey, this issue still exists. Not a big solution can consume 16GB of ram on my pc. Unfortunately, I can’t share my solution with you. Right now I see at least ~5k files in my solution. It looks like dotnet performance dropped significantly for me.

Thanks @roji for analyzing that! The issue just caught my attention b/c i was looking into our analyzer build performance previously. As mentioned, our project is fine with migrations being in their own projects with analyzers disabled causing minimal build impact (both due to no analyzers and up-to-date checks for inner loop perf).

Note that this is a pretty extreme case

Depends on the project I think, we’ve had even larger migration projects until recently - 2x mysql + 2x postrgres each at the size of @Alirezanet’s repro or larger (2 of them using quite a lot of seed data). Moving them to a separate project with analyzers disabled (and creating scripts to ensure the project builds and then invokes 4 dotnet ef commands) was workable - we also reset the migrations. For us nothing changed noticeably with the 5.0 SDK though - we’re still using EF Core 3.1 (b/c pomelo mysql needs some time and we don’t have the time to migrate to EF Core 5.0 but want the container & perf optimizations of the 5.0 runtime / SDK). For us the reason to disable Analyzers on the migrations was not only due to EF analyzers but also due to additional analyzers (StyleCop, Sonar).

Looking forward to that squashing feature! After going live, resetting is a tiny bit more cumbersome since we need to keep the migration versions that we actually shipped so only removing/regenerating between releases…

@roji the repo was posted by @Alirezanet in https://github.com/dotnet/efcore/issues/24135#issuecomment-735344548

I am very new to all of this but trying to learn doing a reset

i’ve got the same problem. when building proccess going through ef migrations, build fails. facing no problem on .net core 3.1 with .net 3 sdk. apart from upgrading to .net 5. also i’ve had some trouble on .net core 3.1 when .net 5 sdk is installed [build proccess takes a lot of time].