how to use services before app build in .net core 6.0

Question

I have earlier achieved this .net 3.1. But it couldn't be possible with .Net 6 because of startup.cs removed.

I have registered a few services,

builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var appSettings = builder.Configuration.GetSection("AppSettings").Get<AppSettings>();

  
builder.Services.AddScoped<IEncryption, Encryption>();

//Here I need to get the IEncryption Service, and call the method in this service to encrypt/decrypt the connection string to pass to DBContext Service.

builder.Services.AddDbContext<CatalogDbContext>(options => options.UseNpgsql(
                    appSettings.ConnectionString));

var app = builder.Build();

Earlier in .NET 3.1, I used BuildServicProvider() to get the Encryption service, and call the methods in that service to do the required logic then got the proper connection string I wanted that would be passed to the DBContext service on the next line.

Now, .NET 6/7 is forced to use the services only after app = builder.Build(); so, I can't register the DBCOntext after the build() method.

How can I solve this case? Any recommended approach to do this in .NET 6/7?

Answer 1

You still can useStartup.cs in .net 6

var builder = WebApplication.CreateBuilder(args);
var startup = new Startup(builder.Configuration);
startup.ConfigureServices(builder.Services); // calling ConfigureServices method
var app = builder.Build();
startup.Configure(app, builder.Environment); // calling Configure method

And then you can use ConfigureServices and Configure methods to register your services before building.

Answer 2

Important Caveat: In general, my suggestion below is a bad practice Do not call BuildServiceProvider

Why is bad? Calling BuildServiceProvider from application code results in more than one copy of singleton services being created which might result in incorrect application behavior.

Justification: I think it is safe to call BuildServiceProvider as long as you haven't registered any singletons before calling it. Admittedly not ideal, but it should work.

You can still callBuildServiceProvider() in .Net6:

builder.Services.AddScoped<IEncryption, Encryption>();
// create service provider
var provider = builder.Services.BuildServiceProvider();
var encryption = scope.ServiceProvider.GetService<IEncryptionService>();
// use service here

or alternatively

builder.Services.AddScoped<IEncryption, Encryption>();
var provider = builder.Services.BuildServiceProvider();
using (var scope = provider.CreateScope()) {
   var encryption = scope.ServiceProvider.GetService<IEncryptionService>();
   // use service here
}

Alternative: You can still use the classic startup structure in .Net6/7. We upgraded our .Net3.1 projects to .Net6 without having to rewrite/restructure the Startup()

Answer 3

You didn't need to use BuildServiceProvider in .NET Core 3.1 either. AddDbContext has an overload that provides access to an IServiceProvider instance :

builder.Services.AddDbContext<CatalogDbContext>((services,options) =>{ 
    var myOwnDecrypter=services.GetRequiredService<IMyOwnDecrypter>();
    var cns=myOwnDecrypter.Decrypt(appSettings.ConnectionString,key);
    options.UseNpgsql(cns);
});

or, if you use the ASP.NET Core Data Protection package :

builder.Services.AddDataProtection();
...
builder.Services.AddDbContext<CatalogDbContext>((services,options) =>{ 
    var protector = services.GetDataProtector("Contoso.Example.v2");
    var cns=protector.Unprotect(appSettings.ConnectionString);
    options.UseNpgsql(cns);
});

or, if IConfiguration.GetConnectionString is used :

builder.Services.AddDataProtection();
...
builder.Services.AddDbContext<CatalogDbContext>((services,options) =>{ 
    var conn_string=services.GetService<IConfiguration>()
                            .GetConnectionString("MyConnectionString");
    var protector = services.GetDataProtector("Contoso.Example.v2");
    var cns=protector.Unprotect(conn_string);
    options.UseNpgsql(cns);
});

That said, it's the configuration provider's job to decrypt encrypted settings, not the service/context's. ASP.NET Core's configuration allows using multiple different configuration sources in the same host, not just a single settings file. There's nothing special about appsettings.json. That's just the default settings file name.

• You can add another settings file with sensitive contents with AddJsonSettings. That file could use the file system's encryption, eg NTFS Encryption, to ensure it's only readable by the web app account
• You can read settings from a key management service, like Hashicorp, Azure Key Vault, Amazon Key Management etc.
• You can create your own provider that decrypts its input. The answers to this SO questino show how to do this and one of them inherits from JsonConfigurationProvider directly.