v4.6.8

Change Log

1. Bug: Fixed the SiteMap.FindSiteMapNode(rawUrl) method so it will search both the URL-based nodes and route-based nodes. Previously it only worked for URL-based nodes.
2. Bug: Fixes #336, menu not visible when current page is null and using a level-based menu.
3. Bug: Fixes #335, added null check for query string keys because there are cases where the key will be null (patch for #332).

v4.6.7

Change Log

1. Bug: Fixes #332, configured query string values not taken into consideration in the node matching.
2. Feature: Closes #324 and #328, added support for Grace DI container.

v4.6.6

Change Log

1. Bug: Fixes #322, "multiple nodes with same URL" exception when using a custom URL resolver.

v4.6.5

Change Log

1. Bug: Null reference exception when navigating to pages not configured in the sitemap, caused by lack of null checking in the patch for #310.

v4.6.4

Change Log

1. Enhancement: Closes #308, performance improvements in SiteMapHierarchyBuilder that make loading the SiteMap into the cache faster, especially notable on SiteMaps with large numbers of nodes (thanks @cpswizard).
2. Bug: Fixes #318, filtered null types from the assemblies returned from the MvcSiteMapNodeAttributeDefinitionProvider.GetTypesFromAssembly() method.
3. Bug: Fixes #316, security trimming not functioning with AttributeRouting and MVC 5.1.x.
4. Enhancement: Changed default Menu template to include the CSS classes for the default MVC5/bootstrap project template.
5. Bug: Fixes #310, equality check causing node mismatches when the cache is rebuilt, causing failures when using multiple HTML helpers.

v4.6.3

Change Log

1. Fixes #305, exception thrown when using visibility as a custom attribute in conjunction with MvcSiteMapNodeAttribute.

v4.6.2

Change Log

1. Bug: Changed output directory location of NuGet packages to /release/packagesource/ to fix problem caused by version 2.8 of NuGet Package Manager when attempting to install the packages from a local directory. See https://nuget.codeplex.com/workitem/4045 for complete details.
2. Enhancement: Changed the build script to backup CommonAssemblyInfo.cs and then restore it again so it won't cause Git to think it has changed after a build.
3. Enhancement: Changed the build script to use the current year on the build server as the copyright year so it doesn't need to be changed manually every year.
4. Bug: Fixes #296, updating causes MvcSiteMapProvider_IncludeAssembliesForScan setting to be duplicated in web.config.
5. Bug: Fixes issue described at http://stackoverflow.com/questions/22708773/mvc-sitemap-couldnt-be-found-exception, exception when setting MvcSiteMapProvider_EnableSiteMapFile to false and then deleting Mvc.sitemap because the internal DI container was still attempting to use it to load IDynamicNodeProvider, ISiteMapNodeVisibilityProvider, and ISiteMapNodeUrlResolver instances.
6. Bug: Fixed default value of ChangeFrequency and UpdatePriority properties of SiteMapNode and MvcSiteMapNodeAttribute so they default to "Undefined". This was causing 0.0 to always appear in the /sitemap.xml endpoint for nodes that were configured with MvcSiteMapNodeAttribute.
7. Bug: Removed extraneous call to FindSiteMapNode from the FindSiteMapNodeFromKey method because it would cause confusing results if the key were explicitly set to a URL. This will improve performance for this method call.
8. Bug: Fixes #304, UrlPath.IsAbsoluteUrl method was misidentifying the URL as absolute when it contained an absolute URL in the query string, such as when using ASP.NET error pages.

v4.6.1

Possible Breaking Change - 1 of 2

Who is Affected?

This affects you if you are using a custom or 3rd party implementation of ISiteMapNodeProvider.

What Could Break?

The ISiteMapNodeProviders are now being run in the invariant culture. Meaning System.Threading.Thread.CurrentThread.Culture and System.Threading.Thread.CurrentThread.UICulture are being set to System.Globalization.CultureInfo.InvariantCulture before running ISiteMapNodeProvider.GetSiteMapNodes() and it is restored to the original culture settings just after this method call is complete.

This can affect several things including DateTime.MinValue, DateTime.Parse, String.Format, and various other methods, particularly if they have an overload that accepts a formatting or culture object.

How Do I Fix It?

You can fix this by thoroughly testing each string and DateTime formatting method call within your ISiteMapNodeProvider implementation, and adjusting for any problematic formatting.

We recommend you do the formatting in the context of the invariant culture, if possible. But if all else fails or you simply run out of time you can revert back to the user's original culture by using this code.

// Do formatting in the invariant culture context

using (var originalContext = helper.CreateCultureContext(helper.CultureContext.OriginalCulture, helper.CultureContext.OriginalUICulture))
{
    // Do formatting in the user's original culture context
}

// Do more formatting in the invariant culture context

Important: Be sure to always use the invariant culture when calling helper.CreateNode and if making a call to DateTime.MinValue.

Possible Breaking Change - 2 of 2

Who is Affected?

This affects you if your URLs depend on the "ambient value" behavior of MVC to pull non-configured values into the URL. For the most part, this behavior is undesired. More information about this behavior is here, here, here, and here.

What Could Break?

The URLs will no longer include these non-configured ambient values from the user's request.

The default behavior has been changed to ignore these "ambient values" from the current request when building the URLs because this essentially makes the generated URLs unpredictable and highly dependent on the URL that is specified by the user. It also makes it impossible to cache the resolved URL because it may or may not contain user information.

How Do I Fix It?

This behavior can be re-enabled by setting the includeAmbientValuesInUrl attribute or property of the SiteMapNode to "true".

Change Log

