What should MvcSiteMap v2.0 look like?

Apr 27, 2010 at 7:04 AM

I'm currently in the planning phase for MvcSiteMap version 2.0. Feel free to add extra feature requests, comments, ... This post will one day transform into the next version of MvcSiteMap.


- Create sitemap files in XML
- Attributed sitemap nodes for action methods
- "Dynamic" sitemap nodes (i.e. specific parameters not taken into account)
- Sitemap node discovery using MEF
- Sitemap node providers (i.e. add 1000 nodes based on database list of products)
- Sitemap groups (i.e. areas of SiteMap nodes)
- Menu helper
- SiteMapPath helper
- SiteMap helper

Open discussion questions

- Should the ASP.NET SiteMap provider model be respected? This is currently one of the biggest reasons for hacky code in some locations.
- Are you using regular ASP.NET SiteMap controls? Is there a reason why you are not using the helper methods provided?

Apr 27, 2010 at 8:20 PM

How about adding functionality to produce sitemap.xml docs (see what I've done @ http://www.isi-net.com/Blogs/Ron-Muth/How-to-use-an-ASPNET-SiteMapProvider-to-produce-a-XML-SiteMap-for-Google-Yahoo-Bing-etc) but supplement schema to add in “lastmod”, “changefreq” and “priority”


Apr 28, 2010 at 12:56 AM

I would like to see the documenation expanded and formalised. This software is quite handly, but it is way harder than it ought to be to figure out how to use it in anything beyond the simplest of scenarios. Rather than scour the forums, it woudl be good to see an FAQ or some sort of artciles page perhaps.

Of course, this needs people and time! (I'd gladly volunteer)

Feature wise, I like the sound of sitemap groups. Are you talking about the ability to give a heading to set of links - eg; a non clickable section header?


Apr 28, 2010 at 1:09 AM

I'm in two minds if this is an exisiting feature or a feature I need. The ability to change the url of a node at runtime.

My post http://mvcsitemap.codeplex.com/Thread/View.aspx?ThreadId=209542 has gone unresolved, so I have had to move on with an assumption that affecting nodes at runtime is buggy or not supposed to work in the manner I disucuss.

RE:  Should the ASP.NET SiteMap provider model be respected? 

No. You are creating new code that benefits from the ability to escape such restrictions. The only area to be mindful of here is, and no doubt stating the obvious, the need to document very clearly any deviations / enhancements.

I wonder if this duplicate URL issue can be eliminated. Or if a node can have an id by which other nodes reference a single URL.

May 7, 2010 at 5:50 PM

Needs to work flawlessly in Medium Trust environment. This should be a priority always in my book.



May 10, 2010 at 6:51 PM
  • Security Trimming
    • Support for standard role membership
    • Support for nodes that only show up when you are unauthenticated
  • Node visibility based on active (i.e. only shows in menu when you are on it)


May 11, 2010 at 3:41 PM


Add TreeView menu helper method


May 12, 2010 at 8:28 PM

I'm fairly new to MvcSiteMap, but I've gotten quite a bit of experience with it in the last few days trying to add customizations to it to enable claims-based authorization and multitenancy. I started working with the released version, updated to changeset 45766, updated again to 46314, and rolled back to 45766 due to some issues I found with the GetController method returning the controller for the current request rather than for the site map node.

Anyway, my thoughts:

  • Really nail down the SiteMapPath and other HtmlHelper methods. I've run into all sorts of weird issues like incorrect nesting, incorrect handling of selected nodes, etc. so I have to still use server controls (or write my own helper methods).
  • Ensure handling of areas is robust. When using this with a composite application, it's possible you'll have controller name overlap (two 'HomeController' implementations) and action overlap (both HomeControllers have an 'Index' action) but they differ by area. The provider currently doesn't select the proper active node in this case.
  • Refactor the DefaultMvcSiteMapAclModule so the IsAccessibleToUser isn't such a monolith. Having smaller bits that can be overridden would make it easier for consumers to implement customizations. For example, the way the "proxy" attributes are created and executed isn't flexible enough for attribute instances that have constructor parameters. Instead of using proxy classes that get built on the fly, a quick reflection call would probably be better since you already have the constructed attribute instance anyway. I could have derived/overridden the evaluation call to do this in a custom module, but I also needed the bits where role evaluation happens, etc., so I ended up doing a huge copy/paste operation, refactoring it myself, and updating basically just that one spot. It might make the ACL bits easier to test if it was refactored, too. (And I think I found some code that probably doesn't need to be in there, like the creation of the AuthorizationContext, since it's never used - it's just used for the HttpContext, which there's already a reference to.)
  • Work in Medium trust. I agree with marcusjm, above - while this isn't my primary use case, it is important. (I admit I haven't tested this in Medium trust to see if it already works or not.)
  • Respect the ASP.NET SiteMap Provider model. There are two big benefits to that:
    • First, any out-of-the-box controls that support the site map provider will also support the site map that comes out of this provider. That's huge, particularly for shops that have invested in robust third-party menu controls (maybe that don't require a server-side form) and can't/won't invest in re-implementing those robust menus in a more MVC-friendly format. (Also, if you have MVC and web forms coexisting, having the lowest-common-denominator format is really nice.)
    • Second, there's nothing really proprietary to learn. If you are a developer coming in off the street, understanding how to consume the output of the provider, how to use the provider, etc., is basically the same as any standard provider you should already know. For a small shop it's not a big deal to teach people yet-another-proprietary-way to work with site maps, but if you've got to spread that knowledge across 300 developers in a large shop... there's cost involved.
  • Native multitenancy. I may be in the minority on this one, but if you have a multitenant web UI (say, an application service provider) and one tenant wants to have the nodes show up in a different order than another tenant, the ability to register and retrieve maps on a per-tenant basis would be cool. If you're obeying the standard SiteMapProvider model, the tenant ID could be in, say, an HttpContext.Current.Items["tenantId"] key or something like that. I haven't thought it through too far, but I know I'll be having to add that sort of functionality myself and it'd be nice to see it in the base product as a supported feature.

