Add Migrations UI picks up old binaries - requires manually cleaning projects before running

[Brads3290]

Describe the bug

The Add Migrations command (and presumably the other commands too) pick up old binaries when run, unless you manually clean the projects first.

Note: This is not an ef core CLI bug - see the Expected Behaviour section: dotnet ef does not exhibit this problem.

To Reproduce

1. Clone https://github.com/Brads3290/EfCoreUIRepro
2. Add a migration using the ef core plugin
   • Right-click on the EfCoreUIRepro project, then Tools -> Entity Framework Core -> Add Migration
   • Leave defaults and click OK. Wait for migration to finish.
   • Notice the console message: "Message one"
3. Open ReproDbContext.cs and add in the Comments set (uncomment it), and also change the Console.WriteLine message.
4. Repeat step 2
   • Notice the console message is still "Message one", and there are no changes in the migration
5. Clean the project, then repeat step 2 again
   • Notice the console message has now changed, and the Comments changes are now present in the migration

Expected behavior

You should not need to clean the solution in between adding migrations.

If you repeat the above steps but instead paste the generated dotnet ef command into the terminal (instead of clicking OK on the dialog), you will see that you don't need to clean in between migrations - it just rebuilds automatically.

Something is happening behind the scenes with this plugin that's causing dotnet ef to pick up the old binaries.

Screenshots

Using the UI (broken)

Using dotnet ef CLI (working)

Environment (please complete the following information):

• OS: MacOS Ventura 13.4.1 (M1)
• .NET SDK info (installed ones and version used within Rider):
  • 6.0.408 [/usr/local/share/dotnet/sdk]
  • 6.0.412 [/usr/local/share/dotnet/sdk]
  • 7.0.203 [/usr/local/share/dotnet/sdk]
  • 7.0.302 [/usr/local/share/dotnet/sdk]
  • 7.0.306 [/usr/local/share/dotnet/sdk] (Used by rider)
• Plugin version: 232.1.0
• Rider version: 2023.2.1 (Build #RD-232.9559.61, built on August 23, 2023)

[seclerp]

Hi @Brads3290, thanks for the ticket, but I cannot reproduce the issue following your steps.

Something is happening behind the scenes with this plugin that's causing dotnet ef to pick up the old binaries.

it's a really strange one. The EF Core plugin itself is just a facade over dotnet ef calls, it executes the command that you see in the console without any additional modifications.

We also don't cache anything related to the build itself when executing commands. As you can see, the build process is starting from dotnet ef itself, not from Rider.

The only difference between using a terminal and using UI is that we set some .NET-related environments to skip the logo and propagate the same .NET root used by Rider:

DOTNET_NOLOGO=true
DOTNET_ROOT=/usr/local/share/dotnet
DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true

[Brads3290]

Hi @seclerp, thanks for trying to replicate this - very strange.

Out of curiosity, which OS were you using when you tried to reproduce the issue?

I've just (re)tried clearing Rider caches and restarting my machine, just in case.. but the issue is still present on my end.

I also tried to run the command from the terminal with those environment variables set, and it didn't reproduce the issue.

[seclerp]

I'm using the exact same setup - Ventura 13.4.1 on M1.

Do you maybe have some additional configuration in Rider around the build system?

[seclerp]

Also, I have 2 more questions:

1. Do you store this project inside the temp directory? if so, please try to execute the command from the directory outside of the temp one.
2. Do you have any symlinks to the solution directory?

I will prepare a special build of the plugin with the ability to enable dotnet ef diagnostic logs and will send you.

[seclerp]

Here you go. Please check the "Enable diagnostic logging" checkbox under the Execution group and execute the command again.

rider-efcore-232.1.1-verbose01.zip

You can find the .zip installation instructions here.

[andras-gyarmati]

in my solution all projects have 6.0.9 version but the tool tries to use 6.0.1, and i can not find any reference to that version in the code. how do i clean the project? is this the same error?

[seclerp]

@andras-gyarmati, no, this is the expected behavior. "EF Core tools" means .NET CLI tool dotnet efused to perform operations. And scope (global or local CLI tool). It is not related to NuGet versions in your projects. But it's highly recommended to keep them synchronized.

[sburbano]

Hi @seclerp

I was going to open a new issue but found this one, which might have the same cause... so here are my $0.02

The problem (I think) is that the plugin doesn't trigger a "save all files" before executing dotnet ef commands.

If you make a change to the model and issue an "Add Migration" immediately without saving, changes are not detected.

And the reason cleaning the solution solves the problem is that it "saves all" (like any build action) under the hood, thus fixing the issue.

So, the plugin should either save files or warn the user about unsaved files present.

[seclerp]

Hi @sburbano, thanks for the details! Yes, the plugin doesn't save anything before running operations, and it makes sense to do so.

@Brads3290 could you confirm this is your case too?