Location Path in web.config?

Topics: Controls
May 25, 2012 at 7:00 PM
Edited May 25, 2012 at 7:01 PM

I'm updating my blog to and having a difficult time getting the location path to work properly. In I just added the following:

<location path="." inheritInChildApplications="false">

It worked as expected, my child application worked fine. Now when I add it to the web.config in it works, but it breaks the logins and any sub directories that BE may create (child blogs, for example). I changed the line to the following:

<location path="~/subfolder" inheritInChildApplications="false">

Which allows the child app to work, as well as allows me to log in and view any sub directories, but when I got to the blogs default page, I get this:

  Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: Unknown server tag 'blog:PostPager'.

Source Error:

Server Error in '/' Application.

Parser Error


Line 8:  
Line 9:  <div style="clear:both; display:block">
Line 10:   <blog:PostPager ID="pager1" runat="server"></blog:PostPager>
Line 11: </div>

Source File: /User controls/PostList.ascx Line: 10

Anyone have any idea as to how to fix this?

May 27, 2012 at 11:29 AM

I have a feeling that the original syntax you used is the correct one.

<location path="." inheritInChildApplications="false">

I tested your 2nd one and received errors about the RoleManager feature not being enabled, when trying to access any page on the blog.  This is because with the 2nd one (path="~/subfolder), that means everything that is defined within that <location> block (system.web, etc) only applies to ~/subfolder ... which is not what you want -- we really want the opposite of that.  i.e.  you want everything in the <location> block such as the settings defined in system.web to apply to all the folders (except for your child application).

I think path="." is correct because it means the settings should apply to all folders.  And the inheritInChildApplications="false" part is the "exception" part saying that even though it should apply to all folders, it should not propagate down to child applications.

So I think you should go back to the first one (path=".").  You said that with this one in BE it "breaks the logins and any sub directories that BE may create".  If you could elaborate here on what is breaking, and if we can fix that, I think this is the best way to resolve this.

FWIW, with the <location path="." inheritInChildApplications="false"> tag on my development machine with, I'm not seeing anything breaking (sub directories, logins, child blogs, etc).  So I think it should be possible to use this, and it's probably something that needs to be adjusted on your end in order for it to work.

Jun 5, 2012 at 1:10 PM
Edited Jun 5, 2012 at 1:10 PM
BenAmada wrote:

FWIW, with the <location path="." inheritInChildApplications="false"> tag on my development machine with, I'm not seeing anything breaking (sub directories, logins, child blogs, etc).  So I think it should be possible to use this, and it's probably something that needs to be adjusted on your end in order for it to work.

Ben, thanks for the reply. Can you share where you placed the <location path="." ...> in the web.config file and where you're closing it. I have it placed after line 70 like so:

	<location path="." inheritInChildApplications="false">

I close it at the very end:


Using that, all of the blog's pages (sub directories) work fine and my child application works fine. However, when I try to go to the login page, I get this error:

HTTP Error 500.22 - Internal Server Error

An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.
So I have it working other than the Admin section.
Jun 5, 2012 at 2:44 PM

It turns out that I'm getting the same error you are on the Login page, when using the <location> tags.  I probably didn't try going to the Login page.

I actually used two sets of <location> tags.  One wrapping the <system.web> section and another one wrapping the <system.webServer> section.  However, regardless if I do this, or use one <location> tag like you are doing, I'm seeing the same 500.22 error you are getting.

There are a couple of solutions for this problem described here:

I tested the first solution and that eliminated the error for me.  In the <system.web> section, I deleted the entire <httpModules> and <httpHandlers> sections.  These are not needed in an Integrated mode application pool.  Instead the <modules> and <handlers> defined in the <system.webServer> section are used.  Solution #2 in the above link also looks like it would work.  I thought solution #1 was slightly easier to do, so went with that.

Jun 5, 2012 at 3:36 PM

Thanks again Ben!! That seems to have fixed it!

Any chance that this fix could be permantely added to the next build to save others from smashing their heads against their monitors?

Jun 5, 2012 at 4:02 PM

Glad to hear it worked for you too.

We can look at making this change.  It only affects those using the location tag with the inheritInChildApplications attribute.  More importantly, the <httpModules> and <httpHandlers> sections are needed if someone is running in a Classic mode app pool.  I'm not sure however with the current version of BE if it can run in Classic mode, or if it needs Integrated mode.  If it needs Integrated mode, then we could remove the <httpHandlers> and <httpModules> sections since they would never be used.  But it's possible BE does run in Classic mode.  In this case, it would be better to keep these 2 sections in there as they are needed in Classic mode.  Although integrated mode is better than classic mode in general, there are certain situations people are in (their website is running other applications, etc) where they may need to be in classic mode.  Assuming BE does work in classic mode, there's probably more people that need to be in classic mode than need the location tag with the inheritInChildApplications attribute.  So we may need to keep these sections in there.

Jun 5, 2012 at 4:16 PM

Totally understand. I'll just keep this discussion bookmarked for future reference.

Now to download the latest source that fixes the Online Gallery issue and then update my blog! Thanks again for the help Ben!!

Nov 10, 2012 at 7:29 AM

Ben and MGD_King,

Thanks for this solution.  I have been struggling with this for a few days now.  I was running 2.0 and updated to 2.7.  I run a child application and I was having the same and similar issues.

I went with solution 2 from the above link.   My web.config looks like:

    <validation validateIntegratedModeConfiguration="false"/>
  <location path="." inheritInChildApplications="false">
      <!-- <validation validateIntegratedModeConfiguration="false"/> -->
      <modules runAllManagedModulesForAllRequests="true">
        <add name="WwwSubDomainModule" type="BlogEngine.Core.Web.HttpModules.WwwSubDomainModule, BlogEngine.Core"/>

Then just to test, I switch from integrated mode to classic mode and from what I can tell everything is functioning as expected.

Thought you might want to know.

Thanks again!


Nov 10, 2012 at 12:14 PM

Guy, I'm curious as to how this works for you. Are you able to see your child blogs, posts, and comments in your admin panel after adding the location path to your web.config?

Nov 10, 2012 at 3:50 PM


Well....No.  I guess I didn't do enough verification before posting my response.

Using firebug I see the the below errors when trying to load post, comments, etc. in the admin panel

GET admin.res.axd 404 Not Found thenetheryfamily.com 1.2 KB
POST LoadComments 500 Internal Server Error thenetheryfamily.com 91 B

The common thread on all pages is the admin.res.axd 404 Not Found.

Guess I will try option 1??

Nov 10, 2012 at 6:22 PM

Option 1...same result.

Everything else seems to work as expected except for the admin stuff.

Have you found another workaround? 

Do any of the Guru's have any input?

Nov 10, 2012 at 8:18 PM

To clarify, the parent application is BE.NET 2.7 and the child application is something else.  The web.config changes you made are in the parent BE.NET web.config file.

Do you need to run the application pool in classic mode, or can you run in integrated mode?  If you can run in integrated mode, then in the BE.NET web.config file, I would delete the entire <httpModules> and <httpHandlers> sections.  In general, integrated mode is preferable (not necessarily for BE.NET, but ASP.NET in general). 

Also, regardless of the application pool mode, if you haven't already, I would also wrap the <system.web> section in the <location> tag too to make sure any system.web settings are not propagating down to the child application.

A last resort option which is probably better to avoid and not necessary if you get the <location> tags setup right etc, is to not use <location> tags and instead in the child application's web.config file, you can <remove ...> BE.NET modules and other settings.  In this scenario, you remove the <location> tags and then try running the child application and see what errors you get.  For example, one possible error is "cannot load WwwSubDomainModule".  You address that by adding <remove name="WwwSubDomainModule" /> into the child web.config's <modules> and/or <httpModules> section.  The main problem with this approach is you may need to add a bunch of removes including to other sections of the web.config file which may not have a simply <remove> option available.  So ideally trying to get the <location> tags working is the better option.

Nov 11, 2012 at 1:48 AM

I did make the settings in the parent site, BE, and not to the child site.  I ended up removing the <httpModules> and <httpHandlers> sections.  Or going with option one from the above link.  After being away for several hours everything is working as expected now.

I think what may have happened is....I was logged in to the site when I made the changes to the web.config file.  I then recycled but on browser side I did not have to log back in to the site.  So, perhaps my old session didn't know how to manage the new settings.  Hope this makes sense. 

Nuts and bolts as of now all is running.  I can go to the admin panel see my post, pages, users, etc.  where before I could not.

Perhaps the real issue here lies between my chair and the keyboard!


Nov 12, 2012 at 3:11 PM

I finally figured out why it would work sometimes and not others...I was inadvertently accessing the site via http://localhost/thenetheryfamily rather than http://thenetheryfamily.com.  when accessing via localhost I would get the admin.res.axd 404 Not Found errors.

MGD_King per your request I have email my web.config file to you.