Releases: maartenba/MvcSiteMapProvider
v4.4.2
v4.3.1
Important Manual Update Recommended for DI Modules
If you installed v4.3.0 into a new project 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.0.17, which was out of date at the time you installed MvcSiteMapProvider.
The safest way to fix this is to see the diff in commit 425c15cdfef7ee70b3226845daf2f91c8d3d7f12 and use it as a guide to manually update your DI module. You only need the one for the DI container you are using.
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.3.1 -IgnoreDependencies -FileConflictAction Overwrite
Change Log
v4.2.1
v4.1.2
v4.4.1
Important Manual Update Recommended for DI Modules
If you installed v4.4.0 into a new project 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.0.17, which was out of date at the time you installed MvcSiteMapProvider.
The safest way to fix this is to see the diff in commit 425c15cdfef7ee70b3226845daf2f91c8d3d7f12 and use it as a guide to manually update your DI module. You only need the one for the DI container you are using.
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.4.1 -IgnoreDependencies -FileConflictAction Overwrite
Change Log
- Bug: Fix for #233, web.config format changes when installing.
- Bug: Fix for #234, upgrading updates Web.config package.
- Bug: Fix for #222, sitemaps index page links broken when hosted in sub-application.
- Bug: Fixes problem with new DI NuGet package installation not installing the most recent version of modules.
v4.4.0
Important Default Behavioral Changes
Default HTTP Method
The HttpMethod property of the SiteMap node is used to determine which Action method to use to determine whether or not the user has access. Previously, the default was set to * (or the current request). This behavior doesn't make sense because the default HTML helper code always creates hyperlinks, which do a GET.
Therefore, the default is now to use GET. That is, the AuthorizeAttribute of the Action method that uses HttpGet will be the one that is used to determine whether the user should has access to the node.
This value can still be overridden by setting the httpMethod property of the SiteMap node. The only reason why you might want to change it is if you alter the HTML helpers in some way that causes them to use POST or another HTTP method, which will likely be edge cases.
Node Property Validation
The following validation is now being done on the SiteMap node, and if validation fails you will receive a detailed exception message. Keep this in mind when upgrading, as you might need to fix your node configuration (although it should be pretty unlikely).
- Title is required
- Controller + Action or URL is required
- HttpMethod must be a valid value (or not set)
- RouteValues cannot have the same key as PreservedRouteParameters for the same node
- RouteValues cannot have the same key as InheritedRouteParameters for the same node
Change Log
- Bug: Fix for #230, default value of HttpMethod should be GET.
- Bug: Deleted UrlResolverException because it is never thrown.
- Feature: Changed the URL resolution so it will support the ~/ syntax when setting the Url property.
- Bug: Fix for #222, sitemap links broken when hosted in sub-application.
- Bug: Deprecated overloads of IXmlSiteMapResultFactory that don't include a page number because using them could cause the /sitemap.xml endpoint to stop working when the site reaches 35,000 nodes.
- Feature: Added validation to ensure required node properties are set and that conflicting properties are not used simultaneously.
- Bug: Fix for #231, projects using MvcSiteMapNodeAttribute that have a different project name from assembly name get assigned a value for area when areas are not being used.
- Enhancement: Deprecated AreaName property and created Area property on MvcSiteMapNodeAttribute to be used instead (for consistency with the rest of the project).
v4.3.0
This is the most significant release since 4.0.0. There are some behavioral changes to be aware of and some manual updating of configuration code is highly recommended (but not required) if you are using an external DI container.
Important Default Behavioral Changes
Orphaned Node Detection
Up until this release, you could declare nodes as MvcSiteMapProviderAttribute or Dynamic Node Providers that specified a ParentKey that doesn't exist and you would neither see the orphaned node in your HTML helpers or get an error.
This has changed. We now use logic that ensures your configuration is valid or it will throw an exception. The exception message contains detailed information about which nodes could not be added to the sitemap as well as where they originated from.
When upgrading, you should take this into consideration, as you might need to spend some time fixing orphaned node problems.
XML Nested Dynamic Node Provider Processing
The default logic of processing nested DynamicNodeProviders in XML has changed. Take the following XML for example:
<mvcSiteMapNode title="VendorDetails" dynamicNodeProvider="MyNamespace.VendorDetailsDynamicNodeProvider, MyAssembly">
<mvcSiteMapNode title="VendorAPIDetails" dynamicNodeProvider="MyNamespace.VendorAPIsDynamicNodeProvider, MyAssembly">
<mvcSiteMapNode title="VendorAPITableDetails" dynamicNodeProvider="MyNamespace.VendorAPIVirtualTablesDynamicNodeProvider, MyAssembly"/>
</mvcSiteMapNode>
</mvcSiteMapNode>Up until this release, the logic would first call VendorDetailsDynamicNodeProvider. For each node that was returned from that provider, VendorAPIsDynamicNodeProvider would be called one time and then it would be called one final time at the end. In short, it would be called N + 1 times.
In turn, the VendorAPIsDynamicNodeProvider would call the VendorAPIVirtualTablesDynamicNodeProvider N + 1 times. So for example if our VendorDetailsDynamicNodeProvider returned 10 nodes, and our VendorAPIsDynamicNodeProvider returned 10 nodes, VendorAPIsDynamicNodeProvider would be called 11 times, and VendorAPIVirtualTablesDynamicNodeProvider would be called 111 times.
This behavior was clearly broken, and the default logic now calls each DynamicNodeProvider 1 time per declaration in the XML whether they are nested or not.
In other words, the above configuration will produce exactly the same result as this one.
<mvcSiteMapNode title="VendorDetails" dynamicNodeProvider="MyNamespace.VendorDetailsDynamicNodeProvider, MyAssembly"/>
<mvcSiteMapNode title="VendorAPIDetails" dynamicNodeProvider="MyNamespace.VendorAPIsDynamicNodeProvider, MyAssembly"/>
<mvcSiteMapNode title="VendorAPITableDetails" dynamicNodeProvider="MyNamespace.VendorAPIVirtualTablesDynamicNodeProvider, MyAssembly"/>If for some reason you managed to get an application working with that anomalous behavior and it now requires it, there is a web.config setting MvcSiteMapProvider_EnableSiteMapFileNestedDynamicNodeRecursion that can be used to re-enable it. If you are using an external DI configuration, this setting can be found on the constructor of the XmlSiteMapNodeProvider and is named useNestedDynamicNodeRecursion.
We don't recommend using this setting unless you absolutely require it, and even then we highly recommend you either move your recursion logic inside of a DynamicNodeProvider or you change your application so it doesn't require recursion at all (it could probably perform much better than it does). This configuration setting will likely disappear in a future major release.
Important External DI Configuration Update
There is a major design change in this release to fix node processing order problems, but to avoid breaking backward compatibility some existing features were deprecated instead of removed. That means you don't have to do this, but we highly recommend you do or you won't be taking advantage of the latest bug fixes or future updates to the code.
Please see the diff in commit 425c15cdfef7ee70b3226845daf2f91c8d3d7f12 and use it as a guide to update your DI configuration.
SiteMapPreserveRouteDataAttribute Deprecated
The SiteMapPreserveRouteData attribute has gone the way of the Dodo bird. After careful analysis, it was determined that this attribute has no useful purpose. It is scheduled for removal in v5.
The recommended alternative is to use the preservedRouteParameters collection of the SiteMap node. For a detailed look at how to make this work, read How to Make MvcSiteMapProvider Remember a User's Position.
Change Log
- Bug: Fix for #223, no error message when parent node doesn't exist in the SiteMap. An error message is now shown with each orphan that couldn't be added to the SiteMap and detailed information about the origin of the node.
- Feature: Closes #114, specify order of nodes in the menu. Added an order property that can be used throughout the provider to control the order in the Menu and SiteMap HTML helpers.
- Bug: Fixed datatype of Attributes property in DynamicNode and MvcSiteMapNodeAttribute. It was IDictionary<string, string>, changed it to be IDictionary<string, object> so user-defined objects can more easily be added to the SiteMap nodes.
- Deprecated: SiteMapPreserveRouteDataAttribute was deprecated because upon careful analysis it has no real-world use. It apparently depended on writing data to the shared SiteMap cache in order to function. Allowing updates to the shared cache was a bug that was fixed with the release of 4.0.17.
- Enhancement: Made MvcSiteMapProvider_IncludeAssembliesForScan, MvcSiteMapProvider_AttributesToIgnore, and MvcSiteMapProvider_ControllerTypeResolverAreaNamespacesToIgnore configuration settings safer by trimming the whitespace between the value and delimiter.
- Enhancement: Added an error message when the .sitemap file doesn't have a root node defined.
- Feature: Added setting MvcSiteMapProvider_EnableSiteMapFile so XML file parsing can be disabled while using the internal DI container.
- Bug: Fixed the logic so it doesn't depend on the order the nodes are processed when adding Dynamic Nodes and MvcSiteMapNodeAttribute defined nodes to the SiteMap. This was causing nodes not to be added with no indication as to the cause. This change required a new interface to be created, ISiteMapNodeProvider and the following types were deprecated: XmlSiteMapBuilder, ReflectionSiteMapBuilder, AspNetSiteMapBuilder, DynamicNodeBuilder, and IDynamicNodeBuilder.
- Bug: Fixed instantiation of providers when using them in conjunction with MvcSiteMapNodeAttribute and the internal DI container.
- Feature: Added MvcSiteMapProvider_IncludeRootNodeFromSiteMapFile setting to allow parsing of the XML without including its root node. This allows multiple XML files to used to specify a single SiteMap.
- Bug: Fixed logic that processes Dynamic Nodes that are nested in the XML file so it only calls them 1 time per declaration (rather than N + 1 times, N being the number of nodes in the parent Dynamic Node provider).
- Added MvcSiteMapProvider_EnableSiteMapFileNestedDynamicNodeRecursion setting to enable V3 dynamic node recursion behavior, which called the nested dynamic node N+1 times (not sure why or how it could possibly be useful, but we need this setting on the off chance that someone is using it). The default behavior is to have this setting disabled, and we don't recommend enabling it unless you absolutely need the recursion for your application to work.
- Fixed implicit resource key by setting it to the SiteMapCacheKey as described in #228 as the "object key".
v4.2.0
- Enhancement: Changed logic of SiteMapLoader so passing null or empty string causes it to lookup the SiteMapCacheKey from ISiteMapCacheKeyGenerator rather than throw an ArgumentNullException. This makes it easier to implement features with an optional SiteMapCacheKey value.
- Feature: Added SiteMapCacheReleaseAttribute action filter attribute that can be used on controller actions to clear the cache after executing the controller action and before the view is processed.
- Bug: Fixed SiteMapCacheKey property on SiteMapTitleAttribute because it was not available publicly.
- Documentation: Added readme file to obsolete MvcSiteMapProvider package with instructions on how to remove it and/or replace it with the MvcSiteMapProvider.MVCx packages.
- Feature: Added a web.config setting named "MvcSiteMapProvider_EnableResolvedUrlCaching" for use with the internal DI container that can be used to globally disable URL resolution caching.
- Bug: AttributeDictionary was throwing exceptions when trying to add values from the presentation level. This was unintended, as it was supposed to allow changes that are valid only for the current request.
- Bug: Fixed visibility for /sitemap.xml endpoint so each URL will function individually rather than being blocked if the parent node doesn't have visibility. The ACL modules still block access to their child nodes as expected.
- Enhancement: In the /sitemap.xml endpoint, duplicate URLs are no longer sent to the output, as there would be no value in listing the same URL twice.
- Bug: In the /sitemap.xml endpoint, fixed the default baseUrl setting so it will take into consideration when an application is being hosted as a sub application.
- Enhancement: Removed unnecessary caching from SiteMapNodeUrlResolver.
- Bug: Fixed thread safety of the cache of ControllerTypeResolver.
- Bug: Fixed cache key names for RouteValueDictionary and AttributeDictionary.
v4.1.0
- Documentation: Added upgrade information to the readme file of each DI package.
- Documentation: Changed description of MvcSiteMapProvider legacy NuGet package to indicate it is now obsolete.
- Bug: Incorrectly resolved URLs in sitemaps XML when MvcSiteMapProvider is in sub application (#222).
- Bug: Fix for custom AuthorizeAttribute implementations that are sealed or have a non-public constructor (#156 and #220). Important Change: If your custom AuthorizeAttribute overrides
OnAuthorization(), you must ensure thatfilterContext.Resultis not null when authorization fails and is null when authorization succeeds. - Feature: Refactored IRequestCache to inherit from ICache so other types of caches can be swapped.
- Bug: Added exception message in the case where the same key is added to RouteValues and PreservedRouteParameters on the same node.
Important Note: If you are using SimpleInjector, you must remove the following code from your DI module, or you will get compile time exceptions after installing this (or a future) version.
container.RegisterSingle<AuthorizeAttributeAclModule>(() => new AuthorizeAttributeAclModule(
container.GetInstance<IMvcContextFactory>(),
container.GetInstance<IObjectCopier>(),
container.GetInstance<IControllerDescriptorFactory>(),
container.GetInstance<IControllerBuilder>(),
container.GetInstance<IAuthorizeAttributeBuilder>(),
container.GetInstance<IGlobalFilterProvider>())); v4.0.17
- Extensibility: Changed open generic registration of cache providers in external DI modules so they can be extended without having to change configuration code. Please update your DI modules using the diff as a guide.
- Bug: Fix for issue described in #212, problem with preserved route parameters being written to the shared cache.
- Bug: Fix for #214, Area inheritance logic not working correctly for default non-area nodes.
- Feature: Added key property to SiteMapNodeModel View Model class to aid in building custom CSS schemes.