I've got a webapp for containers running in Azure that I have working locally with a local appsettings file.
once I deploy to Azure, I want the container to pull appsettings values from the azure settings. These are set via AzureDevops and appear correctly when I check the portal.
However, the site is not pulling the appsettings values from Azure once deployed. It is using the ones from the file. I am using the double-underscore names as specified.
I have created a testcontroller to output the appsettings values. This is an a snippet of what the test view outputs:
Build version: 2019.1.23.1
Location: local
Database__DatabaseConnectionString: Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=application;Data Source=.
---
-------
Env vars: Key WEBSITE_AUTH_SIGNING_KEY Value ASDS*(&*&*(SDSD05C29
Key DOTNET_RUNNING_IN_CONTAINER Value true
Key WEBSITE_ROLE_INSTANCE_ID Value 0
Key Database__DatabaseConnectionString Value Server=tcp:servername01.database.windows.net,1433;Initial Catalog=application;Persist Security Info=False;User ID=applicationUser;Password=password;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Key APPSETTING_Database__DatabaseConnectionString Value Server=tcp:servername01.database.windows.net,1433;Initial Catalog=application;Persist Security Info=False;User ID=applicationUser;Password=password;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
As can be seen, the Database__DatabaseConnectionString should be consumed by the app. But it's not being.
What could be the problem here? This should be standard functionality according to the aspnetcore documentation.
Turns out this was a bug in the application. The controllers in question has an injected IOptions being injected into the constructor. Unfortunately, one of the controllers had different behaviour as a concrete instance was being inject in instead. As this object was not being correctly initialised in Startup.cs, this has the effect of passing empty values into the constructor.
Finally as empty values were found, this mean the default appsettings.json values were used.
Having fixed this above bug (by ensuring all controller use the same IOptions values), the azure appsettings values are being picked up and used correctly by the application at startup time.
Related
i upgraded my spring boot application to master pom 2.4 version and using cloud configs with the property enabled spring.cloud.bootstrap.enabled = true, I have db password encrypted in cloud properties so by the time i use the db properties i don't have my encryption framework available, so eventually my application failing with invalid username and password .."i have my own encryption service "
i am looking to see load the cloud config properties after i have my encryption service available, but the spring.cloud.bootstrap.enabled makes it load first on application startup, before i upgrade to master pom, i was not using spring.cloud.bootstrap.enabled so i didn't had any issue, with adding the property the order of loading changed, so i am running into an issue. Any help will be greatly appreciated. Thanks
so by the time i use the db properties i don't have my encryption
framework available
Use #DependsOn annotation in the bean that uses the db properties to depend on the encryption framework.
I have two projects targeted .net 6 and there are no any explicit declarations for using user secrets (I remember, it was required in previous versions to use AddUserSecrets()). Though, one project gets the right config from secrets.json, but another one - tries to get it from appsettings.json.
So, I'm wondering, what's the issue? How the behavior was changed in .net 6?
In .Net6, WebApplication.CreateBuilder initializes a new instance of the WebApplicationBuilder class with preconfigured defaults. The initialized WebApplicationBuilder (builder) provides default configuration and calls AddUserSecrets when the EnvironmentName is Development.
As long as you initialize your web application using the WebHost.CreateDefaultBuilder method, ASP.NET Core automatically picks up your configuration from the secrets.json file in .Net6. If you initialize your application manually or not .Net6, make sure to call the AddUserSecrets-method.
refer to this
According to microsoft blog the ASPNETCORE_ENVIRONMENT variable is loaded in order:
appsettings.json file
appsettings.{env.EnvironmentName}.json file
The local User Secrets File
Environment Variables
Command Line Arguments (or equivalently launchSettings.json)
and "The last key loaded wins".
Questions:
But how can the file appsettings.{env.EnvironmentName}.json be loaded before the final Environment is known?
Can it happen that I set 'Staging' environment through command-line and appSettings.Development.json is loaded because during step 2 it is not yet known?
There are two sets of configuration for an ASP.NET Core application:
The configuration for the WebHost.
The configuration for the application itself.
First the WebHost configuration is built (source):
_config = new ConfigurationBuilder()
.AddEnvironmentVariables(prefix: "ASPNETCORE_")
.Build();
As the source code shows, the configuration for the WebHost uses only environment variables and only those that are prefixed with ASPNETCORE_. One of those environment variables is, unsurprisingly, ASPNETCORE_ENVIRONMENT.
A little later down the line, an implementation of IHostingEnvironment is instantiated. This ends up using _config to retrieve a configuration setting named environment, which comes from the ASPNETCORE_ENVIRONMENT variable. If there is no such value, it defaults to Production.
Next up, the configuration for the application itself gets built. At step 2 in your question, the value of env.EnvironmentName is from the IHostingEnvironment I've already mentioned. If you were to set an environment value of e.g. Staging as a command-line argument, it would not change the value used in the WebHost configuration, as this applies only to the application configuration.
Andew Lock goes into more detail about how this all works and also demonstrates how to configure the WebHost to use additional configuration sources.
When I publish my .NET core app to a development IIS server, I make a call to the API and the method works fine locally. This method makes a Db call using a connection string stored in
appSettings.json as well as appSettings.Development.json
Observations:
- Yes, I have ASPNETCORE_ENVIRONMENT = Development and I have both an appSettings.json file AND appSettings.Development.json file
- So I started looking at the published files and I had BOTH of these json files in the published folder, even though appSettings.Development.json properties is set to "Build Action" = content and Copy to Output Directory = Do Not Copy
- If I comment out the code that his the Db, and return dummy data, and republish the api, i get the results fine with no complaints about "development mode"
Error I get when calling the API trying to hit the Db
Error.
An error occurred while processing your request.
Request ID:
0HLL1GOCEHH73:00000001
Development Mode
Swapping to the
Development environment displays detailed information about the error that occurred.
The Development environment shouldn't be enabled for deployed applications.
It can result in displaying sensitive information from exceptions to end users.
For local debugging, enable the
Development environment by setting the
ASPNETCORE_ENVIRONMENT environment variable to
Development
and restarting the app.
Questions:
- The Db connection strings are in both
[ update ]
Brain-fart! The db connection strings were using 'trusted', so no wonder they worked locally! Once I put in the credentials, and re-published, things worked like I expected. However, the error message threw me off.
Im still not sure why I have both of those appSettings files published? Which one will it use?
I am assuming your appsetting files are named as following:
appSettings.json
appSettings.dev.json
typically, you have to explicitly set the environment to dev. if you use Visual Studio for development, it sets an environment variable that tells the application to put it in dev mode.
Without seeing the initializing logic, I would say in prod it will use the appSettings.json.
Take a look at this article, it explains configuration in more details.
I have a web service. Its domain and port can be changed. So I want to read port and domain from file or db. When this information change, I update them in db or file.
Adapter XML:
<domain>${adp.hostname}</domain>
<port>${adp.port}</port>
worklight.properties:
adp.hostname=localhost
adp.port=10080
This is working fine. But I'd like to take adp.hostname and adp.port from file or db.
Something to remember about adapters is that you cannot change in real-time any of the properties set in the adapter XML once it is deployed.
Once the adapter is deployed, it is transformed into an object and is stored in memory. At this time, then, you can no longer interact with its "setup".
The only thing you can do, is to decide what will be the value of these properties before your deploy the adapter. For example, a different set of properties for QA/TEST/UAT/PROD environments...
To setup external properties, starting Worklight 6.0 and above, you can read this documentation topic: Configuring an IBM Worklight project in production by using JNDI environment entries
Specifically for Tomcat in its server.xml:
<Context docBase="app_context_path" path="/app_context_path">
<Environment name="publicWorkLightPort" override="false"
type="java.lang.String" value="9080"/>
</Context>
You change app_context_path to your project's context (project name)
You add environment child elements for each property you need
Important to remember: these properties must also exist in worklight.properties; those will be the default properties, and if using the above example they will be over-written and the environment properties will be used instead.
In the example above you can see that it will replace the default property publicWorkLightPort.