The name and the path.
There are plenty of descriptions of these properties but the most important thing to note is that when combined they form the xpath used to locate the node on which to operate.
Therefore, the following 2 examples have the same effect.
This is because when the name and path attributes are combined they result in the same xpath.
configuration/system.web/httpHandlers/add[@verb='*' and @path='*.asmx']The reason I am stressing this so much is that I've noticed lots of complaints about how the sequence attribute does not appear to affect the order in which the modifications are applied. This is because the sequence attribute is only taken into account when the names of the modfications are the same. This isn't much use. This means that if I try to insert the following lines into the web.config
<clear />it would always appear
<add verb="*" path="*.asmx" />
<add verb="*" path="*.asmx" />because alphabetically the names are
<clear />
add[verb='*' and path='*.asmx']Because the names are different the sequence would be ignored and the modifications would be applied alphabetically. Therefore adds would come before clears and removes would be last.
clear
That sucks!! But help is at hand. Now that we now the name attribute just forms part of the xpath to locate the element in the web.config file we can use this to our advantage.
The earlier examples formed the xpath
configuration/system.web/httpHandlers/add[@verb='*' and @path='*.asmx']Well lets alter this example (or will we). If we add a condition to httpHandlers but make sure it always equates to true, the xpath would return the same node but the name used in the WebConfigModification construct would be slightly different.
configuration/system.web/httpHandlers[1=1]/add[@verb='*' and @path='*.asmx']The condition always returns true and will be ignored but lets look at how this changes the code.
The names are now (in alphabetic order)
httpHandlers[1=1]/clearhttpHandlers[2=2]/add[@verb='*' and @path='*.asmx']and a therefore will be applied as wanted/expected.
<clear />
<add verb="*" path="*.asmx" />
6 comments:
Using this technique, the web.config modifications are stored in the correct order; however, there’s an issue when trying to remove the modifications. The modifications are removed from the database when using SPWebConfigModification.Remove(), but the web.config is not updated. Have you experienced this issue?
For some reason this did not work for me. I had to still leave the path correct otherwise the new element would not a child of the right parent. To get it to work I changed the name to go to the parent and then to the element it should be under. Like:
name="parent::httpHandlers[1=1]/remove[@path='*.asmx']"
Great post. But the xpath value in your code didn't work for me. I had to change it to:
SPWebConfigModification modification = new SPWebConfigModification(name, "configuration/system.web/httpHandlers");
Have you been able to get this to actually work? I've tried it with EnsureChildNode and it does not place the elements in the expected place.
I can tell you that I never post anything that I haven't implemented with one exception (Execute entire page with elevated privileges).
What I'm highlighting here is the use of a contidition that always equates to true to facilitate ordering of the WebConfigModifications. The exact xpath needed will vary depending on what you are trying to acheive.
name="parent::httpHandlers[1=1]/remove[@path='*.asmx']"
this works not correct for remove and not check for present in the web.config.
Change to:
../httpHandlers[1=1]/remove[@path='*.asmx']"
and works fine.
Post a Comment