Here’s a missing piece of functionality that’s frustrating me right now:
Basically, XmlDocument has a virtual property called BaseURI that subclasses can override to provide the base URI (go figure) from where the XmlDocument instance was loaded. In a normal XmlDocment, if you call the Load override specifying the “filename” parameter, it will set it’s BaseURI to that. Also, if you Load the instance from an XmlReader that has it’s BaseURI set it will inherit that. Anyway, my point is, the support is there in the base XmlDocument class.
Now we come to ConfigXmlDocument, which subclasses XmlDocument to provide special behavior for loading .NET application configuration files. Guess what it doesn’t populate? You got it: BaseURI.
Next imagine you write a custom configuration section handler that parses an XML fragment inside of the configuration document and wants to allow people to use relative paths within the definition of that fragment. Now guess what the paths become relative to: the assembly of the configuration section handler.
So I’ve written a library which is now being used inside of an ASP.NET application. While the web.config is in the root of that application, people have to counter intuitively make any relative paths inside of that configuration section fragment relative to the /bin directory as opposed to the root. FWIW, the same thing happens with any Console and WinForms applications as well. Frustrating to say the least.
I’m going to check if this has been remedied in Whidbey and, if not, post a request to LadyBug to get it done. I see no reason why this should not be implemented.
Update:
I tested it in Whidbey and the results are unfortunately the same. I have submitted a bug, so if you find this important go ahead and vote for it.