We are migrating some of our on-site hosted web API to Azure app services. However, we aren't sure how to handle environment-specific configuration files on the Azure hosted apps.
What we do right now, in .NET Core, is include a directory of different JSON configuration files, each with the naming scheme:
myappname.SOMEMACHINENAME.json
Then, in the app startup, we load the appropriate file based on the machine that is running the app. This lets the app load an environment-appropriate configuration only knowing what machine it is running on.
Config = new ConfigurationBuilder()
.AddJsonFile(#"Configurations\myappname." +
Environment.MachineName +
".json", false)
.Build();
However, we're not sure how to accomplish something like this in the Azure app services world, where we do not know the machine name that the app will be running on. What is the best practice method of loading an environment-specific configuration at runtime with an Azure hosted app service?
Thanks for any help!
Edited to add .NET framework info.
Set the ASPNETCORE_ENVIRONMENT app setting to CustomConfig to the value matching appsettings.CustomConfig.json. Or, use a custom solution with a custom app setting. Either way, an app setting in the Azure Web App may be a good solution.
https://learn.microsoft.com/en-us/azure/app-service/configure-common#configure-app-settings
Related
We have a dotnet core 3.1 console application. It is deployed to on-premise Windows server. There is some sensitive information that we would like to keep in Azure Key Vault. However, instead of accessing Key Vault directly, we would like to access it via App Configuration service.
https://learn.microsoft.com/en-us/azure/architecture/solution-ideas/articles/appconfig-key-vault
Above article mentions that any application can use Azure App Configuration (under Potential use cases).
Does "any" include application hosted outside of Azure? If so, can you share high level steps on how to access App Configuration service from dotnet core app that is not running in Azure.
it seems that any means any, looks like the steps remains the same as long as the connection string to config services work, i'll do some testing with quick start material and let you know..
Best!
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.
I've created a .net Core 2 API and published it to the server.
The file structure looks very odd compared to a normal .Net MVC structure
Normal Structure I am familiar with
And this is the structure of the deployed .NET CORE 2 API
Now if I just try and convert that folder to an application like a normal ASP.NET app, it doesn't work.
I've installed the .NET Core Windows Server Hosting bundle on the server, but I'm still missing something.
Where do you add this code to enable IISIntegration ?
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.Build();
That code goes in Program.cs, but it's the default, so you should already be fine there.
The ASP.NET Core file structure is different than MVC 5, but it all pretty much works the same, once you've installed the .NET Core Hosting Runtime. You drop the published files in a directory on the web server. Then, you set up a site in IIS to use that directory. The only thing slightly different is that you need to edit the App Pool and set it to "No Managed Code", instead of a particular .NET runtime. Other than that, it should all just work.
That said, if your screenshot is a complete listing of the files, then you do seem to be missing some stuff. It's possible the publishing process failed at some point. Try to republish.
Background
The way ASP.NET Core works is fundamentally different than previous ASP.NET web applications. Whereas you used to have all the HTTP modules and such coming from the monolithic .NET Runtime installed on the machine, ASP.NET Core apps are completely self-contained. A Core app is in fact merely a console application. In an IIS setup, the actual web server is Kestrel, which either bundled into the Core app or available from the .NET Core runtime. IIS works as a reverse proxy. Handing off requests to Kestrel and then returning the responses it gets from Kestrel (hence the "No Managed Code"). With IIS deployment your app is a DLL, but it can also be entirely self-contained and deployed as an executable. The point is that, yes, the file structure and such is very different because it fundamentally works in a different way.
I am trying to minimize the cost of running my web app in Azure App Service. I have a Visual Studio 2017 solution with two Web Projects: Web and API (both .NET Core). The entire solution is part of a single GitHub Repo. Before adding the API project, the build and deployment to Azure App Service was automated. My goal is to deploy both projects under the same App Service (to minimize cost) with two subdomains (e.g. www.example.com and api.example.com) and keep everything automated.
Is this something that can be done? Can somebody please help me understand how this can be done? Can those settings be commited?
An Azure App Service Plan can contain multiple web apps. Normally when you use the Azure portal to connect it to source control, Kudu (the tool behind App Service Plans), will create a deployment script for that site.
In case you want to deploy two projects of a single solution (and git repo) to different Web Apps you have to do the following:
Create two web apps under the same App Service Plan
Connect both of them to the same git repo for automated deployments
Modify the deployment parameters
I'm going to suppose you know how to do the first two steps.
To modify the deployment parameters, you could either modify the deployment script by downloading it through Kudu and adapting it or, much simpler, configure it through the portal:
Go the App1 => Application Settings => Add setting PROJECT with value
<path>\<path-to-app1>.csproj
Go the App2 => Application Settings => Add setting PROJECT with value <path>\<path-to-app2>.csproj
Every time you push up a change, both web apps will receive an update, but they will deploy a different part to the web site.
More information can be found here (see last paragraph): https://github.com/projectkudu/kudu/wiki/Customizing-deployments
I have a wcf web service which could be deployed to azure or on-prem.
I am trying to have a common code base for both scenarios but with different web.config for each sceanrio.
The problem is that when the wcf service is deployed on azure it needs to talk to azure cache instance and if deployed on prem it will talk to windows app fabric cache server.
the code to talk to both remains the same because they are the same caching product essentially.
However - if the wcf service is going to talk to azure cache then the project should have a reference to the following assemblies:
Microsoft.ApplicationServer.Caching.Core.dll (1.0.4817.0)
Microsoft.WindowsFabric.Common.dll (1.0.5627.0)
Microsoft.ApplicationServer.Caching.Client.dll (1.0.4817.0)
Microsoft.WindowsFabric.Data.Common.dll
Microsoft.ApplicationServer.Caching.AzureCommon.dll
Microsoft.ApplicationServer.Caching.AzureClientHelper.dll
If the code has to talk to app fabric on prem then the following assemblies have to be referenced.
Microsoft.ApplicationServer.Caching.Core.dll (1.0.4632.0)
Microsoft.WindowsFabric.Common.dll (1.0.4619.0)
Microsoft.ApplicationServer.Caching.Client.dll (1.0.4632.0)
Microsoft.WindowsFabric.Data.Common.dll
I am looking for a solution so that I can keep the same code base (.cs files and .csproj) and with a configuration switch in web.config it should refer to the right assemblies,
for example if 'UseAzure = 1' in web.config then the azure cache client side dlls should be referenced and loaded and if 'UseAzure = 0' then AF on-Prem dlls should be loaded.
I am wondering if this is possible using run time C# code or via a visual studio pre/post build task.
I am open to any other ideas to acheive this.
Could someone confirm on the feasability of these two options and if so point me to some code which does something similar.