I am working with a asp.net core project which will have 2 environments that I deploy to a single server, staging and production. My aim is to make staging use the appsetting.json file instead of window environment variable.
I have set up a environment variable on the server.
Environment variable
In my appsettings.json file, I have the process setting with a different value.
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"Process": "Not ABC"
}
This is the code to retrieve it in my project.
string process = _config.GetValue<string>("Process");
Issue is both staging and production are on the same server meaning they using the same environment system variable. Both situations, the enviroment variable overrides the one in appsettings.json.
I want staging to use the appsettings.json. Is there a way to do this?
I tried looking over the internet and can't find any solution.
Leveraging the information from documentation: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0
I propose the following:
Create app settings for both production and Staging.
Create two releases, one for staging and one for production.
In the production configuration file, omit the values you want to load from environment variables.
Add the environment provider first and the app setting one second
In the Staging app config, add your values.
This way, the Staging value will come from the app settings file and the production from the environment variable.
Related
In Azure Functions you use host.json to configure logging. However, the logging options/sections are unclear to me. Can someone help?
Per this: https://learn.microsoft.com/en-us/azure/azure-functions/functions-host-json
"logging": {
// FILE CONFIG?
"fileLoggingMode": "debugOnly"
"logLevel": {
"Function.MyFunction": "Information", // where is this log?
"default": "None"
},
// INSIGHTS CONFIG
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes" : "Dependency;Event",
"includedTypes" : "PageView;Trace"
},
Is the FILE CONFIG section used for logging in "log stream"? or is the INSIGHT section?
What is 'default' vs 'Function" log level?
I assume Filesystem logs is what controlled via FILE CONFIG section, correct?
What configuration is used for "Monitor" section of Azure Functions?, is it FILE CONFIG?
if so, If I wanted to see only errors under "Monitor" section would I set Function.MyFunction": "Error" or "default"?
FileLoggingMode is used to generate the logs in azure portal or in a local Environment. The different modes in “fileLoggingMode” are
“debugOnly”: This level will generate logs when the function app is running on Azure Portal. This is the default mode.
“always”: This mode is used to generate logs in local environment as well as when running on Azure Portal. This code reference can be helpful to understand it better.
“never”: This mode does not generate any logs.
When the “fileLoggingMode” is set to “always” the log file generated when running in local environment is stored in “C:\Users{user}\AppData\Local\Temp\LogFiles\Application\Functions\Function{Function_Name}”, the path can be referenced here in the Host Settings code. If you are running the function app as docker/container in your local premises you can change the path by updating the host configuration code.
The fileLoggingMode is still in issue see here
Default Vs Function log is both are same level check the below json
In a logging loglevel we have Parameters default/function/… we where mention the Which type of log can we need to get like (error, information, trace, ….)
{
"logging": {
"fileLoggingMode": "always",
"logLevel": {
"default": "Information",
"Function": "Error"
}
}
}
Refer: Configure monitoring for Azure Functions | Microsoft Docs
In a default it get the log information of what you added in a parameter (host.json). If you are using "default": "Error" you will get the Error logs by default.
If you are using below configuration by default it will get the Information Log and Funcition get the Error log.
"default": "Information",
"Function": "Error"
So when generating a new .NET Core web project there is an appSettings.json and appSettings.Development.json for configuration parts. By default, those are not ignored by the .gitignore file so I think they should stay in the repository.
I'm using a database and want to store my connection string to those files. Obviously the parameters contain sensitive information and shouldn't be in the repository. If the environment is the development I can add the local connection string to the appSettings.Development.json (but then every developer would have to use the same settings until I add the dev file to the .gitignore)
"Database": {
"Server": "localhost",
"Port": 5432,
"UserId": "admin",
"Password": "admin",
"Name": "myDb"
}
How can I set-up the appSettings.json for production or other purposes? Is there a way for something like
"Database": {
"Server": "$DB_SERVER",
"Port": "$DB_PORT",
"UserId": "$DB_USER_ID",
"Password": "$DB_PASSWORD",
"Name": "$DB_NAME"
}
and those placeholders would be replaced with the values from the environment variables?
If you include any sort of sensitive information (like production connection strings) in source control they are usually considered compromised.
You have two options:
First option wopuld be to go for appsettings file override values. It is supported by all the established CI/CD tools. That step usually happen in the release pipeline right before you deploy.In this scenario you store your values encrypted in the CD tool.
Second option is to use Environment variables. In this case for development purposes you can just pass this variables in the launchSettings.json file. And you set the values of your environment variables in the server running your application.
If you want to use Environment variables you do not need place holders in appsettings file. You can read them directly
Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT ")
Use secret
They save in a local file the configuration, so they aren't on repository.
When you go in production, you save this information in environment variable.
In visual studio on Project, select Manage user secret and add your connection
{
"ConnectionStrings": {
"MyConnection": "the connection"
}
in startup use IConfiguration
configuration.GetConnectionString("MyConnection")
and at production, in EnvironmentVariable of server, you save a new EnvironmentVariable
ConnectionStrings:MyConnection
So only administrator know the connection.
If you use Azure, you could use Azure key vault.
I would like to ask if there is a way to tell ASP.NET Core 2 to choose different connection strings.
It is quite annoying to keep changing the connection string in the appsettings.json file every time I publish my website to the hosting server..
I am using this code to get connection string.
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration["Data:WebDataBase:ConnectionString"]));
Maybe there is an easy way but I am thinking of using an if statement in my Startup.cs:
if (local) {
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration["Data:WebDataBase1:ConnectionString"]));
}
else {
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration["Data:WebDataBase2:ConnectionString"]));
}
But how can I set this local variable whether the server is my local computer or a live hosting server?
"Data": {
"WebDataBase1": {
"ConnectionString": "Data Source=DatasoruceName;Initial Catalog=DBname;Trusted_Connection=True;Integrated Security=True;"
},
"WebDataBase2": {
"ConnectionString": "Data Source=DatasoruceName;Initial Catalog=DatabaseName;Trusted_Connection=True;Integrated Security=True;"
}
}
Environment specific configuration is not supposed to be specified within code. ASP.NET Core has a mechanism for that which allows you to swap out the configuration dependending on what environment you run on.
While developing your application, you usually run in the Development environment. When you are deploying your application for production, the Production environment is used by default. But if you have other environments, you can totally make up new names for those too and have specific configurations for them. That all is explained in the Environments chapter of the documentation
What environments allow you to do is create multiple appsettings.json files. The ASP.NET Core by default comes with two files: appsettings.json and appsettings.Development.json.
The former is supposed to contain environment unspecific configuration; things that apply to all environments. The latter file contains development-specific configuration and for example adjusts the logging level so that you get more information during development. You can also use these files to specify a default connection string within appsettings.json and overwrite that for development within appsettings.Development.json.
Furthermore, the configuration file follows a very simple pattern: appsettings.<Environment>.json. So if you run in the Production environment, a file named appsettings.Production.json will be loaded if it exists. This mechanism allows you to configure all your environments differently without having to resort to detections within your code.
In addition, there is also the concept of user secrets during development. These are for development-specific configurations that do only apply to yourself but not for example to other members of your team. This is basically a per-machine configuration that allows you to overwrite both the appsettings.json and the appsettings.Development.json. This is described in the user secrets chapter.
Best practice is to avoid connection strings altogether within configuration files though, since you want to avoid that people that happen to have access to your configuration files (for example through your source code) can know the passwords to your database. In that case you can use other mechanisms, for example environment variables that are local to the process.
In your case, where you are just using integrated security, and as such rely on the credentials of the current user, this is not that much of a problem. The only thing you are leaking is the database name. – So you can definitely start out with putting the connection strings into the appsettings files.
So for example, this is how you would configure your database context within your Startup’s ConfigureServices:
services.AddDbContext<AppIdentityDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("WebDataBase"));
Your appsettings.Development.json would look like this:
{
"ConnectionStrings": {
"WebDataBase": "Data Source=DatasourceName;Initial Catalog=DBname;Trusted_Connection=True;Integrated Security=True;"
}
}
And your appsettings.Production.json would look like this:
{
"ConnectionStrings": {
"WebDataBase": "Data Source=DatasourceName;Initial Catalog=DatabaseName;Trusted_Connection=True;Integrated Security=True;"
}
}
I am a new web developer and am trying to host a test site with Azure test services.
I can see the test site(you can access this to test ) at: http://kencast20160830102548.azurewebsites.net/
However, if you go to the Services -> Fazzt --> Equipment and Applications pages, I get this error:
Error.
An error occurred while processing your request.
Development Mode
Swapping to Development environment will display more detailed information about the error that occurred.
Development environment should not be enabled in deployed applications, as it can result in sensitive information from exceptions being displayed to end users. For local debugging, development environment can be enabled by setting the ASPNETCORE_ENVIRONMENT environment variable toDevelopment, and restarting the application."
These pages are relying on a SQL database, so I think this is where the problem is.
I've been trying to follow along with the directions published here: https://docs.asp.net/en/latest/tutorials/publish-to-azure-webapp-using-vs.html
however I cannot find the "Configure SQL Database" pop-up box when logged into my Microsoft Azure account.
The directions do not seem to go along with what exists in Azure.
Update- 8/31/2016
I have researched and learned a bit more:
I have one project with two DBContexts.
When I publish to Azure, it publishes tables from ApplicationDBContext but not the tables from MyCompanyContext. I can verify using SQL Server Object Explorer.
I can see my local connection strings in appsettings.json file for both ApplicationDB and MyCompanyDB. Here is the code from appsettings.json:
{
"ConnectionStrings": {
"DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=aspnet-MyCompany-3097a012-5e00-4c25-ad83-2730b4d73b4b;Trusted_Connection=True;MultipleActiveResultSets=true"
},
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
},
"Data": {
"MyCompanyContext": {
"ConnectionString": "Server=(localdb)\\mssqllocaldb;Database=MyCompanyContext-f9de2588-77e8-41dd-abb3-84341610b31a;Trusted_Connection=True;MultipleActiveResultSets=true"
}
}
}
However, when I look at the "SQL Server Object Explorer" window, I see that the database hosted on Azure, mycompanydb.database.windows.net(SQL Server 11.0.9231 -mycompanydb, MyCompany_db) only has the tables from the "DefaultConnection" database, and nothing from "MyCompanyContext".
How do I get the tables from the second database (MYCompanyContext) to Azure?
I have been studying this Stack Overflow response, but it uses Enable-Migration in the PMC. When I do that, I get an error that enable-migrations is obsolete.
Locally, I have always done migrations with this:
add-migrations -c MyCompanyContext
Any help you could give me would be greatly appreciated.
Thanks!
From the comments, I am guessing you need to ensure both your contexts are applied in the startup class like this
services.AddEntityFramework().AddSqlServer()
.AddDbContext<MyCompanyContext>(options => options.UseSqlServer(Configuration.Get("Data:SQL")))
.AddDbContext< ApplicationDBContext >(options => options.UseSqlServer(Configuration.Get("Data:SQL")));
the above assumes two things:
1) you have the connection string set up like this in your appsettings.json
"Data": {
"SQL": "Server=tcp:yourDbServer.database.windows.net,1433;Initial Catalog=yourDb;Persist Security Info=False;User ID=youId;Password=YourPswd;MultipleActiveResultSets=True;TrustServerCertificate=False;Connection Timeout=30;",
}
2) Both the contexts share the same Db, if not then substitute the appropriate connection string (make sure to have it matched to the way you have it in your appsettings.json) for the context like this sample:
.AddDbContext<MyCompanyContext>(options => options.UseSqlServer(Configuration.Get("Data:SQL2")));
Where should the production and staging connection strings be stored in an ASP.NET Core application, when deploying into IIS 7 (not Azure) ?
I am looking for the recommended way of doing it / best-practice, especially security-wise.
In ASP.NET 5 it's possible to specify multiple configuration sources. Thanks to this welcoming change to previous model you can store your development connection string in simple json file, and your staging and production connection string in environment variables directly on the respective servers.
If you configure your app like this :
var config = new Configuration()
.AddJsonFile("config.json")
.AddEnvironmentVariables();
and there is connection string in both config.json and environment variable then environment source will win.
So, store your development connection string in config.json(and freely check in in source control) and production one in environment variable. More info here and here.