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

Correct EF Core migration path #541

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions IdentityServer/v7/docs/content/upgrades/v6.3_to_v7.0.md
Original file line number Diff line number Diff line change
Expand Up @@ -59,9 +59,9 @@ We also provide a default implementation of the stores in the *Duende.IdentitySe
To generate a migration for the new columns, run the command below. Note that you might need to adjust paths based on your specific organization of the migration files.

```shell
dotnet ef migrations add Update_DuendeIdentityServer_v7_0 -c ConfigurationDbContext -o Migrations/ConfigurationDb
dotnet ef migrations add Update_DuendeIdentityServer_v7_0 -c ConfigurationDbContext -o Data/Migrations/ConfigurationDb

dotnet ef migrations add Update_DuendeIdentityServer_v7_0 -c PersistedGrantDbContext -o Migrations/PersistedGrantDb
dotnet ef migrations add Update_DuendeIdentityServer_v7_0 -c PersistedGrantDbContext -o Data/Migrations/PersistedGrantDb
```

The *ServerSideSession.Id* property has been changed from *int* to *long*. The generated migration handles the data type change but does not take into account that this column is the primary key for the table. If the primary key constraint is not removed, running the migration will fail. The primary key of the table needs to be dropped before the type is altered and then recreated. The easiest way to do so is to update the generated migration file:
Expand Down Expand Up @@ -144,4 +144,4 @@ That's it. Of course, at this point you can and should test that your IdentitySe
You are now done with everything related to the IdentityServer upgrade, but we would also like to add a references to breaking changes in .NET 8 and associated libraries that are likely to affect the IdentityServer setup.
- Entity Framework Core 8 has some performance improvements in the query generation for Microsoft SQL Server that relies on database features that requires a database compatibility level of at least 130. This can cause errors on database access like *Microsoft.Data.SqlClient.SqlException (0x80131904): The syntax near '$' is incorrect.* or *Microsoft.Data.SqlClient.SqlException (0x80131904): Incorrect syntax near the keyword 'WITH'.* Please see https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-8.0/breaking-changes#mitigations for more information.
- For container deployments, the [default ASP.NET Core port changed from 80 to 8080](https://learn.microsoft.com/en-us/dotnet/core/compatibility/containers/8.0/aspnet-port). This might require configuration updates to either continue using port 80 or to migrate to using 8080.
- IdentityServer and the Asp.Net Authentication packages all depends on the *Microsoft.IdentityModel.** packages. With packages that are brought in as transient dependencies there is less control of the versions being pulled in. If different packages from the *Microsoft.IdentityModel.** family end up having different versions, there will be odd bugs. We've seen reports where the refresh token isn't stored and where the OIDC handler fails to redirect to an OIDC Provider because it failed reading the discovyer document. **Always ensure that all Microsoft.IdentityModel.\* packages are of exactly the same version**. If they are not, you might need to make an explicit *<PackageReference>* to pin an exact version.
- IdentityServer and the Asp.Net Authentication packages all depends on the *Microsoft.IdentityModel.** packages. With packages that are brought in as transient dependencies there is less control of the versions being pulled in. If different packages from the *Microsoft.IdentityModel.** family end up having different versions, there will be odd bugs. We've seen reports where the refresh token isn't stored and where the OIDC handler fails to redirect to an OIDC Provider because it failed reading the discovyer document. **Always ensure that all Microsoft.IdentityModel.\* packages are of exactly the same version**. If they are not, you might need to make an explicit *<PackageReference>* to pin an exact version.