We have a legacy ASP.net powered site running on a IIS server, the site was developed by a central team and is used by multiple customers. Each customer however has their own copy of the site's aspx files plus a web.config file. This is causing problems as changes made by well meaning support engineers to the copies of the source aspx files are not being folded back into the central source, so our code base is diverging. Our current folder structure looks something like:
OurApp/Source aspx & default web.config
Customer1/Source aspx & web.config
Customer2/Source aspx & web.config
Customer3/Source aspx & web.config
Customer4/Source aspx & web.config
...
This is something I'd like to change to each customer having just a customised web.config file and all the customers sharing a common set of source files. So something like:
OurApp/Source aspx & default web.config
Customer1/web.config
Customer2/web.config
Customer3/web.config
Customer4/web.config
...
So my question is, how do I set this up? I'm new to ASP.net and IIS as I usually use php and apache at home but we use ASP.net and ISS here at work.
Source control is used and I intend to retrain the support engineers but is there any way to avoid having multiple copies of the source aspx files? I hate that sort of duplication!
If you're dead-set on the single app instance, you can accomplish what you're after using a custom ConfigurationSection in your single web.config. For the basics, see:
http://haacked.com/archive/2007/03/12/custom-configuration-sections-in-3-easy-steps.aspx
http://msdn.microsoft.com/en-us/library/2tw134k3.aspx
Example XML might be:
<YourCustomConfigSection>
<Customers>
<Customer Name="Customer1" SomeSetting="A" Another="1" />
<Customer Name="Customer2" SomeSetting="B" Another="2" />
<Customer Name="Customer3" SomeSetting="C" Another="3" />
</Customers>
</YourCustomConfigSection>
Now in your ConfigSection Properties, expose Name, SomeSetting, and Another. When the Property is accessed or set, use a condition (request domain or something else that uniquely identifies the Customer) to decide which to use.
With the proper implementation, the app developers don't need to be aware of what's going on behind the scenes. They just use CustomSettings.Settings.SomeSetting and don't worry about which Customer is accessing the app.
I know it might seem annoying, but the duplication is actually a good thing. The problem here is with your process, not with the way the systems are setup.
Keeping the sites separate is actually a good thing. Whilst it looks like "duplication" it's actually not. It's separation. Making changes in the production code by your support engineers should be actively discouraged.
You should be looking at changing your process to change once deploy everywhere. This will make everything a lot easier for you in the long run.
To actually answer your question, the answer is no, you can't do it. The reason is that web.config isn't designed to store user level settings, it's designed to store per application instance settings. In your case, you need an application instance per user which means separate config files.
For your system to work, you need to be able to preemptively tell the application which config file to use, which isn't possible without some sort of input from the user.
Use an external source control application and keep rolling out updates as required.
It isn't really a good idea to let your live site be updated by support engineers in real time anyway.
Depending on what is actually in the web config, and what settings differ between customers, you could opt to use a single web config, and store other customer specific configuration options in a database or some other custom xml/text file. As long as the specific customer settings in the web.config don't have to do anything with how IIS operates, and you are just using it to store values, then this solution might work out well for you.
Thank you all again for your answers. After reading through them and having a think what I think I will do is leave the multiple instances alone for now and I will try to improve our update process first. then I will develop a new version of the application that has the user configuration information in the database layer and then pick the user based on the request domain or URL as someone suggested. That way I can have a single application instance supporting multiple different client configurations cleanly.
As most of the client configuration data is really presentation or data source related, nothing complicated. I think we ended up with multiple application instances mostly because the original programmer hadn't been expecting multiple customers and didn't design for that so when someone came along later and added a second customer they just duplicated the application which is wasteful as each instance is about 99.99% identical to the original.
I am implementing this as we speak.
In the main web.config, I have 1 item per installation. It points me toward the custom config file I built for each client (and toward the custom masterpage, css, images, etc).
Using WebConfigurationManager.OpenWebConfiguration, I open the new webconfigs in their subdirectories. I determine which one to use by using System.Web.HttpContext.Current.Request.Url.OriginalString, and determining the uRL that called me. Based on that URL, I know which web.config to use.
From that point forward the clients all use the same codebase. They have their own databases too.
The idea of having to update 30-40 installations when we make an update scares the death out of me. We do not want to support 30-40 codebases, so there won't be customization beyond the master page, css, and images.
I wrote a custom class lib that knows how to switch to the proper webconfig, and read the custom section I built with all our settings.
The only issue I have now is the FormsAuthentication Cookie. I need to be able to switch that as well. Unfortunately, the property for the name is read only
If I understand correctly, it sounds like you have multiple deployments (one for each client) where the only difference is the web.config, right?
First off, although I don't know your unique situation, I would generally urge you to stay with separate installs. It usually allows much more flexibility. Off the top of my head: are you ever going to have customizations, or different clients running different versions? Are you sure? The easiest way to stay flexible here is to keep going with separate installs.
In my opinion, it isn't ugly at all if your practices are aligned properly. Based on some things you mentioned, you have trouble in that area - obviously, possible source control buy-in/training issues. But you are aware of that. I would also take a hard look at your deployment procedures and so on. I have a feeling you might have further issues in that area, and I mean absolutely no offense.
That said, let's say you want to move forward with this.
You didn't say whether all the clients share a single common database, but I'm thinking no, since designing that type of system is often not worth the extra complexity (which can be severe in systems of any size) so people often opt to keep them separate.
What that means is that you have store your connection string somewhere. Usually that would be web.config... So that seems to break our plan.
Really, the apparent elegance of this situation is almost always wildly offset by the challenges it introduces. If I thought about it hard enough, I could maybe find a way around this by introducing another database that intelligently manages connection strings or maybe delving into keeping all your login info directly in web.config (which is possible but... not ideal), however my gut says the work will be wasted because some day you will end up going back to how you're doing it now.
Also: changing code directly in production is obviously not the best practice here. But you if you are on a monolithic shared platform with any amount of traffic, that can never ever ever happen. Food for thought.
Let me know if I'm missing something!
Related
I'm reviewing the way my company deploys websites and trying to determine if we need to update our methods. My particular question is geared towards the way we handle the web.config file. Currently, when we deploy, we do not override the web.config file that's on the server. We manually reproduce whatever changes were made during development. The reason is
1) we do not want to give developers the responsibility of remembering to deploy the right web.config (the production one) to the server during deployment
2) we also don't want to run the risk of anyone on the dev team accidentally changing (or even unnecessarily seeing) the production web.config
3) on some projects, there are other teams that have the power to modify the web.config (like connection string settings) and we don't want to override their changes
I've come across web.config transformations but it seems that our current methods are a better fit for our particular circumstance. I'm hoping for someone to give me a fresh perspective and probably help me see a better way if there indeed is one.
In a team of developers (i.e. UI designers, programmers, SQL developers), your strategy seems pretty right but it needs accurate co-ordination. The other way you can go is to tell all your departments about various parts of the web.config and the part which they are concerned with. Also, do commenting in the web.config file telling which parts are concerned with which team. This way they can handle the config file on their own by not fiddling with the parts they aren't concerned with.
You can also take help of VCS (version control systems) to keep track of what changes are made at what time and by which users.
I'm looking for feedback as to where I should store application configuration data and default text values that will have the best performance overall. For example, I've been sticking stuff like default URL values and the default text for error messages or application instructions inside the web.config, but now I'm wondering if that will scale....and if it's even the right thing to do in the first place.
As mentioned before, this really shouldn't matter - the settings, be they in the web.config or in a database, should be 'read-once' and then cached, so this really shouldn't matter.
I can almost guarantee that there will be other parts of your code much slower than this.
As a side note, and not performance related, but if you need to worry about site uptime, you can edit configuration in a database on the fly, but changing the web.config will cause an appdomain restart and subsequent loss of sessions.
If it's a single server setup (as opposed to a Web farm) store it in the Web.Config file. There is a new release of the Web Farm framework and you could check details for that type of scenario here:
http://weblogs.asp.net/scottgu/archive/2010/09/08/introducing-the-microsoft-web-farm-framework.aspx
If the database is on the same machine performance difference may be neglect-able. If you need to cross a wire to get to some database it's most likely slower then a directly accessible and not too large web.config.
I really would prefer keeping things simple here, just use the web.config. It probably is already getting cached in memory by some system component. If you feel it's too slow measure it and then perhaps go for a more complicated solution.
Having said that you could simply read in all configuration at application start-up and hold it in memory. This way any performance difference is mitigated to just the application's start-up time. You also get the added benefit of being able to validate the configuration files at start-up.
Not sure about your defaults but just ask yourself if they are environment specific and is it really something you want to change without recompilation. Being configuration files, what is the use case? Is some operations guy or developer going to set these defaults? Are you planning to document them? Are you going to make your application robust against whatever is configured?
Are these defaults going to be used on multiple environments/installations (used for localization for instance)? Then perhaps it's better to use a different and separate file which you can redeploy separately when needed.
How often are the settings going to change?
If they never change, you can probably put them in web.config, and configure IIS so that it doesn't monitor the file for changes. That will impose a small startup penalty, but after that there should be no performance penalty.
But honestly, there are probably dozens of other places to improve before you start worrying about this - remember, "Premature Optimization is the root of all evil" :)
Disclaimer, I am technical support and sysadmin for my company, not a developer. I'm not after the specifics, simply an idea if what I'd like to acheive is possible or not.
We host hundreds of instances of our in-house classic ASP legacy ecommerce software application and due to countless customisations by clients and ourselves, version management is nightmarish, custom code can't be managed and we've given up releasing new features and mass deploying bug fixes due to the inability to track who needs what patches where.
Parellel to this question I am making management scripts to better automate this though.
What however I'd really like to do is using the miniumum possible effort, port the application code (not the database) to a single code base. Questions I have:
Can ASP relatively effeciently handle connecting to different databases depending on the host header being called? I plan some basic extension to the routine, get hostheader
lookup up db credentials in metadb, set application connection string accordingly logic.
The application writes a few files to the webserver from the database for caching purposes, I'd like to handle this by emulating this behaviour by writing it to something like /masterapp/customer1/specificfile.htm then changing the references to /specificfile.htm in the code to more like /masterapp/shop name/specificfile.htm. Obviously the routines that write specificfile.htm would write to the new location accordingly. Does this seem reasonable?
Other webserver-bound store specific contents like images and csv files I need to keep working without URLs changing ideally, can ASP employ logic to redirect get requests for /images/example.jpg to either /masterapp/shop name/images/example.jpg or /shopname/images/example.jpg depending again on host header? Or could that be done via isapirewrite? (which we already use)
I think these are the biggest challenges. I don't need a complete project plan of how to implement each of these things, I just want to know if it's possible. If the answer is 'yes' I should be able to sell my bosses on the development due to saving support time and our in-house developers could hopefully manage this.
This should be possible and I have achieved similar outcomes with code developed that way from the start. As you are retrofitting this in it's going to be a lot harder, but that's separate to your actual question.
To answer your actual points:
Presumably your DB connection string is already in a application variable or settings file? If so, you just need some logic in your global.asa Session_OnStart that reads the host header and selects the appropriate DB string. This could be hard coded or you could have a "control" DB that stores sites, their DB strings file paths etc and pulls the details into the session object.
This is related to the above, pull your cache storage locations from the DB, or have a "directory name friendly" base name for each site, so you can have "/masterapp/" & Session("strSiteBaseName") & "/cache/somefile.htm"
If you're on IIS7 then you can use the URL rewrite module to handle this, if you're on IIS6 there are 3rd party tools you can get to do URL rewriting for you. Again I have done this so can vouch for it working. If you want to get really clever, you can have your master app create the rewrite files for you and "touch" web.config to get them loaded into IIS.
One "gotcha" you'll have with host headers is remember to handle www and no-www records!
You mentioned custom code as well for each site, I haven't done this in production but have tested outside an app and you can rewrite functions after they've already been declared. You can't have includes with variable names, but you can load in a text file and execute it, so there is a way to have custom functions, or changed core functions specific to an individual instance of your over-arching app.
I have been utilizing two third party components for PDF document generation (in .NET, but i think this is a platform independent topic). I will leave the company's names out of it for now, but I will say, they are not extremely well known vendors.
I have found that both products make undocumented use of the filesystem (i.e. putting temp files on disk). This has created a problem for me in my ASP.NET web application as I now have to identify the file locations and set permissions on them as appropriate. Since my web application is setup for impersonation using Windows authentication, this essentially means I have to assign write permissions to a few file locations on my web server.
Not that big a deal, once I figured out why the components were failing, but...I see this as a maintenance issue. What happens when we upgrade our servers to some OS that changes one of the temporary file locations? What happens if the vendor decides to change the temporary file location? Our application will "break" without changing a line of our code. Related, but if we have to stand this application up in a "fresh" machine (regardless of environment), we have to know about this issue and set permissions appropriately.
Unfortunately, the components do not provide a way to make this temporary file path "configurable", which would certainly at least make it more explicit about what is going on under the covers.
This isn't really a question that I need answered, but more of a kick off for conversation about whether what these component vendors are doing is appropriate, how this should be documented/communicated to users, etc.
Thoughts? Opinions? Comments?
First, I'd ask whether these PDF generation tools are designed to be run within ASP.NET apps. Do they make claims that this is something they support? If so, then they should provide documentation on how they use the file system and what permissions they need.
If not, then you're probably using an inappropriate tool set. I've been here and done that. I worked on a project where a "well known address lookup tool" was used, but the version we used was designed for desktop apps. As such, it wasn't written to cope with 100's of requests - many simultaneous - and it caused all sorts of hard to repro errors.
Commonplace? yes. Appropriate? usually not.
Temp Files are one of the appropriate uses IMHO, as long as they use the proper %TEMP% folder or even better, use the integrated Path.GetTempPath/Path.GetTempFileName Functions.
In an ideal world, each Third Party component comes with a Code Access Security description, listing in detail what is needed (and for what purpose), but CAS is possibly one of the most-ignored features of .net...
Writing temporary files would not be considered outside the normal functioning of any piece of software. Unless it is writing temp files to a really bizarre place, this seems more likely something they never thought to document rather than went out of their way to cause you trouble. I would simply contact the vendor explain what your are doing and ask if they can provide documentation.
Also Martin makes a good point about whether it is a app that should run with Asp.net or a desktop app.
There are multiple values I have been storing in ASP.NET configSections sections for each "module". I have been wondering if they even belong in these files at all.
The background stands at: These are multiple instances of the web application deployed. All use the same database but have their own settings.
I'm sure that differences between development and production go in the config files. Some of the values I know should include: connection strings, providers to use, setting debug, etc.
I have factored out all the common pieces in to classes with their own rules and methods. The pieces left are miscellaneous settings for each module in each site. Some of the options I'm unsure of include:
For ModuleA, Show/Hide Option
For ModuleB, What is the terminology to be used for this field
For ModuleC, Allow end user to perform X action
Mmm these sounds like things that you might want be able to change at runtime for your application without having to modify the app.config. One rule of thumb I like to follow is that anything in the config should be for the deployment or server configuration. In this case your settings appear to be modifying the application behaviour and so I would probably move them into the DB if it is not alot of effort.
ModuleA and ModuleC sound like they may be user profile information. If they're not dynamic by user, but you could add later functionality, then maybe move them to a DB.
I've written apps where ModuleB would have been put in a DB also. Things like form labels, etc. can easily go in a DB. If, at a later date, someone decides to add or remove colons to all form labels, that's a pretty easy thing to do if all of the text is stored in a DB.
Consider the situation when you need to edit one of the values.
If the value is in web.config, saving the change to that file will cause the app to recycle, inconveniently throwing out current users. Not so much of a problem if your app is on an intranet only used during business hours (though you could get an angry call from the guy who stayed to work late). But potentially a problem on a public website with international users.
If the value is in a database, it will have no impact on the app's processing in that way.
Either way, consider whether the values are cached in the app's RAM (web.config is). Are the database values in an Application variable, or in Cache? If so, you may not know when the change will occur. Unless you want to restart the app.
And, what different access and permissions would the appropriate admins need to make the changes? Someone would have to have access to the web server(s) to change web.config, or to the database (and table) to change that.
A few questions: Why do you use the same DB for multiple instances of the application, and how will that effect maintanence?
In the future will it be an option to split the db in order to improve performance? Does the config model support that change better then the DB based one?
In other words, you will have to consider a lot variables in order to answer your question :-)