I have some important settings in the machine.config file and I need to prevent that websites can modify them in thier web.config files. In other words, I need those setting in the web.config files to be ignored.
I know I can lock elements but I don't want to have an exception, I just want to be ignored.
Example:
In machine.config
<appSettings>
<add key="a" value="AAAA"/>
</appSettings>
In web.config
<appSettings>
<add key="a" value="BBBB"/>
</appSettings>
In a website or webapplication
ConfigurationManager.AppSettings["a"] // returns "AAAA" from machine.config
Is it possible to do this?
Clarification:
These settings that I need to protect are the wcf serviceModel client elements and not appSettings as my example.
Related
I'd like to transform the appsettings section of my local web.config file from a bunch of individual settings for my local dev work, to a configSource file path attribute for publishing to client servers.
Basically from this:
<appSettings>
<add key="setting1" value="devVal1"></add>
<add key="setting2" value="devVal2"></add>
<add key="setting3" value="devVal3"></add>
</appSettings>
to this:
<appSettings configSource="clientSettings.config" />
This partial solution adds the configSource attribute.
<appSettings xdt:Transform="SetAttributes(configSource)" configSource="clientSettings.config"/>
But I'm not sure how to remove all the individual settings as well (I think the configSource will override them anyway, but I'd prefer to not have them there at all, to avoid having irrelevant dev settings in each of my client's web.config files)
A bit more perseverance lead me to the answer. Apply the "RemoveAll" transform to an add element within the appSetting.
<appSettings xdt:Transform="SetAttributes(configSource)" configSource="clientSettings.config">
<add xdt:Transform="RemoveAll"/>
</appSetting>
Hope this is of use to someone in the future (if only as an example of why you should do 30 minutes of extra work before reaching for the 'Ask Question' button)...
This answer to another question states:
Do not forget to clear the connectionStrings first:
<connectionStrings>
<clear />
<add name="LocalSqlServer" connectionString="Data Source=(local);Initial Catalog=aspnetdb;Integrated Security=True" providerName="System.Data.SqlClient"/>
</connectionStrings>
... interesting. What does that do?
In .Net config files are inherited, so your applications config will inherit settings from your machines config.
The <clear/> tag will remove any inherited connection strings and thereby avoids confusion and potential problems.
In ASP.Net you may have several inherited connection strings, so this is very common there.
The element removes all sections and section groups from your application that were defined earlier in the current configuration file or at a higher level in the configuration file hierarchy.
http://msdn.microsoft.com/en-us/library/aa903345(v=vs.71).aspx
so for example, if this was a child config file and the parent config file had some settings... you may not want them being inherited so you specify the clear flag to clear it and then use your settings.
In trying to speed up my ASP.Net development build times, I changed my "global" web.config file (C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config) as follows
<system.web>
...
<compilation batch="false">
That really sped up the first page access of my site after doing a build.
What surprises me is that our site's web.config has
<compilation batch="true">
but the global setting is the one that seems to be in effect. I would expect that the site web.config would override the global web.config. Is that not the case?
Global web.config doesn't override site web.config.
try this: set in global web.config
<appSettings>
<add key="TruncLongText-Size" value="150"/>
and in local web.config
<appSettings>
<add key="TruncLongText-Size" value="150"/>
then prompt the result in a page.
What do you see?
We can configure the settings for the webpages in a particular folder by keeping single web.config. Can there be multiple web.config in a same hierarchy as i saw some where web.config.debug and web.config.release and web.config. Why they are intended for.
Those are web.config transformations, which allow you to apply changes to different builds of your project (debug, dev, release, etc).
The ones suffixed with .debug, .release, etc, are the transformation files. They take the base web.config and modify it using the XML-Document-Transform attributes you specify.
A classic use case is the debug=true attribute, which you never want to use in production. You can use a simple transformation to remove it in your web.config.release file:
Web.config
<configuration>
<compilation debug="true" />
</configuration>
Web.config.release
<configuration>
<compilation xdt:Transform="RemoveAttributes(debug)" />
</configuration>
I want to know what best practice is for accessing settings
in config file when you have dev/test/production types.
If you have different config for each type when you
publish a ASP.NET website doesn't the config get copied as well??
Malcolm
We usually manually inject the settings file on each site. I think that it's uncommon, though not unheard of, to actually rely on VS to publish to your production site. Source control has dev/test/prod/ etc. web.config files.
ConfigurationManager.AppSettings ?
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.appsettings.aspx
In Visual Studio 2010 you can maintain Multiple Web.Config and use a transformation to generate the correct Configuration for an environment.
http://blogs.msdn.com/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
Basically we can make have one default Web.Config and different Transformation files for each environment e.g.
Web.Debug.Config
Web.Staging.Config
Web.Production.Config
The Transformation file can override the value of a particular config item for the environment e.g.
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="personalDB"
connectionString="Server=StagingBox; Database=personal; User Id=admin; password=StagingPersonalPassword"
providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)" />
<add name="professionalDB"
connectionString="Server=StagingBox; Database=professional; User Id=professional; password=StagingProfessionalPassword"
providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)"/>
</connectionStrings>
</configuration>
Whenever we target build for that environment the Transformation are applied to the default Web.Config file.