I don't put CSs in appsettings.json, by the way - CSs typically contain sensitive info and should instead be put in user secrets, env vars etc - something that doesn't end up in source control. If you deploy your app to something like Azure, then you use their management portal to house your settings, which is again more secure than in a file that your site could potentially be tricked into serving up to the world
You can get visual studio and to help you with all this. We also don't gerneally bother writing such low level SQL for basic things like "get a list of countries"
I made a project, I added a connected service of "on prem SQLS", conn str stored in user secrets, did the wizard to design the connection string:
It's in user secrets now:
Separately I actually connect to the database and form an EF context for it:
EFCPT is an extension that takes a lot of the pain of DB related work away
I choose the tables I want to work with. and options like wher eto put classes generated from them:
I'm nearly ready to go, I just need to register to use this ScratchContext (DB name is "Scratch")
In Blazor server we don't inject contexts, because they become too long lived for boring technical reasons I won't cover. Instead we inject context factories and manufacture contexts when we want one
For this to work we have to tell the IoC what to inject, and we do this in program.cs:
builder.Services.AddDbContextFactory<ScratchContext>(optionsBuilder =>
{
var cs = builder.Configuration.GetConnectionString("ConnectionStrings:Local");
optionsBuilder.UseSqlServer(connectionString: cs); //if you used MySQL etc this line would look different
});
Then in some Blazor page, or service, whatever, we inject that thing:
//in some page that has a separate codebehind
class SomePage:ComponentBase
{
[Inject]
IDbContextFactory<ScratchContext> contextFactory;
}
//in some page that has no codebehind
@inject IDbContextFactory<ScratchContext> ContextFactory
//in some normal class constructor that is a service or whatever
class MyService
{
IDbContextFactory<ScratchContext> _contextFactory;
public MyService(IDbContextFactory<ScratchContext> contextFactory)
{
_contextFactory = contextFactory;
}
When we want to run a query:
async Task GetAllCountriesClick()
{
var context = _contextFactory.CreateContext();
var countriesList = context.Countries.Where(c => c.Language == "ENglish").OrderBy("c => c.TimeZoneOffset).ToListAsync();
}
----
If you really want to carry on with ADO and passing connectionstrings, just inject an IConfiguration and call
.GetConnectionString("Your_Conn_Str_Name_In_User_Secrets_Here");
. Microsoft DI already knows how to provide IConfiguration; you don't need to register it
If youre not using DI, eg if youre using a console app, you might want to build your configurator and tell it all the places to search to get config; later items overwrite earlier items so...
_config = new ConfigurationBuilder()
.SetBasePath(AppDomain.CurrentDomain.BaseDirectory)
.AddJsonFile("appsettings.json")
.AddUserSecrets<Program>()
.AddANythingElseYouWantToGetConfigFromLikeEnvVarsEtc()
.Build();
Here items in User Secrets displace items in app settings etc..
And again call it like before
_config.GetConnectionString("...")