1. Bug: Fix for #293, AuthorizeAttribute now functions when setting the Url property or attribute of the SiteMapNode.
2. Bug: Fix for #292, use invariant culture during construction of the SiteMap so reading the files and setting the defaults works the same regardless of the culture of the user that causes the SiteMap to be built. Breaking Change If you have a custom or 3rd party implementation of ISiteMapNodeProvider, be sure to check to ensure that your implementation works when both the culture and UI culture are the invariant culture. IDynamicNodeProvider implementations are not affected, but we recommend that you migrate them to use the invariant culture to prevent issues from arising, especially if your site supports multiple cultures.
3. Housekeeping: Removed duplicate MvcSiteMapProvider.xsd files from the demo/test projects so there is only 1 copy to maintain. Added a note to change the namespace if copying the Mvc.sitemap file into another project.
4. Bug: Fix for #213, by default we no longer allow MVC to inject "ambient values" from the request into the URL. This was causing issues with user information being stored in the shared cache and affecting the URLs other users. Breaking Change The default behavior has changed to not allowing these ambient values in the URL. More information about this behavior is here, here, here, and here. If your application relies on this behavior, it can be re-enabled at the SiteMapNode level by setting the includeAmbientValuesInUrl attribute/property to true. When re-enabled, the resolved URL caching will be automatically disabled for the node. There is no SiteMap wide setting because it seems extremely unlikely that most developers are even aware of this behavior, much less have an application that depends on it (most people simply want it to go away).
5. Feature: Support for specifying to use absolute paths in the Url, CanonicalUrl, and ImageUrl. This can be done by specifying the corresponding Protocol and/or HostName properties. The protocol supports using * to specify to use the protocol of the current request (except for ImageUrl which always uses the protocol of the current request). These Protocol and HostName properties of the main Url work when using routing or when using an explicit Url by setting the Url property.
6. Bug: Fix for matching on nodes when an absolute URL is set to the Url property.
7. Bug: The HTTP_HOST server variable is now consistently preferred over HttpContext.Current.Request.Url to get or match the host name of the web site. This ensures it will correctly support cloud and web-farm environments.

v4.5.2

Change Log

1. Bug: Fix for #289, MvcSiteMapProvider.Web NuGet package was failing to add appSettings, system.web, system.web.webPages.razor, or system.webServer nodes to the web.config file if these nodes are missing, because it was attempting to attach them in parallel to the configuration (root) node rather than as a child node.
2. Bug: Fix for exception being thrown by the Menu when the current node is null (indicating that it couldn't be matched).
3. Bug: Nodes set with an explicit URL or with clickable="false" were matching on route values even though they didn't apply. This made non-clickable grouping nodes declared with MvcSiteMapProviderAttribute match a route that was intended for another action, with no way to force them not to match. IMPORTANT: This change could break your application if you rely on a non-clickable (clickable="false") grouping node being set as the current node. This didn't seem to make much sense because a direct navigation path is blocked and the node really shouldn't be made to match a URL and/or route in this case, but if your application depends on this behavior feel free to open an issue and make your case.
4. Bug: Fix for #291, no exception thrown when a dynamic node provided didn't match any registered type. Also changed the logic to match dynamic nodes, visibility providers, and URL resolver using a .NET type match rather than string match, so different variations of .NET type strings can be used without affecting the match.

v4.5.1

Important Manual Update Required for External DI Modules

If you installed v4.5.0 into a project for the first time (or you uninstalled and reinstalled) AND you installed one of the MvcSiteMapProvider.MVC[x].DI.[ContainerName] packages, you probably did not get the important update that it included. This release fixes the NuGet package logic, but unfortunately the damage has already been done on your project and some manual updating is required.

You can check whether you got the update by looking at the packages.config file in your project. It should include MvcSiteMapProvider.MVC[x].DI.[ContainerName].Modules that is the same version as MvcSiteMapProvider.MVC[x].DI.[ContainerName]. If you didn't get the update, the modules package will likely be 4.4.14, which was out of date at the time you installed MvcSiteMapProvider.

NOTE: You don't need to do this if you already did the manual update when you installed v4.5.0.

Getting the Update

Option 1

The safest way to fix this is to see the diff in commit 3772c22b6873d269f5d941d55af9940cb5c3b512 and use it as a guide to manually update your DI module. You only need the one for the DI container you are using.

You will also need the CommonConventions.cs update which you can also see the diff in commit 4810c7c98660a5aeb3c375a242231f2e0cf78577. If you are sure you have not updated the file, it may be easier just to copy and paste the entire contents of the file.

Option 2

A more brute force way to apply the fix is to use the following package manager console command to update your modules package. This will overwrite any customizations you have done to the DI module or other startup code, so making a backup is highly recommended.

PM> Update-Package MvcSiteMapProvider.MVC[x].DI.[ContainerName].Modules -Version 4.5.1  -IgnoreDependencies -FileConflictAction Overwrite

Change Log

1. Bug: Fix for NuGet dependencies not being installed past 4.4.14 in new projects (for DI packages and MvcSiteMapProvider.Web).
2. Bug: Fix for NuGet package to prevent MVC 5 packages from being automatically upgraded to MVC 6 when it is released. IMPORTANT: If you are using MVC 5, be sure that you have this version or later installed when MVC 6 is released.
3. Bug: Fix for #278, #181, and #9, AuthorizeAttributeAclModule interfering with IIS rewrite module intermittently by removing URL rewriting approach and replacing it with an instance of HttpContext that is made specifically for the node being checked.
4. Bug: Fix for #280, "Multiple nodes with the same URL". The check has been removed entirely from MVC nodes because there are instances (such as when using HttpMethod) where there may be duplicate URLs.