I have a website (not web role) that I'm deploying to Azure, using the Basic tier. The web.config file has the following auto-generated section for website settings:
<applicationSettings>
<MySite.Web.Properties.Settings>
<setting name="MySetting" serializeAs="String">
<value>coolValue</value>
</setting>
</MySite.Web.Properties.Settings>
</applicationSettings>
I'm trying to override the value of MySetting in Azure's Web Apps -> MySite -> Configure -> app settings section. The idea being that the live website has a different value than the development version. I'm trying to avoid storing the live website's value in the web.config file (nor doing transforms).
I've tried the following values in the app settings section of the azure web app configuration section:
MySetting = somethingElse
MySite.Web.Properties.Settings.MySetting = somethingElse
Neither of these things worked. I like the new strongly-typed settings class in .NET, and don't really want to flatten the app settings out (using the old way).
Does anyone know how to override these types of settings in Azure?
Have you added the applicationSettings to the section group?
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="Tools.Instrumentation.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />
</sectionGroup>
</configSections>
One alternative is to set the App Settings from the Azure Portal. Go to the Azure Portal->Navigate to your website->Settings->App Settings and set the key, value pair there.
All settings will show up as environment variables, so you can set different values for the same settings in your test and production environments.
See here for more info:
http://azure.microsoft.com/blog/2013/07/17/windows-azure-web-sites-how-application-strings-and-connection-strings-work/
I asked around Microsoft's support & could not get an answer for this issue as I wanted to do this too. Fortunately while trying to better understand Microsoft's Web Deploy I discovered how to do this.
First, you'll need to use an external config file instead of just adding them into the web.config file. In your web.config file replace the following:
<applicationSettings>
<MySite.Web.Properties.Settings>
<setting name="MySetting" serializeAs="String">
<value>coolValue</value>
</setting>
</MySite.Web.Properties.Settings>
</applicationSettings>
Use an external configuration file like this instead:
<applicationSettings>
<MySite.Web.Properties.Settings configSource="BusinessLogic.config" />
</applicationSettings>
Also in your web.config file you will need to add the following to your configSections:
<configSections>
<sectionGroup name="applicationSettings">
<section name="MySite.Web.Properties.Settings" />
</sectionGroup>
</configSections>
You can read the MSDN article for more on this if need be.
In your BusinessLogic.config file, located in your root with your web.config file you would add your settings:
<MySite.Web.Properties.Settings>
<setting name="SecretPassword" serializeAs="String">
<value>1234567890abc!##</value>
</setting>
</MyApplication.Properties.Settings>
Now manually add this same BusinessLogic.config file to your site on Azure with the settings you want it to have in Azure.
Finally open up your .csproj file and look for the following XML configuration:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
Within there you can exclude files from deployment by adding a line like this:
<ExcludeFilesFromDeployment>BusinessLogic.config</ExcludeFilesFromDeployment>
If you need to exclude more files, you can separate them with a semicolon.
Now in my case when I commit all these files to my git repository, Azure will automatically grab them & put them in a temporary file where it will build the project and then deploy it to the folder where the website lives. Upon deploying it will notice to ignore the BusinessLogic.config file and the file you manually placed in Azure will be used instead.
Related
I am using NLog to write logs to my database,
I have created a file NLog.config which is writing logs to a text file as of now.
To write the logs to a database, I am following this tutorial.
However, the connectionstrings for diferrent environments can be only modified in Web.config. (I am using Azure App services). Is there any way I can refer the connection string from web.config in NLog.config.
TIA
If you not using ASP.NET Core (but "full" ASP.NET), you could use ${appsetting:name=..}
Install NLog.Extended with Nuget and use ${appsetting:name=..} in your config file.
e.g.
<target name="database"
type="Database"
connectionString="${appsetting:name=myConnectionString}" />
See also the ${appsetting} documentation
NB: It can only read <appSettings> and not <connectionStrings>
It is possible in Azure Web App to override web.config AppSettings section easily. E.g. if I have the following web.config:
<appSettings>
<add key="AllowedCORSOrigin" value="http://localhost:26674"/>
</appSettings>
I can override it in the app settings UI in the portal like that:
I have also a custom section in the web.config:
<AdWordsApi>
<add key="OAuth2RefreshToken" value="TOKEN" />
</AdWordsApi>
Is it possible to override it somehow as well? I have tried AdWordsApi.OAuth2RefreshToken and AdWordsApi:OAuth2RefreshToken, but that does not work that easily.
P.S. It's interesting to know if it's possible with other custom sections like e.g if I want another authentication mode on the server.
<system.web>
<authentication mode="None" />
</system.web>
Short answer is that it is not possible.
The mechanism you describes only works with App Settings and Connection Strings. High level, the way it works is:
Your Azure App Settings become environment variables
At runtime, a special module sets those dynamically in the .NET config system. Note that the physical web.config is never modified.
But it would be hard to make such mechanism work on arbitrary config sections, as those could not be dynamically affected without modifying the physical file.
If you are using Visual Studio use web.config transformations to change configuration settings depending on whether you are running locally or deploying to Azure:
How to Transform Web.config
In simple terms you create one more more build configurations (typically Debug & Release). In your Visual Studio solution right-click on your existing web.config file and click "Add Config Transform", this will create a Web.Debug.Config and Web.Release.Config file which you can then customise with specific settings depending on the environment. Link this with your Azure build configuration and you can then have any combination of settings for local and remote deployment.
This is old but leaving this reference to how to use Azure Resource Manager to potentially solve this.
You can transform the values by the listed in VSTS by doing the following steps in App.Release.config:-
Add xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform" in configuration section
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
</configuration>
Add xdt:Transform="Replace" in custom section like below
<AdWordsApi xdt:Transform="Replace">
<add key="OAuth2RefreshToken" value="TOKEN" />
</AdWordsApi>
Create variable token in the release pipeline e.g OAuth2RefreshToken
Then in file config use it as following
<AdWordsApi xdt:Transform="Replace">
<add key="OAuth2RefreshToken" value="#{OAuth2RefreshToken}#" />
</AdWordsApi>
If you are adding any in web.config --> Appsetting, you can overirde it in Azure App Service using variable prefix
Key Name: APPSETTING_AllowedCORSOrigin
Value: http://localhost:26674
https://learn.microsoft.com/en-us/azure/app-service/reference-app-settings?tabs=kudu%2Cdotnet#variable-prefixes
During the deploy to production we have to add a number of additional entries to the application's web.config, for example adding subkeys to system.identityModel/identityConfiguration/audienceUris, which is declared at the top of the web.config file as
<configSections>
<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection,
System.IdentityModel, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=B77A5C561934E089" />
</configSections>
In an ideal world we would do this using config transforms at build time, but we've made a design decision to use msdeploy parameters instead, which don't allow the injection of XML nodes in parameters (in spite of various posts that suggest you can). There are solutions that allow you to use both but we don't have time to integrate those into our deployment infrastructure right now.
Ideally we would achieve our end using appcmd to add nodes in the msdeploy post-sync task, but it seems that out of the box appcmd does not expose these custom sections unless you also declare them in applicationhost.config.
Is there a way to use appcmd or other tools to programmatically update applicationhost.config to add these declarations or do we just have to work with the XML directly?
I am using Service Bus in my project. I am referring Version 2.0.0.0 dll.
When I add following tag in my app.config everything works fine
<extensions>
<bindingExtensions>
<add name="netTcpRelayBinding"
type =
"Microsoft.ServiceBus.Configuration.NetTcpRelayBindingCollectionElement,
Microsoft.ServiceBus, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</bindingExtensions>
</extensions>
but as soon as I remove this tag, it gives following error
Configuration binding extension 'system.serviceModel/bindings/netTcpRelayBinding' could not be found.
Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.
Is it mandatory to provide this tag because on some other machine it is working fine without this tag.
This is required for WCF to be able to load this binding from the correct dll. There are cases where you can add this to other config files like machine.config and WCF will pick it from there and hence the app will work without having it in the app.config file.
I am trying to make my c++ ahadmin application compatible to IIS 7. My app needs to read the websites configuration (via metabase properties in IIS 6).
I read a lot of articles about the configuration paths and I think I have a good idea of how it work - however I am not sure of one thing:
To get to the configuration, I can either commit the MACHINE/WEBROOT/APPHOST/ path or the MACHINE/WEBROOT/APPHOST/Default Web Site.
I understand that the latter refers to the actual web.config of the specific website, and the former refers to the general applicationHost.config file, in which general settings are set.
My app doesn't know however whether a web.config file exists.
My question: if I want to get to this path - Object.ConfiguredObject.Site.Bindings, do I need to commit the APPHOST path or the APPHOST/Default Web Site path?
How do I know that in runtime?
You will always commit your bindings to MACHINE/WEBROOT/APPHOST.
You should go have a look at the schema files in:
%systemroot%\System32\inetsrv\config\schema
They will help you identify where settings should belong.
Update:
Per your comment:
So for example, AccessSSLFlags would
be mapped to
ConfigurationSection.AccessSection.SslFlags
- what section will I commit in that case? How do I know which section I
need to commit?
That all depends. IIS7 supports a mechanism called Feature Delegation. If a feature is delegated then this means a user can configure that feature in their local web.config. Some features are configured under system.webServer, others system.web.
What a user can and can't configure locally in his/her web.config is controlled by entries in two files:
%systemrooot%\system32\inetsrv\config\administration.config
%systemrooot%\system32\inetsrv\config\applicationHost.config
If you go and look at the IIS7 configuration schema in:
%systemroot%\System32\inetsrv\config\schema\IIS_schema.xml
What you'll find is that there are two main types of section:
system.applicationHost/xxxx
system.webServer/xxxx
Anything that is configurable under system.applicationHost is generally not considered a user modifiable configuration item. In fact if you open applicationHost.config you will see:
<sectionGroup name="system.applicationHost">
<section name="applicationPools" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
<section name="configHistory" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
<section name="customMetadata" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
<section name="listenerAdapters" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
<section name="log" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
<section name="serviceAutoStartProviders" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
<section name="sites" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
<section name="webLimits" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
</sectionGroup>
Notice the allowDefinition="AppHostOnly"? That's basically telling you that these settings can't be configured in web.config.
The scope of how feature delegation works is far too wide to cover in an answer so I suggest you read the article linked to above.
It sounds like you are trying to build a generic tool to manage configuration, and so you might want to consider to follow a similar pattern that IIS Manager follows; in short, it always tries to save configuration to the deepest path possible. What this means is that it will always Commit it to the place where it can, by looking at if the section is locked or not. It uses Managed code (Microsoft.Web.Administration), but you can access the same data from C++ using AppHostElement.GetMetadata("isLocked").
By the way if you are using C++, I would STRONGLY recommend using AHADMIN directly (and not WMI, or anything else), in particular IAppHostWritableAdminManager.
So the algorithm would be, set the CommitPath to the same value as the GetAdminSection configuration path specified. Then check for IsLocked, if it is then remove the last "path part" (trim starting the last '/'), and read again till you find the place where the section is unlocked. That is the deepest place where you can save it. Also, you will need to switch to MACHINE/WEBROOT at some point if it is a system.web section. IsLocked will respect things like Section Definition allow location, and other things that are required. If you want to make it bullet proof you would even need to check for attribute-level locking, but I think that is quite advanced.