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?
Related
I'm trying to find all the locations in which a connectionString can be defined for an iis site (to write a script to extract them all).
I know it can be part of a web.config. I would like to have a complete list of files it can be configured in.
Does it make sense for it to be configured in the site code?
Which other configuration files can define a site's connectionStrings?
And a bonus question - how do I know the order of the files in which the connectionString is searched in ?
Thanks,
EDIT:
Additional info - all IIS sites are pure dotnet sites.
Also, specifying the general location of files, rather then file names, is also helpful.
E.g. - connectionStings can be located in external configuration files, whose location is defined at a in an appSettings element in the "%runtime install path%\config\machine.config" file.
Another option is to just link to the relevant docs.
My issue is that I haven't found anything conclusive.
As far as I know, there are several ways to configure connectionstring in ASP.NET applications.
Define it in code. This is the method used by many beginners. Because at this time they focus on code learning and logical understanding. But some people are accustomed to using it if the database is fixed, it does not need to be modified.
SqlConnection connection = new SqlConnection("Data Source=.\\SQLEXPRESS;Initial Catalog=mytest;Integrated Security=True");
Define it in web.config or App.config. The benefit of it is easy to modified connectionstring after publishing application. Developers can change web.config, no need to change code and deploy application again.
<connectionStrings>
<add name="mytest" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=mytest;Integrated Security=True;" providerName="System.Data.SqlClient" />
</connectionStrings>
Using External Configuration Files. ConnectionString is stored in a independent file for example connections.config. The benefit of it is modifying an external configuration file does not cause an application restart.
<?xml version='1.0' encoding='utf-8'?>
<configuration>
<connectionStrings configSource="connections.config"/>
</configuration>
About list all connectionstrings, you can use ConnectionStringSettingsCollection. It can get a connection by name and provider name.
I found a pretty good source for the locations of the IIS dotnet Framework configuration files - https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754617(v=ws.10)?redirectedfrom=MSDN#inheritance
You could define additional connectionStrings
In dotnet code.
In env.
In external config files.
For non-IIS scopes - such as user scopes and role scopes.
These 4 options are not specific to IIS.
I don't know where options (3) and (4) are defined, and I'm not sure if this list is complete. But by combing this list and the one in the doc, I think we have 99% coverage of defined 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
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.
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.
I'm looking for best practices to integrate log4net to SharePoint for web request, feature activation and all timer stuff.
I have several subprojects in my farm, and I would like to have only one Log4Net.config file.
[Edit]
Not only I need to configure log4net for the web application, which is easy to do (I use global.asax, and a log4net.config file, so I can modify log settings withtout reloading the webapp), but I also need to log asynchronous events:
Event Handler (like ItemAdded)
Timer Jobs
...
I implemented this recently and came up with a solution that worked for me.
Deploy your log4net config file to the 12 hive and the log4net dll into the GAC using a globally scoped solution. Then in your application code explicitly initialize log4net from the location of your global file. This allows you to log feature receiver, timer jobs and web application code.
[assembly: log4net.Config.XmlConfigurator(ConfigFile =
#"C:\Program Files\Common Files\Microsoft Shared\" +
#"Web Server Extensions\12\CONFIG\log4net.config", Watch = true)]
see here http://www.codeproject.com/KB/sharepoint/SharepointLog4Net.aspx
Firstly, you will need to modify the web.config where your SharePoint virtual directory resides. This is because you'll need to add SafeControl entries to trust the log4net assembly. You can update the web.config programmatically using the SPWebConfigModification class in a feature receiver. As you have to modify web.config anyway, you may want to consider including your log4net config inside and not set up an external log4net config.
However, if you'd still like to do this, it may work if you add the following to the web.config file:
<configuration ...>
...
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>
<log4net configSource="log4Net.config">
...
</configuration>
The log4net.config file should then be able to live alongside your web.config. As Nat says, you could deploy this file as a solution package.
Assuming you are attempting to run a minimal trust, you will need to update your Code Access Security file to include the log4net assemblies as well. All of your custom SharePoint code should then automatically use your log4net configuration.
You could release the config file as part of the solution package(s) to the 12 hive (use STSDev) to create any packages). This would give you a set location for the config and any changes to it can be released in a controlled manner (i.e. no need for manual editm, just roll back and re-install the solution).
I developed a log4net feature and packaged it in a wsp file. The feature receiver adds an httpmodule to the the web.config and the httpmodule loads the log4net.config from the layouts direcory when the application start event is raised in the http module.