In Visual Studio, when we develop, the web.config file is often modified but I don't know what is modified, and what are consequences in production envirionment for performance, and if configurations sections are important.
For example :
<compilation>
<compilers>
<runtime>
...
There are lot of sections I thinks are not essentials, and without it or with another configuration, can improve performance in production environment.
So my question is :
What are you looking for in web.config file in production environment to not to lower performance and have a light configuration file ?
What are best practices ?
Thanks for your answers !
In Web.Config you can configure whether you want debug assembles or release assemblies. You can tune the performance of WCF, thread pool. You can configure logging, etc.
Visual Studio doesn't change critical settings for you automatically. The only thing it does however is enable debug assemblies when you're trying to debug your app. It asks you for confirmation in that case. For production you can disable debug assemblies.
I would recommend you to use a diffmerge tool to see what sections are added since last commit. However please note that shorter config doesn't necessarily mean better performance.
Your web.config is merged with machine.config which has many sections. So not putting a section usually means you're not modifying the defaults in machine.config. Adding a section doesn't mean you're adding something new. It only means you're configuring something that will have otherwise some default setting.
As far as best practice is concerned. It is advisable to have a short config file to make it more maintainable. There is no point in specifying the defaults in the config again if they are implicitly default or are otherwise in machine.config anyway. VS2010 already avoids unnecessary sections.
The number of sections in a web.config file has nothing to do with performance.
Some machines will require more things configured than others (hence a size difference) in order to run the same application.
As Hasan pointed out, the web.config is merged with the machines config file. You might very well have 1 machine (call it test) which defines things in it's machine.config that isn't defined in your production config. So, for test you might not need certain sections that production would require.
Also, the machine configs for a particular item might vary. In a web farm scenario it is common practice to override the machines config file with a common machinekey. This doesn't have a performance impact but does impact whether you are going to be successful in load balancing the site.
To iterate: the number of sections is immaterial to performance. The contents of defined sections, on the other hand, is.
Now, how to improve performance: This is on an application by application basis. For production you will want to turn off debugging, and turn on things like url compression for static content.
You might want to turn on compression for dynamic content as well or even configure certain directories to inform the browser that content is cachable (like /images, /css, or javascript). Incidentally, these would generally increase the size of your production config file and has certain consequences (like when you want to change a css file), but will generally yield improved performance for the client.
For other items you might turn off logging or use a completely different logging storage provider. We use elmah and our dev boxes are configured for in memory storage whereas production is configured to use a database server. Not necessarily a performance issue, but certainly one of concern.
The point here is that a config file should be used for the purpose of making sure the application can execute on that particular platform / machine.
Related
I have a several MVC project's (all the same) and I'm wondering where to place the Application Configuration? Right now I have the following options:
Store them in a central database
Store them in the application database
Store them in the appSettings (web.config)
Store them in a configsection
Store them in a custom configuration file
I wonder what the best practice is for a situation like this
I think you must store them in application databse. Cuz,
It will be different for every application, e.g. If one application light theme and the other wants dark theme.
It is better to save in databse, cuz you can update the configuration by application itself or by running a query. So, its very to simple to change the settings rather than keeping it in Web.Config.
You can create a class to acces the configuration values from database. use Indexer so that you can use it like Configuration["Theme"] makes the access more easier. I have used it in my project.
But, if its database related, you need to store it in web.config
Hope, it helps you lil bit. Have a nice day. :)
I don't know if there is really a common 'best practice' for where to store settings. You would have to take into consideration all the variables for a given situation. Some thoughts I had:
Storing settings in a database could be useful if you require central storage between different applications. Would have fewer concurrency issues. Depending on the type of settings stored, you could find database schemas being inefficient. It also brings in a dependency on another server/service for the application.
Storing in web.config is nice and simple. Not really useful for settings that need to be changeable from the application. Also, any change to settings in web.config will initiate an app restart.
Custom configuration file would give more flexibility for setting storage. You will of course have to write additional code to read/write the settings. Serialisation could handle this in a lot of cases.
If it's low-level application settings that are changed rarely and only by you, I'd probably go for just web.config. If you're talking about settings that are changed through the application (e.g. user preferences), I'd go for database storage.
You should store default values in web.config and other settings in your database.
For example if your application has a mailing system, than smtp settings should be stored in your database, but the culture in which mails are sent should be stored in web.config
Also, there is a way to store application settings in your Visual Studio environment, as follows
Right click on your project > Properties > Settings tab > Create
but I've never used this. You can also update your settings by calling .Save() method. Read more about it here
In my case :
I store settings in my database
I store default values in web.config
Configuration is something which one should quickly locate, that is why there are configuration files in projects irrespect to platform. Every platform sdk now comes with SDK which ensures their community follows practices they recommend.
If you want to secure configuration files, you can encrypt it which i believe not needed if the software development follows subversion workflows and other development practices.
I have just used the Combres library in my project to minify the css and js files, and basically optimize the page a bit. Everythere I read about the Combres I see that it sends the etags together with the resources it optimizes, and yet when I publish my project, the resources compressed by Combres doesn't have the etags on them. Is there any configuration I need to make to have this working? I am using windows azure to deploy my project (if it matters).
I would be grateful for help with this question.
You might have etags disabled by some means outside of Combres (such an http module). Depending on whether you are using IIS6 or IIS7.5 there are different techniques for removing etags. Some people have done it within the web.config under specific scenario (I think for classic app pool). You can search your web.config for 'etag' to see if there is anything in there. If its not in your web.config, search your web project for 'etag' to see if you are removing them in an IHttpModule somewhere.
Also before you spend too much time on this, you might consider forgetting etags anyways. They are sort of 'passe' and outdated. The thinking is that long reaching expiration dates on versioned files are sufficient. If a visitor/user cleared their cache there won't be any old etag to compare with anyway. If you update your combres resources its going to spit out a new versioned path which won't be compared with the old cached files' etags either. So eitherway you really don't benefit from etags with the current technology.
In fact many people go to the trouble of removing them because of their lack of usefulness and their waste of bandwidth. (Which might be why you don't have them. Some performance tuning thing you may have done in the past could have disabled them when possible.)
It shouldn't matter that your files are minified, nor what utility you use to do so. ETags are controlled by the web server (IIS) but I'm not sure how that's handled on Azure, but you could use an HttpModule to customize ETags:
http://codebetter.com/karlseguin/2010/01/08/asp-net-performance-part-2-yslow/
Hope that helps.
Every .NET project I've worked on uses an app.config file for its configuration. Fair enough.
Today I am asking, "is there a better way?" (in the spirit of continual learning of course)
I guess my specific questions are:
Does it matter either way if I use app.config or settings file?
Are there any scenarios where settings files should not be used e.g web sites where you should use a web.config instead?
Other than not having to edit xml, are there any other benefits gained by using settings instead of app.config, e.g. its easier to deploy or maintain apps etc.
Clarification:
I'll put this question another way:
Can I completely ignore app.config files if I want to and keep all the configuration in a settings.cs file and interact with configuration via the designer only?
IMO, the main advantage of settings files is scoping (for client apps at least) - that is, that you can have different values of the same setting for a different user. It also allows you to easily edit and save user-scoped settings. And yes, if you don't like editing XMLs - then settings have the advantage of a designer too :)
I don't think it really matters either way, as long as it works for you.
I wouldn't use settings files in situations where values are going to change after an application has been set up.
I tend to use a mixture of custom settings in the web.config and settings within a database.
Custom settings in the web.config are based on this here http://msdn.microsoft.com/en-us/library/2tw134k3.aspx These settings will be things that are not likely to change once the project has been set up, but allow for you to easily share class libraries with other projects.
The database settings are things that are likely to be updated at times during the project, e.g. email addresses
Im reading 2 books about WCf and one of them is showing Configuration as App.Config and the other is showing via Code in C#
I want to know which approach should i use and what are the benefits for each other.
Does the Wcf Configuration Wizard supports also the c# code behind configuration ?
thanks for the answers.
Configuration files can be changed without a rebuild (handy, say, to add a custom inspector or serializer), is pretty easy to copy/paste between client/server, has support from the IDE tooling.
Code is handy if you are configuring the system at runtime (i.e. getting the information from another server), or are running as a library (dll) and can't guarantee that a configuration file will a: exist, or b: have your configuration. Code also has intellisense / static checking to avoid brain-dead errors (typos in the xml etc).
I'd use a file until you know you have a scenario that doesn't work well with a file.
Also consider: how hard is it for you to deploy a code change vs a configuration change? for me they're about the same, but that might not be the case for you. Maybe it is easier to just change the config on the machines? maybe not.
I guess it depends on your needs. I personally tend to configure wcf with code, especially for things that are unlikely to ever change. That might include error handlers/logger, behaviors, authentication modules, service host factories, etc
For more dynamic stuff, like connection strings, passwords, file paths, etc are configured in .config files.
One of the biggest advantages of using code is that your code now can support things like IOC/Dependency injection, compile time checking, etc.
I don't buy into the idea that everything should be in a config file because it's easier to change it. In most cases I've seen it never changes in production.
The configuration file approach is better, it gives more flexibility. For example i change the authentication type (username password/windows) by changing config files.
Why is it better to store data inside an appSettings element (or inside a custom section) of a web.config file than to store it in a class?
One argument would be that by using custom sections we don’t have to recompile code when we change data, but that’s a weak argument, especially if we’re using Web Sites, which get recompiled automatically whenever code changes!
Thank you
Because you can change it on the fly and use it without regard to class structure. Your configuration can vary from each developers machine to staging to deployment environment by changing and maintaining a single file independently of the code, and you can take advantage of *.config masking with different areas of your site.
Hard coding anything configurable is a recipe for failure and it absolutely will bite you - this is just a matter of experience, if you don't believe it then you have but to wait a little while!
By putting settings into web.config, you have them all in a centralized location.
Also when deploying a web site, you might want to precompile it once. So you won't be able to change the source afterwards (without another recompilation).
It's not really a concern of just recompiling the code, it's more about re-deploying the code. Normally, you don't deploy code to the web server, you just deploy the binaries and aspx/html files. If you hard-code your config data in the code, you'll have to rebuild and redeploy the library or application to get the change up to the server, which is a lot more work than just updating the web.config.
Putting data in the web.config file also allows the same code to be run in different environments with different environment-dependent data. This can mean running the same website code in staging with a test database connection string and in the production environment with the production database connection string. Or it could mean allowing the developers to configure the data for their own tests without changing any code, as 'annakata' mentioned.
It's just a WHOLE lot easier to manage and update the settings.
If you're using Notepad to do your development and putting the code out on the server, I would agree that there is little benefit, but if you're using Visual Studio and you build your website and publish it, you're publishing the pre-compiled dlls and not just updating text source code (.cs or .vb files) on the server. So when it comes time to update a setting at that point, anything in the web.config can be updated by simply modifying the text file, where as with other changes, you have to re-compile t whole web site and publish it.
And from experience, that becomes tricky when taking over after other developers that weren't careful about ensuring everything needed to make a web site work is in source control. I'm now stuck with a web site where we can't update huge chunks of it because of (kindly putting it) non-standard practices in the past.
Being able to update something without re-publishing the site is a huge blessing in my situation, and you never know who the poor maintenance programmer will be that takes over on your code.
Be nice to him or her. Make it easy to make simple changes.