Single ASP.net site with Multiple Instances & web.configs

Question

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!

Answer 1

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.

Answer 2

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.

Answer 3

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.