Blazor dependency injection and EF/DbContext with private NuGet packages - entity-framework

Question

I am trying to set up a Blazor project to be reusable through numerous other projects, and I am having issues understanding how Blazor's DI system works with NuGet packages.
In short, I built a simplistic Blazor app as a ticketing system for bug reports/requests. It collects simple information through input forms (built as components) and uploads tickets to a SQL Server database via Entity Framework and a connection string (stored in AppSettings.JSON). The DbContext is injected into the ticketing app's DI system via AddDbContextFactory. It all works perfectly within the solution.
My goal is: I want to package this ticketing system and reuse it throughout my other apps with minimal setup. In the other apps, I want to reuse the "AddTicket" components, which will simply accept some simple report data and update the ticketing databse.
As a test, I packaged the ticketing app as a NuGet package locally on my machine. I imported it into a separate host app. However, I had to recreate the connection string and the Dependency Injection (with the Context Factory and everything) in the host app to make the package work.
My problem is that I don't understand how Blazor's DI system works when I am building my own NuGet packages and I don't understand the flow of the dependency injections that are in Startup.cs versus what's in the NuGet package.
I just was a simple, reusable form and submittal component, with all of the EF and database logic built into it in the simplest way that I can drop into a dozen external projects.
What is the best way to build a NuGet package so that I don't need to do additional dependency injections in this situation? If I must do an additional entry into the host app's DI system, how do I make it as simple as possible?

Answer 1

When I create a library that has Injection. In my library I create a static class and create and extension method for IServiceCollection
public static class ServiceCollectionExtensions
{
public static void AddBlazorSyncServer(this IServiceCollection services)
{
services.AddScoped<ILogger, Logger<LoggingBroker>>();
services.AddScoped<ILoggingBroker, LoggingBroker>();
services.AddScoped<IDateTimeBroker, DateTimeBroker>();
services.AddTransient<ISyncDatabaseBroker, SyncDatabaseBroker>();
...
}
}
NOTE: In my example SyncDatabaseBroker is a DbContext :
public partial class SyncDatabaseBroker : DbContext, ISyncDatabaseBroker
This makes it a lot easier for the user to setup in their code base.
Databases have to be handled a little differently. When I want to manage migrations or share a connection strings I use this approach:
Program.cs (Library consuming server)
...
var migrationsAssembly = typeof(Program).Assembly.FullName;
builder.Services.AddDbContext<ApplicationDbContext>(
options => options.UseSqlServer(
connectionString,
dbOpts => dbOpts.MigrationsAssembly(migrationsAssembly)));
builder.Services.AddDbContext<SyncDatabaseBroker>(
options => options.UseSqlServer(
connectionString,
dbOpts => dbOpts.MigrationsAssembly(migrationsAssembly)));
...
builder.Services.AddBlazorSyncServer();
Console commands I can then use for the migrations:
Add-Migration InitialApplicationSchema -Context ApplicationDbContext -OutputDir Data/Migrations/Application
Add-Migration InitialSyncSchema -Context SyncDatabaseBroker -OutputDir Data/Migrations/Sync
Update-Database -Context ApplicationDbContext
Update-Database -Context SyncDatabaseBroker