Sitemap randomly breaks over time

Question

I've been having some production runtime errors that I don't fully understand. This has happened to us on a couple different ASP.NET 4.0 Web Sites (shudders - yes, I know - we're porting it to MVC but that's taking some time).

First of all, we have never been able to reproduce this issue in development/QA environments. Secondly, upon deployment, the issue seems to be non-existent. Sometimes the issue manifests within a day or two of deployment and other times the deployment will be live for a month without it manifesting at all. However, once it manifests, then ANY page viewed under the web site causes the error. Lastly, this problem seemed to only come up once we migrated to .NET 4.0. We started at 2.0, a year ago upped to 3.5, and recently upped to 4.0 with this solution and most child projects.

The error: Could not find the sitemap node with URL '~/Default.aspx'.

A simplified version of our sitemap (with some names changed and uninteresting nodes removed) is as follows:

<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0">
   <siteMapNode roles="*" title="EG">
      <siteMapNode url="~/../SM/Default.aspx" title="Welcome" description="" roles="*" />
      <siteMapNode url="~/../SD/Default.aspx" title="SD" description="" roles="*" />
      <siteMapNode url="~/../SMD/Default.aspx" title="SMD" description="" roles="*" />
      <siteMapNode url="~/Default.aspx" title="Ops" description="" roles="*" >
         <siteMapNode url="~/Error.aspx" title="Error" hide="true" roles="*" />
         <siteMapNode url="~/Public/Login.aspx" hide="true" roles="*" />
         <siteMapNode url="~/Manager/LPCE.aspx" title="LPCE" description="" roles="Administrator, Manager, System, Marketer" imageUrl="~/../SM/images/icons/LF.jpg" />
      </siteMapNode>
      <siteMapNode url="~/../SDD/Default.aspx" title="SDD" description="" roles="*" />
      <siteMapNode url="~/../CCD/Default.aspx" title="CCD" description="" roles="*" />
      <siteMapNode url="~/../RD/Default.aspx" title="RD" description="" roles="*"/>
      <siteMapNode url="~/../SBD/Default.aspx" title="SBD" description="" roles="*" />
   </siteMapNode>
</siteMap>

It is registered in our web.config:

<siteMap defaultProvider="SDXmlSiteMapProvider" enabled="true">
  <providers>
    <add name="SDXmlSiteMapProvider" type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" siteMapFile="web.sitemap" securityTrimmingEnabled="true" />
    <add name="SecurityDisabledSiteMapProvider" type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" siteMapFile="web.sitemap" securityTrimmingEnabled="false" />
  </providers>
</siteMap>

And from logs I have narrowed down what causes the error is in a base class that pretty much all of our pages derive from:

private void Page_Load(object sender, EventArgs e)
{
   if(!IsPostBack)
   {
        SiteMapDataSource.StartingNodeUrl = "~/Default.aspx";
   }
}

I have confirmed in all of the SiteMaps that there is a node with url="~/Default.aspx" with roles="*" (which includes public/anonymous access), so I am very confused as to why this problem occurs.

The problems I have considered:

1. SiteMap does not have a node for Default.aspx. All of them do.
2. SiteMap's Default.aspx node is not accessible for security reasons to the current user/role. They're all accessible to anonymous users and this problem even exists for super admin users.
3. Passed-in URL contains querystrings (Default.aspx?abcd). I don't know if this is a problem (I sure would hope not) but once the problem manifests itself, I can handwrite the URL with no querystrings and the problem still exists.
4. SiteMap changes. It doesn't
5. Service's permissions to the sitemap file. The sitemap works perfectly fine after a deployment, so unless permissions are changed in a way that IISRESET fixes, then this is not an issue.
6. The worker process becomes globally corrupt. I don't think so. We have ~12 web sites all in the same app pool and the problem always stays confined within a single web site. Also, we have yet to have this happen to more than a single web site at a time although it has manifested itself in 4 different ones so far.

Can anybody shed some light on this? It almost seems as though the dynamically-compiled SiteMap gets corrupted or something. The only resolution I have found is an IISRESET or equivalent. And even then, there's no telling as to how long the problem will be resolved. This is VERY frustrating!

Answer 1

I put a previous post on this thread that got deleted :( anyhow I 'had' the same problem.

I found that no matter what I did the "Could not find the sitemap node with URL '~/rootnode" occurred. My break came when I decided to remove the file system dependency and switch to the SqlSiteMapProvider from wicked code. I found that this problem was more reliably re-created.

In short you get that message because there is no site map! I found that on the site map data source if you use the StartingNodeUrl="~/root.htm" then the error message will appear when there is no sitemap built. However if you use StartingNodeOffset="0" then the error message is not displayed and there simply is no menu rendered when the sitemap is not built.

Seemed strange to me but I traced it back to the XmlSiteMapProvider. Sometimes it built sometimes it didn't. Couldn't get my head fully under the bonnet but it looked like something happening Asynchronously. Anyhow I've switched to the SqlSiteMapProvider from wickedcode.

One change I made, aside from converting to vb was to put a recursive call on the return of the overridden BuildSiteMap method:

' Return the root SiteMapNode
If _Root Is Nothing Then
   Return Me.BuildSiteMap
Else
   Return _Root
End If

This makes sure the sitemap builds. I thought about putting an infinite recursion guard in but it doesn't seem to be required.

I'm still thinking that perhaps a network lag or some authentication (which at our place is through an AD controller, and lags first thing in the morning !!) is what is making the XmlSiteMapProvider miss it's Async build window?

Really hope this helps.

Answer 2

I have two possible ideas for this problem. Neither is guaranteed to work. ;-)

1. Is it possible that you are also using URL Authorization at the same time in some of your web.config files located in various folders throughout your web application?

   Example URL Authorization setting that could be found in one web.config file:

   <location path="bobsSecret.aspx"> 
       <system.webServer> 
           <security> 
               <authorization> 
                   <remove users="" roles="BobAndFriends" verbs="" /> 
                   <add accessType="Allow" users="Bob" />          
   
               </authorization> 
           </security> 
       </system.webServer> 
   </location> 
   

   The reason I mention this is I had some trouble in the past trying to get the roles property in my sitemap XML file to work correctly with the settings I had applied in my URL Authorization in a web.config.

   The only thing I could imagine would be some sort of race condition where the process responsible for enforcing these policies is reading one security setting in one place (web.config) before reading it in another place (web.sitemap).

   Just a stab in the dark, based off some past issues I had experienced!
   
   

2. As a second option, you could consider putting this configuration in your aspx page instead of in the Page_Load event on the code behind. You could try this:

   <asp:SiteMapDataSource
       id="SiteMapDataSource1"
       runat="server"
       StartingNodeUrl="~/Default.aspx">
   </asp:SiteMapDataSource>
   

   This way your StartingNodeUrl is specified in the ASPX page itself, and if this is truly an intermittent bug in the Framework code, perhaps this slight change might fix the problem.

Answer 3

Hmm. Its been a couple of years since I worked with ASP.net, but if I recall, I had a similar problem which I solved with

Page.ResolveURL("~SomePage.aspx");

At runtime the sitemap urls are resolved to the actual url, so the tilde is removed and replaced with the actual URL (I think :) ).