-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
EFC Tooling always forces a rebuild #32801
Comments
What commands do you typically run? |
A typical flow might look like this: So as you can see with the time it takes to build my database project, that wastes like 4 minutes at minimum, not accounting for any typo's or incorrect inputs / context's fed to the commands. |
@Suchiman If you are sure the project is up-to-date, then just pass |
huh i've never noticed that flag, thanks! Is there a particular reason though to not rely on msbuild's up-to-date check? |
@Suchiman The idea is that when you do |
@ajcvickers even if i issue efcore/src/dotnet-ef/Project.cs Lines 137 to 174 in 9a1b7fc
which is called from here efcore/src/dotnet-ef/RootCommand.cs Lines 79 to 84 in 9a1b7fc
Grabing the command line from taskmgr reveals it issues dotnet build C:\Path\To\Database.csproj /verbosity:quiet /nologo /p:PublishAot=false which matches that code and looks fine. If i issue it manually in the cmd, it finishes quickly, printing
indicating that the up-to-date check is working, however everytime i invoke |
@Suchiman Note that this area has been investigated previously. If you find something simple and safe to change that helps, that's great, but in general if you want full control over how builds happen then build outside of the EF command line. |
I find this issue interesting. For my solution, a Running Digging deeper into this, I put the code from Console app for dotnet build
using System.Diagnostics;
using System.Diagnostics.CodeAnalysis;
using System.Text;
using System.Text.RegularExpressions;
using static AnsiConstants;
Running this command, takes exactly the same amount of time as |
One thing i've noticed in my first analysis was that the command is running with the
That is not entirely true, it's not the same check, VS has something called the "fast up-to-date-check" where it bypasses MSBuild entirely and judges if a project is up-to-date on its own. That can be turned off though if needed. |
I have identified the issue, it's this piece of code: efcore/src/dotnet-ef/Project.cs Lines 56 to 66 in 9a1b7fc
which writes a .target file into the obj directory on every tool invocation, thus always bumping its last modified timestamp and thus always failing the up-to-date check.
The reason for that is explained as well as
@ajcvickers is any of these options acceptable and would be accepted as a PR? |
We had a discussion on this in the team yesterday. In general, we don't want to make changes here just for perf. In other words, the bottom line is that it should be as reliable as possible, even if that's slower than it needs to be. The reason for this is that anybody is free to do their own thing and use We have a history of changes in MSBUILD and tooling impact what we do, especially when we try to be clever and do something non-standard. So, I can see we might accept a PR that removed some cleverness, as long as the impact is good or not too bad, but I suspect we would reject anything that added in any cleverness. |
I tried with > dotnet build
<build completed>
> dotnet ef migrations list --no-build
<results>
> dotnet build
<starts building, project not up-to-date> |
Awesome, thank you so much to @Suchiman and the team there for all your work in diagnosing and addressing this. 🙏 Adding migrations is becoming quite the pain point for me lately, taking many minutes to both build and optimize the model after the change. Any improvement to this process is greatly appreciated and welcomed. |
Running any EFC CLI (be it
dotnet ef
or the powershell ones) command will always printeven if the project is up to date. Our Database project (which only contains database classes) takes almost a minute to build so having to wait for a build everytime you issue a command severely degrades the innerloop experience. And as for the Powershell Commands, they'll lock up VS until the command has completed.
Include provider and version information
EF Core version: 8.0.1
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .NET 8.0
Operating system: Windows 10
IDE: Visual Studio 2022 17.9P1
The text was updated successfully, but these errors were encountered: