Skip to content

v4.5.0
Compare
Choose a tag to compare
@NightOwl888 NightOwl888 released this 12 Feb 19:16
· 132 commits to master since this release
v4.5.0
f18befb

Important Manual Update Required for External DI Modules

Although this won't affect you if you are using the internal DI container, there is a required update because some of the bugs in the queue simply couldn't be fixed without a breaking change. So, if you are using an external DI container, you should expect to require some extra time in order to update your configuration.

What is this for?

This is to address an ongoing problem where some bugs require services to be dropped from the external DI container, as well as a limitation with the current registration conventions that prevent us from being able to provide alternate implementations of a service. Neither of these things can be done with the current conventions in place in your project.

What has changed?

Conventions (CommonConventions.cs)

This update addresses the following issues:

  1. Types (from the .NET framework) that require an adapter pattern wrapper class (suffixed "Adapter") because they are not designed in a loosely coupled manner are now automatically registered if their constructor permits it. There are 2 adapters (BuildManagerAdaptor and ControllerBuilderAdaptor) that are no longer required to be manually registered.
  2. Multiple implementations of an interface are no longer dropped automatically from auto-registration. The idea was to provide a service that implemented an interface and if you decided to provide an alternate implementation in your project the auto-registration would automatically exclude the built-in type from being registered. This sounded good on paper, but in practice it means we cannot ever provide an alternate implementation for you even when it makes sense. You should now manually exclude a type from auto-registration by adding it to the excludeTypes array.
  3. The conventions now honor a new attribute MvcSiteMapProvider.DI.ExcludeFromAutoRegistrationAttribute. This allows us to remove types from auto-registration even if they follow all of the existing conventions, which can be handy if the type takes on a dependency that cannot be registered automatically and thus requires an abstract factory to instantiate it.
  4. The IsMatch members were renamed IsExcludedType for clarity.
  5. Documentation has been added to the public members of CommonConventions.cs for intellisense support.

Modules

The modules have been changed primarily to support the new CommonConventions.cs logic, but there are also a few updates to existing types in order to support the new version.

  1. Removed all types from excludedTypes (exception Windsor), because they are no longer required. (optional)
  2. Removed the regex from the CommonConventions.RegisterAllImplementationsOfInterface() method, as this is exclusion is now done using the ExcludeFromAutoRegistrationAttribute. (optional)
  3. Added a "Demo" compilation switch so we can test the MvcMusicStore the same way with internal and external containers. Don't copy the code from the first block into your project.
  4. Added documentation for the usage of the excludedTypes variable. (optional)
  5. Removed manual registration of the BuildManagerAdaptor and ControllerBuilderAdaptor because they are now done automatically via convention. (required)
  6. Removed unused using directives. (optional)
  7. Added 2 new variables and updated SiteMapBuilderSet registrations to account for the new visibilityAffectsDescendants and useTitleIfDescriptionNotProvided settings. (required)
  8. Updated references to ISiteMapXmlReservedAttributeNameProvider and SiteMapXmlReservedAttributeNameProvider to IReservedAttributeNameProvider and ReservedAttributeNameProvider, respectively. (required)

Getting the Update

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.

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.0  -IgnoreDependencies -FileConflictAction Overwrite

Possible Breaking Change

Who is Affected?

This affects you if you are using both the /sitemap.xml endpoint and a built-in or custom visibility provider.

What Could Break?

The default visibility logic of the XmlSiteMapResult class has changed so it will have the same behavior as the Menu and SiteMap HTML helpers. This means that some items that are visible before the update could become invisible in the /sitemap.xml endpoint after the update is applied.

What Has Changed?

The "VisibilityAffectsDescendants" logic has been applied to the XmlSiteMapResult, which basically means that when a parent node is invisible, so will all of its children, grandchildren, etc. The change is to address the fact that it is done fundamentally different between the HTML helpers and the /sitemap.xml endpoint and so we could put in a SiteMap wide setting that affects everything at the same time. Unfortunately, from the release of v4 to this release, the default behavior of the Menu and SiteMap HTML helpers was to hide the descendant nodes of an invisible node and the default behavior of the /sitemap.xml endpoint was to show descendant nodes of invisible nodes.

How Do I Fix It?

The recommended fix is to set the "MvcSiteMapProvider_VisibilityAffectsDescendants" setting to "false" in the web.config if you are using internal DI. If using external DI, this setting can be found on the constructor of the SiteMapBuilderSet object (see the external DI update information above).

