web.config inheritance

[gerry]

Is there any way to prevent web.config inheritance in nested web
applications ?

Here is the scenario, a 3rd party asp.net web application installed on an
asp.net intranet site :
http://intranet.company.org
http://intranet.company.org/3rdPartApp
both are configured as applications in IIS.
the subapp is not physcially installed beneath root app

Problems :
- the 3rd party app is completely unrelated ( functionally ) to the root
app and should never inherit any configuration settings but of course it
does.
- app relative items in the root web.config cause errors in the sub app
because of course they are app relative and the sub app can't find them -
ie. HttpHandlers
- successful installation of the 3rdparty app requires manual modification
of the web.config file to negate any problems caused by the root web.config
file

I thought that one solution might be to wrap the entire root app web.config
contents in a location tag to restrict it to just the root app - but I don't
see anyway to get this to work, location seems to only work for restricting
sub-app config with no way to restrict config to just the root app.

Gerry

 

[Steven Cheng[MSFT]]

Hi Gerry,

Welcome to ASP.NET newsgroup.

As for the ASP.NET web application, it follow the fixed inheritance rules
(from machine.config to global web.config to IIS site root to super web
applications....) and so far the ASP.NET configuration only allow uplevel
config control whether to allow downlevel config inherits the setting or
not but can not let the sub applications prevent inheriting a certain
setting (especially for buildin config section and elements). Also, as for
the HttpHandlers issue you mentioned, this is an known problem from ASP.NET
1.1 which make deploying sub applications under a root web application that
configured to use custom httphandlers a pain. Currently, based on my
research, I think for application contains custom httphandlers, if it is
the IIS site root, other sub application will have to copy the httphandler
specific assemblies in their own application bin dir also. Ideally, we
would recommend those applications be deployed in separate hierarchy.

BTW, for ASP.NET application deployment, we also need to take care of
versioning problem when we deploying both ASP.NET 1.1 and ASP.NET 2.0
applications in the same IIS site, because ASP.NET 2.0's web.config
configuration schema involves many new elements not supported by 1.1
version, we'd better not make any ASP.NET 2.0 application the super
application over other ASP.NET 1.1 application so as to avoid parsing error
at runtime.

Sorry for the inconvenience it brings you.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Steven Cheng[MSFT]]

Hi Gerry,

How are you doing on this issue, does the info in my last reply helps a
little or have you got some other approachs? Please feel free to let me
know if there's anything else we can help.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[gerry]

Hi Steven ,
thanks for the reply and sorry for the delay.

Personally I find this whole situation somewhat ridiculous.
I understand the machine.config inheritance, but the sub web inheritance
makes little sense.
especially when the sub web is defined as an iis application - doesn't this
inheritance in some ways defeat the purpose of IIS application boundaries ?

I'm not sure I understand your statement that the httphandler issue is a 1.1
related problem - how does this problem not apply to 2.0 ?

Imo , copying root web http handler assemblies into all sub webs is a very
poor solution and does not address the concern that the sub web is in fact a
stand alone application which in all likelyhood will have no relationship to
its parent and any custom httphandler functionality would be undesirable if
not detrimental.

My solution was to go into each sub web's web.config and add the
corresponding <remove /> tag to the httphandlers section for each handler
defined somewhere higher in the web hierarchy.
As well as every other section of the web.config file looking for any
'higher up' config settings that could interfere with the sub web.

I understand the statement 'Ideally, we would recommend those applications
be deployed in separate hierarchy' however i feel that this is a very
unrealistic and naive approach to this problem.
Forgive me if i misunderstand this approach, but you seem be suggesting that
this standard type of site structure:

http://www.company.web/engineering/3rdPartEngineeringApp1
http://www.company.web/engineering/3rdPartEngineeringApp2

if each level in this structure is a seperate and 'unrelated' IIS
application then this should actually be seperated into 4 distinct web sites
as such :

http://www.company.web
http://engineering.company.web
http://3rdPartEngineeringApp1.engineering.company.web
http://3rdPartEngineeringApp2.engineering.company.web

which, depending on your dns setup & requirements, could very quickly become
a major dns nightmare

This just seems to be one of those areas that was never really thought out,
or was only thought out within a very very narrow scope.

Gerry

 

[Steven Cheng[MSFT]]

Thanks for your response Gerry,

I've tried the <location> element approach and seems it can help stop the
httphandler setting from parent web to sub web app. We can use <location>
element setting to remove the certain configured httphandler for a certain
sub dir (in the parent application). For example:

================================
<configuration>
<location path="SubWebSite1" allowOverride="false">
<system.web>
<httpHandlers>

<remove path="*.hello" verb="*"/>
</httpHandlers>
</system.web>
</location>

<system.web>

.......................................

<httpHandlers>
<add verb="*" path="*.hello" type="HelloHandler, __code"/>
</httpHandlers>
</system.web>
</configuration>
=============================

In the above web.config, we configure a "*.hello" httphandler in the root
web appliation, and use <location path="SubWebSite1" .../> to prevent the
handler setting from being inherited by the "SubWebSite1" application.

So far I've tested this in ASP.NET 2.0 and it works.

Hope this helps.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[gerry]

thanks steven ,
this is a better aproach than placing the remove in each individual sub
web.config as I was doing

 

[Steven Cheng[MSFT]]

Hi Gerry,

How are you doing on this, is the <location> approach currently working in
your scenario? For ASP.NET 1.X this is still an existing problem(the
<location> approach does not work in 1.x). Anyway, please feel free to let
me know if there is anything else we can help you.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[gerry]

Hi Steven,
it works, but the pain involved is exponentially proportional to the number
of options that has to be removed rises and the number of sub webs involved.
since there doesn't seem to be much in the way of alternatives - I guess we
will have to live with it.

thanks for your help on this
hopefully this is an area that ms will be revisiting at some point to come
up with a more acceptable solution
Gerry

 

[Steven Cheng[MSFT]]

Thanks for your followup Gerry,

Yes, agree with you that it will be a big pain when there is large number
of sub applications(and the handers are configured in a quite top level app
or site root). Anyway, our dev guys did notice this and provide this
workaround in 2.0. And I think there should come more graceful and
convenient solution in future version. So I also suggest you submit this
to the MSDN product feedback center so that the dev team can rate it on a
higher priority.

http://lab.msdn.microsoft.com/productfeedback/default.aspx

Thanks again for your understanding and support to us!

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[bigdaddy2]

Steven Cheng[MSFT] je napisao/la:

Thanks for your followup Gerry,

Yes, agree with you that it will be a big pain when there is large number
of sub applications(and the handers are configured in a quite top level app
or site root). Anyway, our dev guys did notice this and provide this
workaround in 2.0. And I think there should come more graceful and
convenient solution in future version. So I also suggest you submit this
to the MSDN product feedback center so that the dev team can rate it on a
higher priority.

http://lab.msdn.microsoft.com/productfeedback/default.aspx

I just posted a suggestion to the above issue (Suggestion ID:
FDBK48126). I am having exactly the same problem (Win2003). I installed
DotNetNuke 3.2.2 in the root folder (wwwroot) because I want my company
portal to have address www.mycompany.com (top level) and not
www.mycompany.com/portal or something similar. But when I did that, my
applications, which are located in subfolders
(www.mycompany.com/MyApps/MyApp1 and so on), and are completely
independent of DNN, stopped working because of httpModules section
(this was the first error, there are probably more issues). When I
renamed DNN's (root) web.config file, then my applications worked fine,
but then DNN wasn't working, of course.

I think that this is a very big issue.