I have an ASP.NET Core application going on an have setup Github auto-deploy on it. But since it's an open repo I obviously don't want to upload my correct configuration file.
What I'd like to do is to replace some strings in the appsettings.json after a github auto deploy.
"AppSettings": {
"Token": "my super duper secret token"
}
How can I change my super duper secret token to my real token after a github deploy on Azure?
As I know we can config token in App Settings on the Azure port.
I do a test on this, it works successfully, the following is my detail steps.
Create an Asp.net core Application.
Add [AppSettings] section in the appsetting.json file (Token vaule: mysecretkey).
Add a public class AppSettings.cs under the created project.
Add the code services.Configure<AppSettings>(Configuration.GetSection("AppSettings")) in the function ConfigureService function in the Startup.cs file (For .net Core 1.0).
Note:The syntax for model binding has changed from RC1 to RC2. Using services.Configure<AppSettings>(Configuration.GetSection("AppSettings")), is no longer availableIn order to bind a settings class to your configuration you need to configure this in the ConfigureServices method of Startup.cs:
services.Configure<AppSettings>(options => Configuration.GetSection("AppSettings").Bind(options));
5. Add code to the HomeController.cs file.
Publish the WebApp to the Azure Portal.
Add [AppSettings: Token] in the Azure Portal.
Browse the WebApp and select the about tab to see the token value is that the value set in the portal.
Assuming the web site already exists as a resource in Azure, you can simply set the App Settings/Connection strings in the portal. These will override the ones in the appsettings.json file at runtime. Ie. your app will first look at the azure app settings/connection strings before looking for them in the local file. This is part of asp.net core's "cloud first" approach to configuration management. These settings wont get overwritten when you deploy code to the app/slot.
Found a blog post here which describes it in a bit more detail, using the .AddEnvironmentVariables() call to add azure slot settings to the configuration.
There is a code editing functionality in developer tools settings (Settings -> Development Tools -> App Service Editor (Preview)). You can go there and change any file you like in there. But you probably will need to restart the web application (by editing web.config or some other way).. You can also use Kudu (Advanced Tools) for that, but it's not as pleasant UI as Visual Studio Code in the first option.
Though the more advanced and correct way of dealing with application secrets is the special secret manager. You can read more about it on asp.net documentation here.
Generally it's a way to load the secrets from a protected data storage and override them with environmental variables in production (can be set in azure web app).
If you are using Azure DevOps Release to deploy, you can easily specify properties for each environment/stage.
You can use the task File Transform and indicate the path to appsettings.json:
Or if you are deploying directly to Azure:
So you just need to create the variables to override the data in the settings:
Related
I've made a new .NET 6 MVC application, installed 'Microsoft.ApplicationInsights.AspNetCore' and added builder.Services.AddApplicationInsightsTelemetry(); to Program.cs
Without an appsettings.json file no application insights information is logged, if I add an empty appsettings.json file logs do appear.
This seems an odd (undocumented?) requirement, is there something simple that I'm missing to avoid this?
We are handling config for app insights elsewhere and don't want to have to add an empty settings file just for this.
Thank you #Tiny Wang for your suggestion that helped lot.
The Application insights SDK for AspNetCore package Microsoft.ApplicationInsights.AspNetCore Package required the appsettings.json file.
When you inject your application insights to your ASP .NET core application the service.AddApplicationInsightsTelemetry() requires the appsettings.json file. The Application starts when the configuration values can be read from appsettings.json file.
Refer here for more information
its better to add the "APPLICATIONINSIGHTS_CONNECTION_STRING" key value pair in your Secrets.json instead of appsettings.json. secrets.json is local to your pc and will not be pushed to github or any scm.
The services.AddApplicationInsightsTelemetry(); will look for the key APPLICATIONINSIGHTS_CONNECTION_STRING at runtime in your configurations
read more about Secrets.json at https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows
I have a Xamarin.Forms app. As it does not have built in configuration file, I used a solution found here:
https://www.andrewhoefling.com/Blog/Post/xamarin-app-configuration-control-your-app-settings
and here
https://github.com/HoeflingSoftware/XamarinAppSettings
So now I have a custom appsettings.json file. The secrets in the file are replaced in AzureDevops pipeline. But how can I run the app from Visual Studio (on an emulator)? If it was a web application, I would use Manage User Secrets functionality, which would store the secrets in my file system. So it would be used automatically when the app is running during development. But how can I do it for a Xamarin.Forms app with its custom json file?
You could use the Replace Text in Source Files task on Marketplace to replace text in your source, before you build the project. You can then store the secret as a secure value in the pipeline variables library.
We use a similar approach to update the build versions for Xamarin Apps and for providing access to the Signing files.
I am having trouble getting the desired result from my CI/CD pipeline when deploying a .Net Core 2.0 web app to Azure.
As it stands everything is working when I deploy to my test environment. I have added a setting - ConnectionString:Main - to link to the correct database in the AppSettings section for the development app in the Azure portal.
I now want to deploy to my production environment. The issue is that there are two production databases, only one of which is "live" any any one time. What I would like to do is create two release definitions, one for each database and then have the ability to deploy using either one.
Is it possible to simply add a release variable that will override the local connection string in AppSettings.json as it was with previous .Net versions or is a more complex solution required?
You can use JSON variable substitution feature of Azure App Service Deploy task, for example, replace the value of ConnectionString in the sample below, you can define a release/environment variable as Data.DefaultConnection.ConnectionString in release definition.
{
"Data": {
"DefaultConnection": {
"ConnectionString": "Server=(localdb)\SQLEXPRESS;Database=MyDB;Trusted_Connection=True"
}
}
}
When using ASP.NET Core apps on Azure, the recommended way to store secrets is by using Azure Key Vault. This makes sure that no credentials are stored in version control or in VSTS.
If you really want to update a configuration value during deployment, you can tokenize your parameters and replace them during deployment. You can use this marketplace task for that. Managing Config for .NET Core Web App Deployments with Tokenizer and ReplaceTokens Tasks describes how to use these tasks.
You should be able to accomplish this by creating the deployment via ARM template and creating different parameters files for each environment. Using the template the relevant app settings can be replaced, which will inject them into the Azure portal Application Settings. These settings will override what is checked into your config file in the repo.
Currently I have my project connected to the database placed on Windows Azure, but I will be soon publishing my website for other people. When I'm making changes to my site, I often make changes to the database too. So during my work on my site, public webpage will not work.
How can I create local database which will be used locally, while testing and how can I automatically switch to this public db when my project is in Internet?
I use Asp.Net MVC5 with Entity Framework.
This is what Configurations are for in Visual Studio. You put your development connection string in your Web.config for development, and then in Web.Release.config, for example, you add a transform to change that connection string to the production version. Then, when you publish the site, you select the appropriate configuration, "Release" in this example, and the published Web.config will contain the production connection string. More information on configurations and using Web.config transforms can be found at MSDN.
I created an empty Azure Cloud Service project, then added a web role there. The role project has a web.config file.
When I hit F5 the role is deployed in Compute emulator. I went into the folder where role binaries are deployed - there's no web.config file there.
What's happening? Is that because I didn't set "copy always" on web.config file? What web.config does my role use?
If your role is configured for Full IIS mode (for those unaware of the difference between Hosted Web Core and Full IIS, see this blog post), the compute emulator should deploy the web role to IIS where it can be viewed in IIS Manager. On my machine (I'm running Azure SDK 1.5), the deployed web role's physical path is my source code directory.
I think web.config is compiled into your assembly as content in your development environment, and is not directly accessible like in staging/prod. You don't need to use Copy Always, if its marked as Content its all you need. You can use Environment.CurrentDirectory to see your web root path.
Even though the preferred way of storing configuration in Windows Azure applications is in the ServiceConfiguration.cscfg file, there are still many cases when you may want to use a normal .NET config file - especially when configuring .NET system components or reusable frameworks. In particular whenever you use Windows Azure diagnostics you need to configure the DiagnosticMonitorTraceListener in a .NET config file.
When you create your web role project, Visual Studio creates a web.config file for your .NET configuration. While your web application can access this information, your RoleEntryPoint code cannot-because it's not running as a part of your web site. As mentioned earlier, it runs under a process called WaIISHost.exe, so it expects its configuration to be in a file called WaIISHost.exe.config. Therefore, if you create a file with this name in the your web project and set the "Copy to Output Directory" property to "Copy Always" you'll find that the RoleEntryPoint can read this happily. This is one of the only cases I can think of where you'll have two .NET configuration files in the same project!
All info is from Azure Team Blog and I have used this solution successfully- http://blogs.msdn.com/b/windowsazure/