Setting this value to false ensures your /sitemap.xml endpoint is the same as it was, but it could inadvertently cause some items to become visible in your HTML helpers that shouldn't be. Basically, this setting makes visibility of every node toggle on and off rather than taking into account the visibility of the parent node. So, you may need to copy the "visibility" attribute to the descendant nodes (children, grandchildren, etc) in your configuration.

Alternatively, you can call an overload of the Menu and/or SiteMap HTML helper that accepts the visibilityAffectsDescendants property, setting this value to "true" which will override the global setting of "false". This will basically give you the same behavior as 4.4.x.

Change Log

  1. Bug: Fixed potential localization problem when parsing the LastModifiedDate from the XML so it uses the InvariantCulture.
  2. Feature: Added call to container.AssertConfigurationIsValid() for StructureMap external DI configuration so it will be called automatically when the application is in debug mode at application startup. This checks to ensure all of the registered types can be created and throws an exception if they cannot.
  3. Feature: Added ExcludeFromAutoRegistrationAttribute so types that follow the conventions to auto register can be excluded explicitly by our team without having to release an update to the external DI configurations.
  4. Bug: Fixed spelling mistake on Adapter suffix (previously spelled "Adaptor") so the types can be auto registered using the suffix by convention in external DI configurations.
  5. Bug: Fixes #266, Attributes and LastModifiedDate cannot be modified on MvcAuthorizeAttribute. This was due a limitation of .NET attributes in that they only allow primitive types and arrays as parameter types. The workaround was to convert both properties to string - LastUpdateDate uses DateTime.Parse() to read the date (on the invariant culture) so any valid .NET date string can be parsed into the field. The Attributes field can now be configured using a JSON string.
  6. Housekeeping: Removed unused StructureMap conventions from the external DI configuration. These conventions are not being used in our default setup. *** (Back up conventions if they are needed in your setup)
  7. Feature: The "area" key of the RouteValues dictionary is now automatically created when creating a new node. In addition, all of the Add() and AddRange() members of the RouteValues dictionary and Attributes dictionary automatically update existing values instead of throwing an exception. This makes the node easier to populate from implementations of ISiteMapNodeProvider.
  8. Bug: Fixed inheritance logic of XmlSiteMapNodeProvider so it will include the inherited values in the key name, rather than the original values.
  9. Feature: Closes #261, added "MvcSiteMapProvider_VisibilityAffectsDescendants" web.config setting and added the functionality to honor the setting in the XmlSiteMapResult so it will be consistent everywhere. The default setting is "true" to avoid breaking backward compatibility of HTML helpers, but note this is a _breaking change_ to XmlSiteMapResult, that previously acted like this setting was "false". We recommend setting this to "false" as that provides you with the most control over your HTML helpers. In version 5.x, we plan to set the default to "false" so the default behavior will be the same as it was in version 3.x.
  10. Bug: Fixes #238, added "MvcSiteMapProvider_UseTitleIfDescriptionNotProvided" setting (default true) so the behavior of defaulting Description to the value of Title can be turned off if desired.
  11. Bug: Fixes initial issue described in #236, SiteMapTitle doesn't function when the "MvcSiteMapProvider_CacheDuration" is set to "false".
  12. Bug: Fixes #249, URL comparisons are case sensitive, which is inconsistent with Microsoft's implementation.
  13. Bug: Added [ExcludeFromAutoRegistrationAttribute] to AssemblyAttributeProvider to fix issue with incorrect auto registration decision in SimpleInjector.
  14. Bug: Getting Started page was throwing a JavaScript error in Visual Studio because GitHub no longer supports IE8. So moved the Getting Started page to GitHub pages.
  15. Bug: Fixed "disappearing breadcrumb" problem that was caused by the breadcrumb showing up intermittently when the node is misconfigured and then "disappearing" when the code with the correct behavior was hit.
  16. Bug: Fixed incorrect URL caching logic that cached the URL with the value provided by the user on the first request. This was due to MVC picking up "ambient values" and injecting them into the URL from the request that builds the SiteMap.
  17. Bug: Fixed node matching logic when 2 nodes with different "id" values are configured in the sitemap. This issue appeared after fixing the "disappearing breadcrumb" problem, which was apparently keeping it from happening most or all of the time.
  18. Performance: Refactored the node matching logic so it no longer uses a recursive call or calls into the IAclModule when locating the node.
  19. Bug: Removed unreachable execution path that checks for matching action method parameters from the node matching logic and unnecessary call into MVC to retrieve these values.
  20. Deprecated the public ResolveActionMethodParameters() method from ISiteMap. This is scheduled for removal in version 5.
Assets 2
Loading