I have an <applicationSettings> tag in my web.config file which contains <connectionString> and other settings related to the application.
I want to ask If I want to add some more settings to the <applicationSettings> section. How can I do that?
Is it possible to edit/add tags in the <applicationSettings> section of the web.config file?
You mean at runtime? When the application is published? Sometime else? The config file can be edited within Visual Studio.. or even just good ol' notepad. You can definitely edit it, you just need to follow the appropriate XML structure provided, meaning appsetting keys use a NameValueCollection - http://msdn.microsoft.com/en-us/library/vstudio/ms228154(v=vs.100).aspx
Related
There are 3 environments through which my .Net web application goes namely Development, Release and Production with each having their own config and project setting files.
Assuming that the setting and config files for different environments are in one system, I want to create a small script or an application where the developer just mentions the environment type and the related setting and config files get loaded and then the application builds.
Can anyone guide me on this?
You can create config transforms and use them in publish profiles. For each configuration (Debug, Release, YourOwnConfig ...) there will be a file named by its configuration (Web.Debug.config, Web.Release.Config, Web.YourOwn.Config, ...)
The trick is that you have one complete config file, the original Web.Config, and the transforms just mention the differences to this file via XSLT transform syntax (once you create a new transform, there will be some examples in the file itself showing the syntax). For example, adding a transform for an appSettings key looks like:
<configuration>
<appSettings>
<add key="ClientSessionTimeout" value="100"
xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />
</appSettings>
</configuration>
That example will replace an existing ClientSessionTimeout setting by the one specified (with value="100"). Notice how the xdt:locator specifies that the key attribute will be used to localize the setting, and xdt:Transform specifies that the attributes mentioned (here: value) will be set.
If you have applicationSettings, you need to replace the setting itself:
<applicationSettings>
<WebApplication2.Properties.Settings>
<setting name="Setting" serializeAs="String"
xdt:Transform="Replace" xdt:Locator="Match(key)">
<value>Some value</value>
</setting>
</WebApplication2.Properties.Settings>
</applicationSettings>
The differences will be for example the data source settings, other environment specific settings such as URLs to web services etc.
To create those, select a configuration such as "Debug", then right-click on the Web.Config file and you will see a context menu item "Add config transform" - click it and the Web.Debug.Config transform file will be created underneath the Web.Config. Adapt it as mentioned before; copy the entire key or setting to the transform file, then add the appropriate xdt attributes as shown above.
Finally, you can use the "Publish" function (Right-Click on the web prroject to select it). A wizard opens where you can set up a publish profile. There you can mention a configuration - like "Debug", "Release", and the ones you've created earlier.
A file publish will put the files together needed to deploy the web project and additionally perform the transformation of the Web.Config by applying the appropriate transform file (e.g. Web.Release.Config). The published config will be named "Web.Config" and contains all changes.
For trouble-shooting, and to find out more about the topic, I recommend the following links:
asp net web application: add config transform grayed out
web.config transform not working
Notice also the side-bar of Stack overflow showing more related links.
Consider a group of developers working on an ASP.net web application. Each developer would like to have a private version of the web.config.
By "private" I mean that a developer can freely change the file to suit their dev/test needs at any given moment, without it affecting other team members and without ending up in source control.
How can one go about achieving this with Visual Studio 2015?
My closest solution so far is to have a "private" Solution Configuration with a matching Web.config Transformation file ("web.private.config") that's excluded from source control.
But this is not a satisfactory solution because:
a. The transformation is not run automatically when debugging (with F5). The developers need to remember to run it manually.
b. The result of the transformation ends up in the main "web.config" file which is, naturally, included in source control.
We had a very similar problem but only needed personalized versions of the <appSettings> section in Web.config.
In this situation the inclusion of an external file through configSource turned out to be problematic, as this attribute completely replaces the <appSettings>-node. So there remains no way to keep global key/values AND personal key/values for all developers. The whole section is completely replaced by the included private file.
What we need is both global and private <appSettings>. The solution we found was the file attribute. It allows to merge Web.config settings with settings from an additional file.
We ended up with a construct like this one:
<!-- Web.config with global appSettings) -->
...
<appSettings file="Web.PERSONAL.config">
<add key="BaseUrl" value="https://projectname.dev.local" />
...
</appSettings>
...
<!-- Web.PERSONAL.config with personal appSettings -->
<?xml version="1.0" encoding="utf-8"?>
<appSettings >
<add key="EmailSmtpUser" value="my.name#my.domain.com" />
<add key="EmailSmtpPwd" value="***" />
</appSettings >
If you put identical keys in both files, the Web.PERSONAL.config version will overwrite the Web.config version.
The file Web.PERSONAL.config must be excluded from Git through .gitignore .
Keep in mind:
While configSource works for ALL nodes in Web.config, the file attribute is restricted to <appSettings>.
Have web.config include an external file (via configSource) and add that file to .gitignore
The correct answer is to host your local development site in a separate location from your Visual Studio solution. You can then use publish profiles to publish changes to that location and web.config transforms to maintain a separate local config for each developer. Each developer would use a different publish profile which transforms the web.config with their own transform and deploys the transformed web.config to the publish location. You can then attach a debugger to the published site using Visual Studio's Debug > Attach To Process option.
I think there is a lot of value in standardising dev environments so that one can just download the solution and run it.
Custom, long term/permanent, developer specific configs will sooner or later lead to a subtle bug that will be tricky to find.
My solution to your problem would be to find out the reason(s) why permanent individual configs are needed and have a look if these environment specific differences can be eliminated.
I have an ASP.NET MVC5 website in development which I will shortly need to deploy to an IIS8 webserver. I'm trying to get the security model for the web.config file right, and in particular I want to:
Prevent secrets in the web.config file being exposed in my source control system
Protect the deployed web.config from prying eyes (I don't own the server).
From searching on SO and other sites I can see that there are specific tools/techniques to address each scenario:
'Included' sections in web.config that do not get saved to the SCCS.
Encrypted web.config files. Or encrypted sections of the file to be more precise.
I'm fine with both of those, but I can not for the life of me see how to combine the two techniques to solve both problems simultaneously. Is it possible to encrypt an external section? Is this even the right approach given that many of the answers are several years old now and address older versions of ASP.NET/MVC.
I can't be the first do want to do this so I'm sure I'm missing something obvious.
It has been suggested that this might already be answered here, however that question is about encrypting sections in the main web.config file, and I am asking about encrypting external sections. By that I mean sections that are 'included' using the configSource XML attribute.
It's probably bad form to answer ones own question, but I had a flash of inspiration and after a couple of hours of experimentation I have it working how I want.
The bit I had got all wrong was that I was trying to encrypt the external files. It does not work like that. Here's how it does work, at least, this is how it works for me on an IIS8.5 and ASP.NET v4.0.30319 server.
ConnectionStrings
Create the connectionStrings section in a separate file, e.g. Web.connectionStrings.config:
<?xml version="1.0"?>
<connectionStrings>
<add name="MyConnection" connectionString="{your connection string here}"
providerName="System.Data.SqlClient" />
</connectionStrings>
Ref this file from web.config:
<connectionStrings configSource="Web.connectionStrings.config" />
Make sure the external file is not under source code control so it does not get uploaded to your SCCS.
Deploy BOTH files, either as part of your deployment process or deploy the secure file manually if you're really paranoid.
Encrypt the connectionStrings section of the web.config normally, using the aspnet_regiis.exe command mentioned in the article mentioned by Afzaal. This process actually encrypts the contents of the Web.connectionStrings.config file and leaves the web.config file unchanged. You need to leave the external file in place but as it is now encrypted this is quite safe.
appSettings
Create your security-critical settings in a separate file, e.g. Web.appSettings.config.
<?xml version="1.0"?>
<appSettings>
<add key="wc1" value="web.app.config1" />
<add key="wc2" value="web.app.config2" />
</appSettings>
Ref this file from web.config:
<appSettings file="Web.App.config">
{other non-secure appSettings}
</appSettings>
Again, ensure the secure file is not under source control, and deploy both files to the production server.
Encrypt the appSettings section of the web.config file.
Unlike the connectionStrings section, this does not alter the external file at all. Instead, settings from both web.config and the external file are merged (external file takes precedence if duplicate keys are encountered) and are stored in an encrypted form in web.config.
At this point you can remove the Web.appSettings.config file as its contents are now incorporated into the main file.
Points to note:
If you introduce another Web.appSettings.config file at a later time, and restart the site, the contents of that file will override the encrypted settings in web.config. This may or may not be useful. When you remove the file and restart the site, the settings revert to the encrypted ones again.
If you decrypt the appSettings section, ALL the current settings are written back into the main web.config file, including those that originally came from the external file. You'll need to remember to remove them if you're just changing a setting and then re-encrypting the file again.
I'm having some trouble with a current project. I have a Solution with 2 separate projects in it. The first is my Project that I am publishing, which has a web.config file. The second is a data access project, which only contains .cs files, and has an app.config file, as well as a Properties folder containing a Settings.settings file.
Like so:
Solution
DataProject
app.config
Settings.settings
Code.cs
PublishProject
Code Files
Web.config
My Problem is that I want to be able to edit the app.config file settings after the solution has been published, but the app.config file gets rolled into a DataProject.dll that sits in the bin folder in PublishProject. Because of this I cannot access the app.config file to edit it post-publishing.
I have tried to setup the app.config file as a linked file that just points to the Web.config file in the other project, but the issue there was that the Settings file does not get updated with the correct values from the app.config file unless you open the settings file in Visual Studio and allow it to reload. The values in the settings file are the ones that are being used throughout the application.
Right now are only workaround is to change out the configuration and re-publish the project.
In case anyone else runs into this problem, here is the workaround that I was able to use:
Create an xml file in the PublishProject, and convert the data in the app.config into individual xml tags like so:
<configuration>
<setting name="debug" serializeAs="String">
<value>False</value>
</setting>
</configuration>
becomes
<Properties>
<debug>True</debug>
</Properties>
Once you do this, you can call the following in your code, instead of using the value from the Settings.settings file.
XmlDocument doc = new XmlDocument();
String appPath = HttpContext.Current.Server.MapPath("~").ToString() + #"/App_Data/Properties.xml";
doc.Load(appPath);
debug = Convert.ToBoolean(doc.SelectSingleNode("Properties/debug").InnerText.ToString());
Note: that I put it in the App_Data folder of the finished project because that folder is not accessible via a browser by default.
I have two web application. Their folder hierarchy in server is like that.
first one is : .../firstapplitaion
second is : .../firstapplication/secondapplication/Default.aspx
At first can i run them with just firstapplication's web.config file? secondapplication's web config hasnt any special things.
Thanks for your helps..
One way would be to have a section in your web.config files point to an appropriate file, like this
<configuration>
<appSettings file="C:\MyCommonFolder\MyCommonAppSettings.config">
</appSettings>
</configuration>
Hope that helps
If the second app's web.config file is the same why bother to even run them as seperate apps? Why not just make them one app that uses the same web.config? Or were you trying to split them into seperate app pools?
What I have done in a similar situation was to have each site contain it's own seperate web.config but to move all of the shared pieces into my Machine.config. For me it's locatd in the C:\WINDOWS\Microsoft.NET\Framework\vX.X.XXX\Config folder (I would suggest backig it up first). Because of the way the config files work you can put settings in your machine.config and your websites will inherit these settigs. So put any shared settings there, with very unique names, and you should be set.