Is there ever a case that the traditional ASP.NET appSettings should be preferred over a Sitecore setting (i.e. <configuration><sitecore><settings><setting>) when creating application-specific settings? I can think of a couple of advantages of using Sitecore settings, for instance, being able pull those setting out into the App_Settings/Include folder, but I am not sure of any advantages of using the ASP.NET appSettings.
I would suggest a third approach. I highly recommend creating a configuration file, and corresponding IConfigurationSectionHandler, specific to your project (or assembly). This prevents appSettings or sitecore/settings from becoming a dumping ground and prevents magic strings (i.e. the configuration key) being littered in your code. This approach also allows developers to quickly identify where settings are for code in a specific assembly (the config file should be named similar to the assembly). Furthermore, using Slow Cheetah you are able to add configuration transformations to the file.
I dislike the use of appSettings for anything other than settings which are very specific to the web application project itself. Examples would be aspnet:MaxHttpCollectionKeys as Trayek mentioned, ClientValidationEnabled or UnobtrusiveJavaScriptEnabled
In a similar vein, I dislike the use of Sitecore settings for anything other than storing settings for Sitecore modules or other customizations to the Sitecore system.
I think the advantage to the Sitecore configuration route is as you describe. Namely, your settings can be segregated into their own .config file in App_Settings/Include. Moving settings outside of web.config is somewhat possible natively via the configSource attribute, but Sitecore allows for as many files as you need. That way each component's settings can be contained in their own file (and distributed as such).
The other advantage is being able to take advantage of Sitecore's config patching mechanism. If a your component installs a default settings file, but a certain environment needs to override a value, you can put a second file in place to override the values.
We are also using the Sitecore settings for our configurations. Another advantage is that you have a nice interface to read the properties:
Sitecore.Configuration.Settings.GetBoolSetting("MySettings", false);
The only disadvantage I can think of is, that the files in the Inlude-folder will be rendered at runtime and the settings in the web.config not. So if you have thousands of settings you may consider to add them to the web.config.
In our projects we tend to have the global settings, such as the URL to use to get address information, in the appSettings.config and the Sitecore specific settings in the Sitecore settings.
I think it's mainly a matter of preference, although I think there might be settings that can only be added to the <appsettings>, such as aspnet:MaxHttpCollectionKeys (I haven't tested adding it to the Sitecore settings though).
Going on Kevin's disadvantage (at least, how I understand it), is that you can't quickly see what settings you're using - you can go to website/sitecore/admin/showconfig.aspx for that (although that only gives you the <sitecore>...</sitecore> section of the web.config.
The advantage of appSettings is that it'll run out of the box anywhere, and it's dead simple. Everyone who knows ASP.NET knows what appSettings are. While Sean Kearney offers some good advice, I feel it's a bit of a violation of the K.I.S.S. rule. You already have two different options for configuration settings... why add a third? This seems quite unnecessary, unless you are dealing with hundreds of settings.
You can quickly and easily make appSettings more manageable by putting it in its own file.
Related
I have a few applications that are set up using elmah for error handling. I recently read that Web.config files inherit from parent applications/directories, and decided to test it so that I can change elmah's settings in one place (since all the current Web.configs are identical when it comes to the elmah configuration). After creating a virtual directory in IIS7, nesting all my applications under it, and creating a stand-alone Web.config file in the physical folder, I tried testing it.
After removing the elmah specific configurations from one of the applications, I found that elmah stops working altogether. Just to see if it was something I did wrong, I created a connection string in the parent Web.config file, then called the connection string through code in the application. No issues. Inheritance was working fine. I tried adding all the elmah specific configurations back in, and removing them one at a time, but it kept complaining every time I removed something.
The question I have is:
Can only certain settings be inherited from the parent Web.config?
If not, am I just not comprehending how inheritance works with nested Web-configs?
I wanted to ask if it's an issue with me before I ask about it on the elmah site.
You should check this answer, it will maybe help you.
Also, in your child web.config, make sure that you do copy the configsections for Elmah (or make sure they are properly inherited). Otherwise, the elmah sections in your child web.config might not work (not entirely sure about that though)
I have an application which creates page routes from a database. My whole site is secured with forms authentication but I need to allow unauthenticated uses to access these routes. I don't want to hard-code <location> tags for the routes in the web.config as this will negate me using a database to generate the routes.
Can anyone help?
Thanks everyone. I've found an answer here
Basically it involves creating a folder for each route and putting a web.config file in it allowing access. This approach needs to be coupled with setting RouteExistingFiles to false so that the routes don't get confused with the folders.
Rather than using strongly typed configuration classes, why not make the modifications directly in XML?
Here's an abbreviated snippet to demonstrate the concept from some code of mine that performance IIS tuning in the machine.config. The principal is the same for other XML config files though. You just need to create the appropriate XPath statements to do what you need.
XmlDocument machineConfigFile = new XmlDocument();
machineConfigFile.Load(MachineConfigPathString);
XmlNode autoConfig = machineConfigFile.SelectSingleNode(#"/configuration/system.web/processModel/#autoConfig");
autoConfig.Value = "false";
machineConfigFile.Save(MachineConfigPathString);
When saved, the XmlDocument object will preserve all other untouched document nodes. Very handy. It works great for modifying the machine.config. The only possible issue I can see is that your application will probably reset when you save your changes to the web.config. So test it out in a safe environment with a backup of your web.config just in case the reset causes any undesired outcomes!
I found this MSDN link for you. I didn't find whether you can modify the config of running server instance this way though.
Have you considered implimenting your site security in a different way? Having a portion of the site that allows unauthenticated access and a portion that does not. I am "assuming" (bad) that you are using MVC since you are describing routes - this is very easy to do with both MVC and traditional web form applications.
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.
I have few settings which I could place in a separate XML file and have them accessed in the Web app. Then I thought (thinking of one additional file to deploy), why not have them in the web.config itself. However, just because I need to have custom nodes, I can not have the settings under . So, I am thinking of creating a custom config handler following this. Would that be better than having a separate XML file? Is It going to be an overkill or performance wise? Is there a better way to go?
From performance standpoint putting custom settings in web.config and creating a configuration handler will be OK because the config values are cached and read only once when the application starts. Putting the values in a separate XML file you will need to handle the caching your self if you want to avoid parsing it every time you need to access those values.
The shop that I work at basically has developers creating controls and a backend platform, and producers to skin and customize sites for each client.
We are currently using resx files in App_LocalResources folder to expose copy in many of our controls. The problem is that the producers have a hard time finding the correct resx for a specific string, when our controls are spread out in a deeply nested folder tree that they don't really understand.
We want to put everything in one place, and App_GlobalResources seems like a good solution (we don't mind adopting a naming convention for resource strings to avoid collisions) However, moving a file from an App_LocalResources folder to App_GlobalResources doesn't seem to work (just throws a resource not found exception)
Any idea why this is happening? Any other suggestions for tackling the problem?
Perhaps the code is calling GetLocalResourceObject() instead of GetGlobalResourceObject()?
Edit: based on the comments below and given that you're using implicit localization, the correct answer is that implicit localization requires local resources.
As for an alternative, I would try using a custom resource provider instead of the default and make the CreateLocalResourceProvider() return the same as the CreateGlobalResourceProvider() method: a GlobalResXResourceProvider instance (or anything else that suits your needs).
There is difference to get local resources and Global resources, If you are trying to put your localized resources to Global Resources then you need to change your code as well to access resources like...
Accessing Global resources
Text="<%$ Resources:GlobalRes, YourKey %>"
Accessing Local resources
meta:resourcekey="YourKey"