ASP.Net Core Identity, EFMigrations and Database Deployments

I'm now adding the Security / ASP.Net Core Identity to my app.

I see that after enabling it and running the app, I have several new tables.

I'm currently using https://dbup.readthedocs.io/en/latest/ to manage my database changes so I can version each change and track the version of each database.

One of the tables that enabling Security added was "__EFMigrationsHistory".

There is nothing in the Radzen Blazor Studio docs about this table.

Can someone from the development team tell me how I can anticipate this table being used?

Is this to handle future anticipated changes to the Security tables?

Should I add this table and it's data to my DbUp Database Migration scripts?

I have another related question.

The Security tables didn't appear until I ran my application locally, then they were created on my local database.

But for security reasons, when I deploy my App to testing and production environments, I would like the account the App connects to the database with to only have DML rights, meaning the App won't be able to issue CREATE TABLE or any commands like that (DDL).

I see the Data Migrations files located in "Server\Data\Migrations".

Are these files needed? If I update my SMTP settings in the AppConfig files directly, can I remove these files?

I'd prefer to manage all changes to the database using DbUp, is that possible?

I've confirmed that at this point forward the App requires the EFMigrations table & the one inserted row.

I've added these to my DbUp scripts along with the AspNetCore Security tables, and validated I could deploy the changes to a new DB and the App still works.

This is not something specific to Radzen, check the official Microsoft document for more information:

While ASP.NET Core and the Security portion isn't specific to Radzen, what is specific is that Radzen is doing things to my code and also my database.

The link you posted has what appears to be a lengthy walkthrough.

In Radzen it was a few button clicks, which while good/easy, would be great to have documented all the things it is doing.

It would also be really helpful to document how Radzen might make additional changes to the database in the future.

Could you share how the team envisions this being deployed to a Production environment, where the App/Web server doesn't have permission to issue DDL commands?

If I can't be certain when Radzen alters my local development database, it's a concern that Production deployments might fail.

Hey @DB1234,

I strongly suggest you to read carefully the article from my previous reply.
In short:
ASP.NET Identity works with your database and will create various tables for roles, users, etc. These tables are created using Code First migration on application first run - what Radzen does is to create exactly the same code generated by Microsoft Visual Studio when you enable ASP.NET Identity security. If you do not have the same security tables in your production database your application will not work properly when deployed. Again, this is not something specific to Radzen, ASP.NET Identity overview is explicitly linked in our documentation : Security

Thanks, I've been reading up on the link you posted.

I'm still not following what the preferred pattern is for Production deployments.

In almost all environments that I've worked in, we restricted the permissions of the database account the app used to access the database.

So if I did so with my app, the DDL would never run. Hope that makes sense.

Additionally many third party DB tools and Visual studio have the ability to compare 2 databases (schema and data) and generate scripts.
You need to backup the production database before update and review the scripts as some changes could result in loss of data.

And if you are working with Microsoft SQL Server, creating a database project in Visual Studio and deploying DAC PACs is the only way to go.