Asked By David Wang
06-Feb-08 11:05 PM
Locking is a behavior of the underlying IIS7 configuration system. You
can look at the <modules> collection to see how items are locked.
You can view the IIS7 Manager UI as an application implementing IIS-
related workflows on top of this configuration system, abstracting it
away.Thus, it focuses on the workflows of IIS, and not the details of
how to do that in the IIS7 configuration system. Thus, concepts like
locking are a means to achieve a behavior and not worth exposing in
the UI. There is no glorified UI editor for the .config configuration
system.
Of course, I have already made clear that there are many prior IIS6
behaviors that are emulated in IIS7 config, but you can easily do more
things in IIS7 (like insert <clear />) to get behavior that was never
possible in IIS6. That is just the price one pays for legacy support
in the new, delegated way of doing things in IIS7.
Here is how to think about things.
- IIS7 configuration system has a natural inheritance hierarchy which
flows from machine.config to applicationHost.config to web.config
[nesting]
- Collections are just a grouping of multiple elements
- Thus, if you define something in a collection defined high up in the
hierarchy (like applicationHost.config), it is naturally inherited by
child web.config or event location-tags (location tags are a
complication to things - ignore it for now). This is great for the
Configuration-Reading scenario. But what about the Configuration-
Writing scenario?
- Enter "overrideMode", which controls whether that section can be
- overrideMode is great for things like defaultDocument because it
means that you can define a default "DefaultDocument" list in
applicationHost.config that applies everywhere by default, and if you
allow overrideMode, it allows children websites/applications to also
alter this inherited value. This is delegation at the core.
- Everything looks good until you look at handlers and modules
collections. It is a design goal to allow people to add their own
handlers/modules for their websites so that they get custom behavior,
so overrideMode should be allowed in those scenarios so that the child
web.config can edit the collection. However, since those collection
literally define how IIS processes requests and hence its behavior, we
want to always ENSURE that certain modules/handlers are always present
in the collection.
- Enter "Locking" for the item, which controls whether that element
can be removed or not at the child level
- Thus, with both overrideMode=3Dallow and LockItem for specific
collection elements, an administrator can delegate configuration for
child web.config to edit as well as constrain which collection
elements must always be present.
- Of course, this flexibility can be further tweaked with <location>
tags, but that's a separate complication that I'm not going to get
into at this point.
So, to clarify your questions:
- There is not such thing as "lock to prevent inheritance"
- Inheritance direction and scope is defined within the section
definition of applicationHost.config and usually proceeds logically,
from parent to child
- Inheritance automatically happens. Child can ignore inheritance with
lockItem
Thus, if you want the behavior that global ISAPI Filters are always
present and cannot be cleared/ignored by the child, then you should
lockItem it at its definition in applicationHost.config
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Jan 24, 5:31=A0pm, -kinetic <kine...@>
I
ing
nge
ow
te
on
it.
it
level
at the
ks fine.
he
onger
e case
orking
ry
at
ty
if
t
t
al level,
ing happened
lters, thus
ce
nheritance
ike there's a
o predict
on for that.
out, and
the
will
that
will
ith
tion....
stake
lter.. =A0My team
systems, but
We are aware of
n though it is
considerably
or not.
.exe process
racing but
dll. =A0How
me if the DLL
y filters the
equest Tracing,
nothing about
's installed
e is needed to
er of the
ault..
o the
S6, and
ent log
filter
gnose_an....
get ISAPI
and if it
obably the