Disable web.config inheritance?

I have a content management application in the root of my website, and I’m trying to use a different app (a billing application) under a sub-folder. Unfortunately, the web.config of the root site is interfering with the sub-app.

Is there a way to just disable web.config inheritance for a sub-folder?

Update:
As linked by Stephen Burris, using the <location> tag can prevent inheritance for part of the web config, as follows:

<?xml version="1.0"?>
<configuration>
<configSections>
    ....
</configSections>
<location path="." inheritInChildApplications="false">
    <appSettings>
        ....
    </appSettings>
    <connectionStrings/>
    <system.web>
        ....
    </system.web>
    <system.codedom>
        ....
    </system.codedom>
    <system.webServer>
        ....
    </system.webServer>
</location>
<runtime>
    ....
</runtime>
</configuration>

The <configSections> and <runtime> sections will not accept being enclosed in the tag…so I guess this only does most of the job. Anybody know how to do it better?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

There is an attribute that you can use in the root web.config file to cause it not to have its contents become inherited by child applications.

inheritInChildApplications

Blog about inheritInChildApplications

MSDN article on ASP.NET Configuration File Hierarcy and Inheritance

Put the part of the config that is not for inheritance inside

<location inheritInChildApplications="false">
     <NotInheritedConfigPart/>
</location>

Config sections seem to be impossible to not inherit, but other parts of configuration can be “commented” out like this and don’t get inherited.

Method 2

If you can use 2 separate application pools, you can completely stop inheritance by using an attibute enableConfigurationOverride="false" in the applicationHost.config file as I described in this question: “Entry has already been added” – Two Separate App Pools

<add name="MyAppPool" enableConfigurationOverride="false" autoStart="true" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated" >
    <processModel identityType="NetworkService" />
</add>

Method 3

In my opinion every time I’ve struggled with this the answer ends up being effectively NO – and I’m leaving this here for my future self to find so he doesn’t waste any more time on it.

I’ve found this to be a huge problem when you just want to add something as a virtual directory inside an existing site. With a complex web.config files I’ve always just ended up giving up and moving it to a different application altogether.

Method 4

I would explicitly define all of the settings required – never assume that any setting is still set to the default value.

For example, if you’re defining a connectionString include a <clear /> tag before the <add name=... />, etc. For Membership define all of the attributes, including the cookie name. And so on.

It may make the file a bit bigger but it will definitely help you avoid the “but it worked on my box” scenario too 🙂

Method 5

I have faced this situation a few times. It seems that the parent poster’s instincts are in the ball park. I have found that adding two entries seem to have solved it—both a <location> entry.

1. Find your <system.web>…</system.web>. Wrap it with a <location path="." inheritInChildApplications="false">.

   Now check the parent site and make sure it still works.
   Check the child: does it work or give an error?

2. If you still have an error, do the same thing with <system.webserver>; wrap the same <location> tag around it.

In summary – in the PARENT:

<location path="." inheritInChildApplications="false">
  <system.web>
    ...
  </system.web>
</location>

and maybe:

<location path="." inheritInChildApplications="false">
  <system.webserver>
    ...
  </system.webserver>
</location>

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0