efcore: Remove-Migration does not remove last migration and does not restore ModelSnapshot
I have an asp.net core web api with 2 Contexts
when running (Package Manager Console) add-migration Test -context AppIdentityDbContext and then remove-migration -context AppIdentityDbContext
the generated migration file still exists
The verbose output from remove-migration ends with:
Executing 456 update commands as a batch.
A manual migration deletion was detected.
Reverting model snapshot.
Done.
'AppIdentityDbContext' disposed.
When there are real model changes and the modelsnapshot is changed, remove-migration does not revert those changes.
Changes that are generated (every time) are e.g.:
migrationBuilder.UpdateData(
table: "AspNetRoles",
keyColumn: "Id",
keyValue: new Guid("5de8d15a-02c5-4042-b7ed-a4a77f5a8f3a"),
columns: new[] { "CreatedAtUtc", "ModifiedAtUtc" },
values: new object[] { new DateTime(2019, 6, 1, 10, 0, 0, 0, DateTimeKind.Utc), new DateTime(2019, 6, 1, 10, 0, 0, 0, DateTimeKind.Utc) });
CreatedAtUtc, ModifiedAtUtc are additional properties on our custom Role class which is derived from IdentityRole<Guid>.
These values are generated from DateTime.Parse(…) and then spcifing DateTimeKind.Utc
And everytime i add a new migration i get the same changes to be applied
Further technical details
dotnet core skd: 3.1.300 EF Core version: 3.1.4 Database provider: Microsoft.EntityFrameworkCore.SqlServer Target framework: .NET Core 3.1) Operating system: Windows 10 IDE: Visual Studio 2019 16.6.1
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 26 (11 by maintainers)
Commits related to this issue
- Fix issue where property with value generated on add is reseeded in every migration Fixes #21146 — committed to dotnet/efcore by ChristopherHaws 4 years ago
- Fix issue where property with value generated on add is reseeded in every migration (#22760) Fixes #21146 Co-authored-by: Christopher Haws <cribs2@gmail.com> — committed to dotnet/efcore by AndriySvyryd 4 years ago
Looking at the LTS policy vs Release Planning, it appears that there is little (if any) reason for designating a version to be LTS. What does the LTS designation provide that a non-LTS version doesn’t? It can’t be stability. LTS versions are designated as such when they are released, right? That means they are just as likely to be buggy as a non-LTS version.
With a non-LTS verson, critical bugs may be patched, and less-than-critical bugs might be fixed, but in a newer version. As I understand it, isn’t that basically the same as an LTS version?
What exactly is the “support” in a Long-Term Support version?
Conversely, for open-source software like .NET core, what does EOL really mean anyway? How is .NET Core 2.2 different (as far as support goes) from the LTS 3.1? Both have known bugs that were decided to be fixed in later versions, meaning that for certain bugs, the only way to get the fixes is to upgrade.
According to the release planning mentioned above, “The bar to make a change in a patch release is very high.”, and “This bar gradually rises through the lifetime of a long-term support (LTS) release.” Doesn’t that just mean that the older an LTS version gets, the less likely it is to be patched? That doesn’t really sound like support (long-term or otherwise), but rather the opposite.
From what I see, an LTS version is actually worse than a non-LTS version, because it only makes you think staying on that version is good, rather than upgrading.
If your policy around fixing bugs in LTS versions isn’t going to change, I’d recommend dropping the concept of LTS versions completely, as it seems to do little more than confuse developers who are familiar with what LTS typically means.
Note from triage: @AndriySvyryd to prepare a 3.1 patch to take for approval.
Security updates for three years.
No more security updates.
If it’s features and bug fixes you’re looking for, I would have to agree with you. Heck, use the daily builds if you can live with a bit of churn around new features as we develop them.
In the past, we’ve asked the .NET leadership for stronger and more consistent semantics around what LTS means across .NET products. We’ll continue to advocate for our users and forward feedback like this along to them.
BTW, there was an interesting discussion around this on the Entity Framework Community Standup last month.
Also suffering from this bug, If it was a minor bug, I would understand why it won’t be ported to 3.1. But that’s a quite serious one, From what I read here, my alternative is to upgrade to 5.0RC… which seems to be very buggy, in order to be able to continue coding using Migrations.
I would really appreciate if this bugfix could be ported to 3.1. It was only broken in one of the latest minor builds, since it was working fine until not so long ago.
I assume this fix will be ported into 3.1, correct?
After upgrading to latest .net core nuget packages to 3.1LTS, still having this issue.
When I Remove-Migration -Verbose, I get the “A manual migration deletion was detected.” message, And the migration is not removed from the snapshot + the migration file is not deleted.
Will appreciate any direction @bricelam
Postpone it to a 5.0.0 Milestone is a real bad thing for me. At the moment a empty migration will generate 10k lines of rubbish.
If i have a real migration with updated columns, data etc. it will be horrible to find these real changes an double check if they are correct.
So why will it fixed that late?