mvcSiteMapNode.dynamicNodeProvider Atrribute: More lenient delimiter between Class and Assembly?

[refactoryourmind]

Hi,
Recently I spent some time debugging issues with a dynamic node not triggering its associated DynamicNodeProvider class. Eventually I found the problem here:

<mvcSiteMapNode title="Thing Details" action="thingDisplay" preservedRouteParameters="id,thingTitle" dynamicNodeProvider="AssemblyName.Namespace.ThingDetailsDynamicNodeProvider,AssemblyName"/>

Note the lack of space between the comma after "ThingDetailsDynamicNodeProvider," and "AssemblyName".
The result of this was that the dynamic node defaulted to its title of "Thing Details" . Breakpoints I had set in ThingDetailsDynamicNodeProvider.cs did not trigger. The failure was silent.
I resolved it by changing the dynamicNodeProvider to this:

<mvcSiteMapNode title="Thing Details" action="thingDisplay" preservedRouteParameters="id,thingTitle" dynamicNodeProvider="AssemblyName.Namespace.ThingDetailsDynamicNodeProvider, AssemblyName"/>

(Note the space between the comma after "ThingDetailsDynamicNodeProvider," and "AssemblyName".)
I think it's odd that a space would be required here when none is required in preservedRouteParameters. Wouldn't it be more effective to use both "," and ", " as delimiters between these two values?

[NightOwl888]

The string used is the standard .NET notation for specifying a type that has been around since .NET 1.0. However, it appears that Microsoft has loosened the way that the string can be specified because I know for a fact in .NET 1.0 the space was required. Now it works with no space or even 5 spaces after the comma.

There was also a limitation that strongly named types (including the version number, culture, and public key token) wouldn't match.

So the solution was to switch to matching on .NET type rather than by using the string. This requires a call into .NET reflection to convert the string into a .NET type, so I was careful to test the performance of this change and was surprised to find that it actually performs slightly better than matching strings. Here is the performance test I used (posting here for future reference).

private void TestComparisonPerformance()
{
    var providerName = "MvcMusicStore.Code.StoreBrowseDynamicNodeProvider, Mvc Music Store";
    int testCycles = 100000;
    TimeSpan test1;
    TimeSpan test2;
    var sw = new System.Diagnostics.Stopwatch();

    // Run first test
    sw.Start();
    for (int i = 0; i < testCycles; i++)
    {
        var type = Type.GetType(providerName, false);
        bool result = this.GetType().Equals(type);
    }
    sw.Stop();
    test1 = sw.Elapsed;

    sw.Reset();

    // Run second test
    sw.Start();
    for (int i = 0; i < testCycles; i++)
    {
        bool result = this.GetType().ShortAssemblyQualifiedName().Equals(providerName, StringComparison.InvariantCulture);
    }
    sw.Stop();
    test2 = sw.Elapsed;
}