The SiteMap.SiteMapResolve event is set to cause major headaches in ASP.NET 2.0 development. Jeff Prosise talks about the need for the event in a post entitled “Cool ASP.NET 2.0 Programming Trick”. Jeff appears to be taking the wrong approach.
As ASP.NET developers we are accustomed to wiring up events to methods in our Page derived classes. However, SiteMapResolve is a global (defined as public and static) event on the SiteMap class and will fire when resolving a node for any page in the application, not just the subscribing page. Also, we aren’t used to unsubscribing to events in ASP.NET but SiteMapResolve, being a root, will hold on to any references we hand off through a delegate until the universe collapses, or the AppDomain unloads, whichever happens first.
The best solution to work with SiteMapResolve is going to involve a singleton or static class. The best solution I have so far appears to be unfortunately very messy.
Comments
I have just encountered this very problem and it is a major design flaw. The usefulness of this event would be much, however the usefulness of the event being static is almost none in any case that springs to mind including my current dilema. This is painful.
RemoveHandler SiteMap.SiteMapResolve, AddressOf Me.SiteMapModify
inside the handler?
scott, could you share with your workaround?
though i do not like anything messy.
the best way is to look for another solution not involving SiteMapResolve event.
i'm afraid this leads to writing custom site map provider
protected void Page_Unload(object sender, EventArgs e) {
SiteMap.SiteMapResolve -= new SiteMapResolveEventHandler(YOUR FUNCTION);
}