Which is better from a performance perspective?
Accessing a Global Application Variable (Application["foo"])
versus
Accessing an AppSetting variable from the web.config
Does .NET Cache the AppSetting variables so that it is not accessing the web.config file with every use?
These two things are not comparable. appSettings, or any other configuration settings, are for configuration settings. Application variables are for quantities that might change during the course of the application, or are for things like tables of domain data values. These latter are things which you would not place into a configuration file, because they change rarely, and do not need to be configured.
appSettings and everything else in a config file, is cached. The file is only read once per AppDomain, in general. In fact, when you change your web.config, it causes an AppDomain restart, mainly so that the new configuration settings can be read in.
appSettings are apparently not cached
EDIT: Seems both appSettings and Application variables would be the same speed then. After the initial load of course.
Related
I would like to store some meta-information about a given site instance that can (a) be managed by that site instance and (b) persist clobbering of Web.config file.
The site will run in multiple environments (dev,testing,staging and production) and each environment can have different values for this metadata.
Note: All environments are running IIS 7.0+
The Root Web.config seems very appealing, as it is certainly outside of the website. Therefore, both files and databases can be changed while maintaining the metadata. I have seen how to modify the appSettings of the Web.config stored in the website, but is it possible to similarly modify the appSettings in the Root Web.config (Specifically within the proper directive)?
If you have other suggestions of approaching this problem, I would be very happy to hear them. Thank you!
would not use web.config for runtime modifications, that will cause the application to recycle, perhaps some other form of configuration file like app.config
if my assumption is incorrect and the web.config will not be edited after the application is started, then you can use WebConfigurationManager to access the file sections
Yes you can modufy the app settings within your web.config Just use the WebConfigurationManager class in the System.Web.Configuration namespace to create a Configuration object. This object could then be used to read and write changes to the web.config file.
You could then create your own "keys" or attributes that could be read as needed.
Depending upon what your attributes represent or if they need to be picked up by multiple environmnets from that server I would also look into making the modifications within the machine.config file as then those settings would apply to the enter machine and thereby picked up by multiple environments( if you are hosting multiple webapps from the server). This could save you time in modifying multiple web.config files and narrorw the storage or the metadata to one location vs. multiple config files in certain situations.
When you have a system of multiple application, web services and windows services, which is better option?
Option 1) Put all settings in database table and cache it somewhere, probably you will have to use a web service to share the cache object across applications. You can then view some of those settings in a grid for user manipulation.
Option 2) Put all settings in a common configuration file, and let web.config or app.config of each application points to that file, I am sure there is a way to put those settings in a grid, but probably you will lose the capability of "showing settings based on Role".
Thanks
A lot of this comes down to preference, what settings you're talking about, when you need access to the settings, and how often they'll change.
Generally, I try and keep my web.config & app.config pretty small. Settings for infrastructural things (e.g. modules to load, connectionstrings, log settings, ORM settings, etc) go in there. Anything that I really need or want to have access to on App_start or in my Main() method, basically.
Anything more complex, or that's applicable to less of the application, etc, I generally don't put in the config files, but instead either have settings objects which I inject through my IoC container, or else pull them from a database.
I prefer option 1, as it makes deployments easier, as each environment can have different configurations, yet you're still able to do a xcopy deploy, as settings aren't stored in the web.config.
I would suggest putting the configuration in the database and then retrieving it based on the application. You can also write a single XML that contains different configurations and load it on the datagrid etc..This way management of the configuration becomes easier, because you have a single file to maintain.
This might be a borderline Server Fault-question, but here goes.
I have a IIS 6 where AspMaxRequestEntityAllowed="204800" in MetBase.xml, suggesting the upload file limit is 200kb, while <httpRuntime maxRequestLength="20192"/> in web.config allows for a 20mb upload - and the latter is what the application allows.
Why do web.config override MetaBase.xml? To me, that seems like an error of hirarchy. And where would I find a "centralized parameter" to config max limits for the entire machine the server is on, in case I don't want some web.config mishapp to allow for gigabytes of upload?
Web.config file is the last-point configuration manager and entries in it will override any entries made in the higher layers.
I.e. any settings made in machine.config file (which are applicable to all websites) will be overridden by web.config (applicable to only that website).
In fact you can have separate web.config file for each folder which will override your root level web.config.
This is the way hierarchy works you know.
I am not aware of MetaBase.xml but in your machine there are default configs available in folder
c:\Windows\Microsoft.Net\Frameworks\VERSION\Config
am sorry the exact name could be little different, but you will figure out easily, here you will find couple of different web.*.config files, in each of them you can configure and there is a way you can disallow this property to be changed at lower level, but I am not aware of how to do that.
Reading MS Documentation of httpRuntime says that max limit is anyway set to 4MB by ASP.NET itself. I will try to find how to block lower level to modify this element in their web.config.
Why do we store connection strings in web.config file? What are the benefits of doing so?
The web config file is used so you can reference the connection anywhere in your app. It avoids having to deal with a fairly long connection string within your application.
Here is a good article which may give you detailed information: http://articles.sitepoint.com/article/web-config-file-demystified#
There is even a wiki page for it :) (surprisingly):
http://en.wikipedia.org/wiki/Web.config
If you ever move / change to a different database format the connection string setting inside of the web.config file can be changed in one place rather then digging through your entire application looking for it. This also avoids having to recompile or build an application to get the new connection string setting.
If you are wondering how to access the information from within a web.config file that can be found here:
http://msdn.microsoft.com/en-us/library/4c2kcht0(VS.85).aspx
There is also sample code right in there.
Imagine you have several classes which access your database; you can:
Place your connection string in every class
Create a constant to store that value
Place it inside your configuration file and to refer it
These have following characteristics:
Every time a connection string changes, for instance, migrating from development to production environment, you'll need to change everywhere;
By using a constant, you just need to change a single place. But in this case, when your string needs to be changed, you'll need to recompile it.
Same as above, without that recompile part. You can to develop your application and other people set that database connection to you
So, by storing a connection string into your web.config file you gain more flexibility to change that setting than other alternatives.
Reason #1
As everyone is mentioning, having the connection string in the web.config makes it easy to update/change as needed. It becomes a single source where the arguments can be easily be changed.
Reason #2
Beyond that though, IIS is configured not serve up web.config to users who request the file. If your website is,
www.mydomain.com
someone can't hit http://www.mydomain.com/web.config and scrape all your confidential settings, passwords, and so forth.
(As a side, note, IIS won't serve up files in the App_Code directory either to a user, so the web.config file isn't unique in this respect.)
Reason #3
ASP.NET automatically detects changes to configuration files and will immediately applies new settings.
More info..
MSDN has a discussion of the ASP.NET configuration system at,
http://msdn.microsoft.com/en-us/library/aa719558%28VS.71%29.aspx
What I like most about having the connection string in the web.config is when you have multiple environments that you test on. Say you have a Test server, Staging server and a Production server. Well you don't need to have code that checks which server you're on, or have to recompile different versions for each... just use the web.config to store your connection strings and that way you can have a different web.config on each server but the same web application with no hassles. You may want to Encrypt your Connection String Settings as well so they're not visible to everyone that has access to the folder.
You can reference them using the ConfigurationManager via the ConnectionStrings property.
http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.connectionstrings.aspx
It allows the connection string to be configured by someone maintaining the site.
You don't have to re-build the application if the connection string changes. An admin can make the change and the code remains the same.
I have an ASP.NET web application where i am having multiple subrirectories in the root folder.in my root web.config, i have sessionMode as "StateServer" . So in one page of my subdirectory, i am not able to do serialization. If i change the SessionMode method to "InProc" , it will work fine. I want to maintain the web.config file in the root directory as it is.So i am planning about having another web.config file in sub directory.Can anyone tell me how to do this ?
Thanks in advance
While you can have a Web.config in every subdirectory not all settings are allowed at all levels.
And SessionMode is one setting that can only be made in the application-root.
You can just place a new web.config file in the sub-directory and ASP.NET will override any settings you change in that directory.
If you mark the class that is being put in the Session with the [Serializable] attribute, it can usually be used in an StateServer setup.
Just put another web.config in the subdirectory. ASP.NET allows for that, and I have several areas on my website where the web.config contains values specifically for that "application" specifically.
That said:
1) Are you sure it's a good idea to maintain state in two different ways? It would probably be better to figure out how to make your session state serializable or get rid of using session state altogether.
2) All those web.config files can get tough to maintain if you're not careful about what values you put in each.