What it best location to store various configuration settings of a web site modules.
Creating class (that inherit ConfigurationSection) that map the settings in web.config file?
Or creating some DAL and BLL clases that work with database?
I've used a simple heuristic to categorize each configuration variable into one of four categories:
Compile time configuration (changes done together with code changes) - if possible then inside the code or assembly (as an embedded resource), otherwise in web.config
Server instance specific configuration (SQL connection strings, local file paths) - in web.config
Application (database) configuration (feature selection and other global application settings that change rarely, if ever) - in database but without an UI
Application configuration - in database, accessible through an admin UI
Storing the configuration settings in the Web.config will have the effect that if you modify the web.config file, your application will be restarted and the new settings will have immediate effect.
If you are running the application on multiple machines, you however will need to update each machine.
If you store the configuration settings in the database, you will need to either restart your web application manually or have a function (such as an admin page/site) to allow the application to re-read the settings.
To actually answer the question:
Basic information is going to have to be stored locally in web.config (connection strings etc.)
Beyond that other information could be stored in either location.
Having it in the database means that it's easier to write admin pages to control the information rather than editing the web.config file directly.
How often are things going to change? If set up is a one-off thing then having admin pages would be overkill, but if there's ongoing changes (adding new users, categories etc.) then they might be a good idea.
Also with data in the database you can perform remote administration on the system
So, without more information on your application I can't make a recommendation.
In most times, you have separate settings for each module on each page. Thus, you have to save them in database.
Build a configuration section. It is pretty straight forward and suits your needs.
Related
What is "the Orchard way" to define environment-specific configurations and/or configuration transforms? Is it possible to use regular Web.config transforms like in any other ASP.NET web app, or does Orchard have it's own engine for this?
(I've not been able to find any useful information on this topic in either the official docs or out in the wild.)
It's perfectly possible to store that information in web.config, as in any other ASP.NET application. In lots of cases it's the only way to go (eg. environment-specific IIS settings and so on).
You may also store custom settings in Orchard database, by writing your custom settings part and attaching it to "Site" content type. It's the preferred way to go if you have some data to store, that does not have to be kept inside web.config file (alternative to creating a custom config section).
I have a custom ASP.NET application that I utilize for several clients that I host. Each client has a separate domain and the application is normally a child application under the root domain (http://domain.com/customapp). The application files are the same (aspx, ascx, style sheets, images, etc.). The only thing different is the web.config file for each client. As development of the application continues to evolve, I have to update the application for each directory and this obviously becoming tedious. I am trying to come up with a method keep the application up to date. My first though is placing the application into a single physical path and creating multiple applications pointing to that path (the problem with this method is I can't have different web.config files). I am curious as to what solution others are using in this scenario...
If you want to handle this entirely in Visual Studio, VS2010 offers web.config transforms which could solve your problem.
In a nutshell, create a build configuration (In VS, select Build|Configuration Manager...) for each site. Add a web.config transform for each client, which only specifies the differences required for each application.
I use this for differentiating between development, staging and release configurations - each transform adjusts the connection string, app settings, etc - and it works quite well both within Visual Studio and when deploying via MSBuild.
Also, note that web.config settings are inherited by IIS applications. So, if you have a root site
/root
and client apps
/root/client1
/root/client2
...
you could place the client-specific config settings in a web.config in each client-specific folder, and global settings a web.config in the root folder.
Can you just move your web.config content to a database and load it conditionally based on the domain that was referenced?
Select Case Request.Url.Host.ToLowerInvariant()
Case "xyz.com", "www.xyz.com"
'Load XYZ stuff'
Case "abc.com", "www.abc.com"
'Load ABC stuff'
Case Else
'Throw an error probably'
End Select
Even better, store your domains in the database as keys so that you don't ever have to touch the code.
Is it possible to use a small .NET page to set folder permissions on some folders on the server where it resides? What is the code or objects that can be used for this? I am on Windows Server 2003.
Basically I want to hit the page with a GET or POST and have it run and check and/or update the permissions on a folder.
There's a number of possible ways to approach this.
One is to use the FileIOPermissions class, which allows you to specify permissions on files and folders.
The other option is to use the DirectorySecurity class within the System.Security.AccessControl Namespace, and specifically the SetAccessControl Method of that class.
This second method should provide you with much more granularity and control over the setting of permissions as the System.Security.AccessControl namespace allows you to programmatically create or modify discretionary access control lists (DACLs) and system access control lists (SACLs) for a number of protected resources such as files, folders, and so on.
Irrespective of the method you choose to perform the permission setting, you will need to be mindful of the account that your ASP.NET-driven code is running under. You say you are using Windows Server 2003, so you're probably using IIS version 6.0. By default, IIS 6.0 will run all user code under the "Network Service" account, which is a low-privilege account and will have limited permissions outside of the IIS processes and the website hierarchy. You can read the MSDN article, "How To: Use the Network Service Account to Access Resources in ASP.NET" regarding accessing resources on the server side and exactly what access you will have under this account.
Depending upon the exact nature of what you want to do, you may also need to look into ASP.NET Impersonation to enable your server side code to run under the context of a different account. See the MSDN article, "How To: Use Impersonation and Delegation in ASP.NET 2.0" for more information on that.
You can use the FileIOPermission class to do this. Just make sure the user under which the website is running has this permission to do all the security settings.
Background Info: File Replication is Lame
Currently, we have a massive, high-traffic ASP.NET web application load-balanced across 8 different IIS servers. Due to the nature of the site, minor changes to .aspx files and .ascx controls happen frequently throughout the day, and after being tested and published to live, are replicated out to each of the public webservers through xcopy deployment on a scheduled basis every 10 minutes.
Of course this is incredibly inefficient, as each server must have a redundant copy of the entire site, and we would like to eliminate the 10-minute publishing lag.
Possible Improvement: Hosting from Shared Storage
We now have the option to use centralized storage with an iSCSI interface to host the entire site centrally, with each server believing that the remote storage is a local drive. Publishes would be instantaneous and system-wide.
Note: Hosting the drive off a UNC share is not possible, as there are so many different directories in the site structure, each requiring a FileSystemWatcher for ASP.NET to monitor for changes, that the SMB maximum command count is quickly reached. Yes, we know about the MaxCmds and MaxMpxCt registry settings.
The Problem: Web.config changes trigger massive recompiles
The problem we forsee is that certain changes to the file system structure can cause nearly every compiled .aspx or .ascx to have to recompile, causing queued requests and a perception that the server is down. Most resources are not used system-wide and so recompiling them on a change causes hardly a blip in resources. A global master page used by all pages on the site can cause this, but this can easily be managed by code.
The primary culprit is the web.config file. Changes to the web.config file cause the entire web application to recycle, and recompilations to occur. So, we currently don't replicate web.config changes. Any web.config changes requires bringing the web server off the load balancer, applying (and testing) the changes, and then warming the server up with junk requests before it is placed back on the load balancer.
However, if the web.config file, like the rest of the web application's directory structure, is located on centralized storage, there is only one copy of the file, and individual servers could not be patched and warmed up anymore.
The Question
Is there a way to get an ASP.NET web application to take its marching orders from a source other than a file named Web.config?
Ideally there would be one file per server, for example:
default.aspx
global.asax
Web-ServerA.config
Web-ServerB.config
...
Web-ServerN.config
Where is the name "web.config" defined anyway? Is there a registry setting that could be set on a per-server basis? Is there an entry that could be made in the machine.config or the global web.config to specify what file to use?
Things Out Of Scope
Just so I am clear, I am not asking how to have different AppSettings for debug, test, and live. There are other topics that cover this, and all my web.configs will be identical most of the time, the only time I need them to be different is when an update is being performed.
We aren't using the web.config for any appSettings information; this is for the really important stuff, like assembly references, httpHandler definitions, and other system.web settings that can not be databased.
Update
I tried searching the registry for Web.config, and found nothing except for applications that noted that I had recently edited web.config files, which I apparently do a lot. No help there.
My first question would be what are you keeping in the web.config & can you move it to a database? We keep every config setting in a table in our database and use the machine.config to store the db connection information.
Not sure how much of a rewrite that would be for you, but it would avoid your issue.
Another option would be to house your configuration items in an external file and reference it from the web.config. Changes to that file would not be re-read until the aspnet wp was recycled but would allow you to change setting and then cycle each server via an IISRESET.
<configuration>
<appSettings file="OtherFile.config">
...
Just curious, what filesystem are you using? NTFS is not a shared storage file system. In other words you can't have more than one node writing to the filesystem at a time.
I would suggest virtual directories under the site in IIS. This will probably require a little bit of restructuring the layout of your code, but shouldn't be too major. So, you would have the root home dir of the site with the web.config that is specific to that machine and then a vdir mapped to whatever shared filesystem resource you setup.
I have an application that uses Forms Authentication to authenticate one type of user. There is a section in this application that needs to be authenticated for another type of user using a different table in the database. The problem happens if the second type of user's session times out, she is taken to the login page defined in the Forms Authentication section of the main Web.Config instead of the login page for the second type of user. I am looking for solutions to this problem. One idea is to create an application in IIS for the section and create a Web.Config for the folder and add another Forms Authentication section. In my experiments, it seems this doesn't work. Am I missing something obvious? Any insights?
IIRC, the authentication works per folder. So you should be able to do it if all of the pages that require the 2nd type of authentication live in a specific sub-folder with it's own config.
Not 100% sure on this, though, so if someone more knowledgeable can contradict me I'll just delete the response.
You may need to double check me on the syntax, but the top level web.config can have any number of tags.
<location>...</location>
Inside you can specify separate config parameters for whatever folder/file you want. Look here for a reference.
EDIT: Apoligies, I neglected to format the code properly
You cannot have an <authentication> section inside of a <location> tag, so you must have the subfolder set up as an IIS (and ASP.NET) application of it's own. So, you should be able to run the subsection on it's own.
I think 500.19 is the "can't read or parse web.config" error - does it have details? You may need to turn on remote errors (or check Event Viewer) to see them. If you're still having issues, post a snippet of web.config.
As an aside - I've never been a fan of nested apps, and would probably prefer having your normal Login.aspx page handle it either with as a MemberOf or perhaps redirecting to a SpecialUserLogin.aspx or something. Nested apps are a PITA to setup and test, IME (for instance - I don't think you can even get it working under Cassini - though you can do 2 separate projects for it, and combine when you deploy).
Yes you can. The Web.config files have a tree-like inheriting arhitecture with override capabilities. Meaning you can modify the settings inside a sub-folder by placing a web.config file there and specifying different configuration settings.
The way I understand this problem, you have two solutions and the first is to look at Roles and the whole Provider Model would be a great place to start. Otherwise, the best bet would be to separate the application into two parts, breaking out the second user type area and then including it back into the main project via a Virtual Directory. Just remember that Virtual Directories inherit their permissions from the parent directories web.config, so you will need to use the <Location>tags to remove authentication for the virtual directory and then within the virtual directories web.config define your new forms authentication. This works well if you need Windows Authentication (NTLM) under Forms Authentication.