1

Right now, we have a setup something like this for our business:

- App pool 1
 - Site 1
- App pool 2
 - Site 2
- App pool 3
 - Site 3

There correspond to:

C:\inetpub\Site
C:\inetpub\Site2
C:\inetpub\Site3strings)
C:\inetpub\Site4

And so on. This is annoying, as our code needs to be maintained across multiple folders, and people often forget to do so; that's an issue that can be fixed, but I'd rather solve it in the solution rather than the process. The code in all the folders is identical, only the web.config files are different.

The reason we have our sites split this way despite the identical .NET code is that we need different connection strings to different servers. This way, whichever site hosts the binding gets the traffic. This is how we handle load balancing, which is not the prettiest way, but it gets the job done.

I'd rather MULTIPLE sites (with one or multiple app pools, doesn't matter) which work the same way, but function with ONE shared code folder. What I need is a solution to handle the connection strings based on the site in IIS. I didn't have much luck looking into virtual directories, which seemed straightforward but I don't think is possible, as it needs a web.config to even know WHERE to look for virtual directories.

I'm sure I'm missing something simple here, but I need a little help to get to this:

C:\inetpub\SiteMaster (contains all .NET code)
C:\inetpub\SiteMaster\Site1_Config (only needs to tell me the connection strings)
C:\inetpub\SiteMaster\Site2_Config (only needs to tell me the connection strings)
C:\inetpub\SiteMaster\Site3_Config (only needs to tell me the connection strings)
1

One option is to change your code and use a single centralized method to access connection strings. In there depending on the site you return the correct string for the site. You could still have all the information into a single web.config but the main connection string wouldn't have the database hardcoded. It would be added later.

Depending on your code structure that may be a lot of work.

The easier way would be to store the connection strings in the root web.config rather than the web.config of your site.

You would have a single site with a single web.config but no connection string in there.

They are in:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config

or whichever framework version your application pool is using.

You can use the location node to specify different connection strings for the different sites:

<location path="Site">
    <connectionStrings>
        <add connectionString="data source=.;integrated security=true;database=Site" name="SiteCS" />
    </connectionStrings>
</location>
<location path="Site2">
    <connectionStrings>
        <add connectionString="data source=.;integrated security=true;database=Site2" name="SiteCS" />
    </connectionStrings>
</location>
<location path="Site3">
    <connectionStrings>
        <add connectionString="data source=.;integrated security=true;database=Site3" name="SiteCS" />
    </connectionStrings>
</location> 

You can do the same for other IIS and Dot.NET settings.

The downside may be that you have to be an administrator to change this settings and that if you do change them all applications pools on the server may be re-started.

  • Thanks for the idea. The issue I see here is that we balance load manually between servers by adjusting the bindings to different domains on each site. If I kept using the web.config inside the actual site folder, could I then perhaps alias out the connectiongStrings to a remote file? I could see it working that way perhaps, as long as I can specify them on a <location path="Site"> basis like you suggested here. I'll give it a shot, thanks. – jski Aug 11 '15 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.