github Particular/NServiceBus 4.4.4

latest releases: 9.0.0, 8.2.0, 9.0.0-alpha.10...
9 years ago

As part of this release we had 3 issues closed.

Features

#2287 Enable users to switch encryption keys without message loss

Since the dawn of time we've only supported 1 encryption key in the ootb encryption(AES) and this makes it close to impossible to switch keys without losing data, messages in SLR, or ERROR queues would have the wrong key and fail to decrypt.

The users only options is either to not switch keys which is no good in terms of security best practices or implement their own ISecurityService

The proposed solution is to allow for secondary keys that we fall back to if decryption fails. This way users can add new primary keys (used to encrypt) but still keep the old key(s) around long enough to be able to process messages in SLR or the error queue.

This bug needs to be backported to all supported versions (v3.3 and up)

Bugs

#2319 Convention based .DefiningMessagesAs causes an exception when following pattern in docs

Docs here: http://docs.particular.net/nservicebus/unobtrusive-mode-messages suggest that you should use a namespace convention for detecting messages. This is cool and I like this convention however if you follow the convention for events/commands and apply the same convention to messages (eg .DefiningMessagesAs(t => t.Namespace != null && t.Namespace.EndsWith(".Messages")) it exceptions with the following:

An exception of type 'System.NotSupportedException' occurred in NServiceBus.Core.dll but was not handled in user code

Additional information: IDictionary<T, K> is not a supported property type for serialization, use Dictionary<T,K> instead. Type: NServiceBus.Unicast.UnicastBus Property: MessageDispatcherMappings. Consider using a concrete Dictionary<T, K> instead, where T and K cannot be of type 'System.Object'

I think either the docs should be updated to note this issue and suggest a better pattern or the code should exclude NServiceBus.*.Messages and Unicast.Messages from the scan types.

#2300 Raven check needs to include an upper bound range

NServiceBus ships with RavenDB Client v2 embedded as part of the core.
As highlighted previously in this discussion a new nuget/dll was released to work against RavenDB v2.5.

So currently anyone using NServiceBus v4 with RavenDB v2.5 Server need to be running the new integration package otherwise them may lose messages!

To ensure that the correct version of the RavenDB integration is being used we need to modify the Raven check that we do in the Core to restrict the upper bound version to be < 2.5

Where to get it

You can download this release from nuget

Don't miss a new NServiceBus release

NewReleases is sending notifications on new releases.