I'm not so concerned with creating sitemap.xml files. Most of the stuff I work on sits behind some sort of authorization so it never gets indexed by a search engine.

I think that's it. Those are the gaps I've run into up until now, at least.

May 12, 2010 at 10:15 PM
tillig wrote:
  • Ensure handling of areas is robust. When using this with a composite application, it's possible you'll have controller name overlap (two 'HomeController' implementations) and action overlap (both HomeControllers have an 'Index' action) but they differ by area. The provider currently doesn't select the proper active node in this case.

I second this.  I am having this issue with a new MVC 2 app that I am building that has three HomeControllers (one in the main area and two others within two seperate areas).  When you go to the home page, the provider (and therefore menu) does not select the correct node. 

Is there anything I can do to fix this?

I also strongly agree with the "Respect the ASP.NET SiteMap Provider model" idea. 



May 22, 2010 at 5:49 PM
Edited May 22, 2010 at 5:49 PM

hey guys,

just wondering any ETA on this ? i know this is a feature feed but not having a sitemap.xml is killing me ?

is 2.0 a "1 year off" or a "1 month off" or ?

Thx :) [great proj btw - MSFT should have done this themselves!!]

Jun 8, 2010 at 5:13 PM

There you go :-)


Jun 12, 2010 at 4:09 PM

I don't plan to use the HtmlHelpers.

It isn't a big deal but separating the helpers into a MvcSiteMapProvider.Web project would be nice for those that are only interested in the sitemap functionality.

Jun 14, 2010 at 12:52 PM

I wanted to have the ability for my DynamicNodeProviders to return a CacheDependency. I added the following class in the Extensibility-Folder:

    public class CacheDescription
        public String Key { get; set; }
        public CacheDependency Dependencies { get; set; }
        public DateTime AbsoluteExpiration { get; set; }
        public TimeSpan SlidingExpiration { get; set; }
        public CacheItemPriority Priority { get; set; }

        internal void AddCache(CacheItemRemovedCallback onRemoveCallback)
            HttpContext.Current.Cache.Insert(Key, "", Dependencies, AbsoluteExpiration, SlidingExpiration, Priority, onRemoveCallback);

Then I added the following Method to the IDynamicNodeProvider-Interface:

    /// <summary>
    /// Gets a cache description for the dynamic node collection 
    /// or null if there is none.
    /// </summary>
    /// <returns></returns>
    CacheDescription GetCacheDescription();

And the following Code to the DefaultSiteMapProvider.AddDynamicNodesFor-Method before the call to RemoveNode at the end of the method:

    // Insert cache dependency
    CacheDescription cacheDescription = mvcNode.DynamicNodeProvider.GetCacheDescription();
    if (cacheDescription != null)
        cacheDescription.AddCache((key, item, reason) => { if (!isBuildingSiteMap) root = null; });

This way my DynamicNodeProvider can return a SqlCacheDependency and the Sitemap gets invalidated when the rows in the database are changed.

What do you think about it?

Jun 15, 2010 at 5:49 AM

I love this stuff! Definitely including it.