Net4x.IdentityData 2.2.0.26250

Net4x.IdentityData

ASP.NET Core Identity data contexts with renamed tables, an application-settings table, and a start-up schema updater that applies dated SQL scripts to an existing database.

Target frameworks: net6.0, net8.0, net10.0.

dotnet add package Net4x.IdentityData

What is in the package

Identity table names

ApplicationBaseDbContext maps the Identity model onto shorter table names:

Getting started

builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("ConnectionStringApp")));

builder.Services.AddDefaultIdentity<IdentityUser>()
    .AddEntityFrameworkStores<ApplicationDbContext>();

The context migrates itself the first time one is constructed. Each concrete context type is migrated once per process; ApplicationBaseDbContext._migrated = true suppresses migration entirely when the schema is deployed out of band.

Application settings table

public class SettingsService(AppSettingsDbContext context)
{
    public string? Get(string key) =>
        context.AppSettings.SingleOrDefault(setting => setting.Key == key)?.Value;
}

Key is a varchar(500) primary key, Value a varchar(4000) defaulting to the empty string.

Applying SQL update scripts

EF migrations cover the schema the package owns. DatabaseUpdater covers everything else: hand written scripts applied in order to a database that already exists.

using DapperLibrary.SqlServer.DbContexts;

// Register a Dapper provider once, at start-up.
SqlDapperContext.Use();

DatabaseUpdater.CreateInstance()
    .UpdateDataBase<ApplicationDbContext>("ConnectionStringApp", @"C:\app\sql");

Name each script <anything><Database>_<yyyyMMdd>.sql, for example Widgets_20240729.sql:

• Scripts are selected by the eight digit stamp in the file name — digits in the directory path are ignored — and applied oldest first.
• Only scripts newer than the version already recorded are applied.
• Batches are split on a line containing only GO (any line ending, optional repeat count).
• USE batches are dropped; the connection decides the catalog.
• The highest version applied without error is written to an UpdateHistory table, which the updater creates if it is missing. A script that fails is logged and leaves the remaining scripts pending for the next run.

UpdateDataBase is a start-up path and is deliberately quiet: if the database does not exist yet, is unreachable, or no Dapper provider has been registered, it logs and returns rather than taking the host down. Scripts are only applied when the resolved connection string uses SQL authentication and sysadmin credentials are configured — see below.

Set ConfigurationVariables.Instance.DontUpdateDatabase = true to skip script application altogether, and ConfigurationVariables.Instance.ProviderName (default Microsoft.Data.SqlClient) to choose the provider used for the existence probe.

Configuration keys

Connection details are read through ConfigurationLibrary's ArgumentGetter, which draws on app settings, environment variables and the command line. Every key may be suffixed with the database name to override it for a single database — DatabaseUserIdWidgets beats DatabaseUserId.

A connection string may be a template with four positional placeholders — {0} user, {1} password, {2} data source, {3} database. With nothing configured at all the built-in template is used:

Initial Catalog={3};Data Source={2};User Id={0};Password={1};TrustServerCertificate=True;

SysAdminUtility puts SysAdminUserId / SysAdminPassword in place of the ordinary credentials for as long as it is held, and restores them on Dispose. Both must be set for SysAdminPatched to be true, which is what gates script application.

Developer-local overrides

A Local.txt — or Local.<username>.txt, which wins — next to the assembly is copied to Local.config and layered over the packaged configuration the first time a connection is initialised. It is an ordinary .config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="DataSource" value="localhost" />
    <add key="DatabaseUserId" value="sa" />
  </appSettings>
</configuration>

The override is a convenience: an unreadable file is logged and skipped, never fatal.

Building connection strings yourself

var initializer = DbContextConnectionInitializer<ApplicationDbContext>.Instance
    .CreateContextConnectionInitializer();

initializer.GettingConnectionString += (_, e) => e.Value = Decrypt(e.Value);

using var connection = initializer.Connection;

DbContextConnectionInitializer<TContext>.Instance resolves the database name from the context type. The non-generic DbContextConnectionInitializer.Instance has overloads taking a DbContext type, a database name, a connection string name and database name, or a ready-made ConnectionStringSettings. Either way a context type is reduced to a database name by stripping the DbContext / Context suffix, so ApplicationDbContext reads configuration for Application.

GettingConnectionString, GettingProviderName and GettingDatabaseName let a host rewrite each resolved value — decrypting a password, redirecting to a tenant catalog. Subscribing to ConnectionInitializerCreating and setting Cancel vetoes creation, which makes CreateContextConnectionInitializer return null.

ProviderFactory is null when the named provider is not registered with DbProviderFactories; register yours at start-up if you need a live Connection.

Source

Part of the Net4x common library set — https://bitbucket.org/pieroviano/identityapplication.