Releases: Particular/NServiceBus
5.0.0
Upgrade Guide from v4 to v5
http://docs.particular.net/nservicebus/upgradeguides/4to5
As part of this release we had 97 issues closed.
Features
#2356 Add XmlMessageSerializer support for generic types.
#1605 Split RavenDB from the core and add support for RavenDB 2.5
In order to better follow the release cycle of RavenDB, the RavenDB functionality has been removed from the core into its own repository https://github.com/Particular/NServiceBus.RavenDB and nuget
https://www.nuget.org/packages/NServiceBus.RavenDB
#1604 Pull the distributor out of the core
Moved to a separate repo https://github.com/Particular/NServiceBus.Distributor.Msmq and NuGet https://www.nuget.org/packages/NServiceBus.Distributor.MSMQ/
#1555 Non-DTC operations
In order to provide the same level of consistency as users that are running with DTC transactions enabled we should introduce a mode of operations that provides those same guarantees without requiring a DTC compliant transport and storage.
The following is the high-level design
When a message is pulled from the Q
- if IncomingMessage.MessageId exists in the outbox
- no: Record all actions (keep them inmemorybatch them to storage at end of "inner" transaction)
* Note that message id will be generated here and kept stable - yes: dispatch all message actions (since this is a retry) but don't invoke user code
- no: Record all actions (keep them inmemorybatch them to storage at end of "inner" transaction)
Content trimmed. See full issue
Improvements
#2330 Provide saga type name when logging a SagaNotFound message
#2328 Introduce ISendOnlyBus
To simplify the api by not exposing IBus methods not relevant for a sendonly bus
#2327 Introduce Bus.Create(new BusConfiguration())
#2288 Move IConfigureThisEndpoint out of the core
#2282 Container.RegisterSingleton should take an instance of T not an object
#2261 Moved Roles into the Host
The extension points IConfigureRole, IConfigureRole<T> and IRole no longer exist.
AsA_Client and AsA_Server can still be used.
AsA_Publisher has been deprecated and should be replaced with AsA_Server
#2244 Remove Bus.CreateInstance
So where previously this was used
Bus.Publish(Bus.CreateInstance<OrderCancelled>(o =>
{
o.OrderNumber = message.OrderNumber;
o.ClientId = message.ClientId;
}));
Now this is used
Bus.Publish<OrderCancelled>(o =>
{
o.OrderNumber = message.OrderNumber;
o.ClientId = message.ClientId;
});
#2229 Improve error reporting in TimeoutPersisterReceiver
When the timeout persister logs a warning about a failure it will now include the exception in the log entry
#2168 Remove UnicastBus.Start(Action)
The Action parameter overload of UnicastBus.Start(Action)` has been removed
#2167 Remove ForInstallationOn, Windows and IEnvironment
This was an overly complex approach to running installers. As such it has been simplified
#2137 Make ConfigureHowToFindSaga abstract
Too many people forget to override this method. As such it will now be abstract.
#2136 Remove empty constructor requirement from Saga
by using FormatterServices.GetUninitializedObject
#2113 Merge the Core
The NSB interfaces dll was created to allow people to have a smaller dependency when creating a messages assembly. With the introduction of unobtrusive messages that is no longer required. As such NServiceBus.dll will be merged into NServiceBus.Core.dll. Also the NServiceBus.Interfaces nuget will be deprecated.
#2105 Change IMessageSerializer.Serialize to take a single message
In version 5 multi-message sends is being removed. So serialization of an array of messages is no longer required.
Note that deserialization to an array is still required for backwards compatibility with earlier versions of NSB
#2104 Obsolete SerializationSettings WrapSingleMessages and DontWrapSingleMessages
In version 5 multi-message sends is being removed. So Wrapping messages is no longer required. It only remains for compatibility with 3.0 endpoints
#2102 Standardise extension methods to configure persistences
#2097 Remove UnicastBus.NoSubscribersForMessage event
#2095 replace ISaga with non generic base class "Saga"
ISaga looks like an extension point. But in reality it is an internal concern which allows the framework to gain access to a non-generic version of the sagadata. See #1762
So ISaga (#1762) and ISaga<T> (#1765) were obsoleted
The replacement for the is a non-generic base class Saga. This class is a legitimating extension point, although most scenarios would still use Saga<T>. All functionality of Saga<T> will be pushed up to Saga. Saga<T> will now inherit from Saga.
#2093 remove MessageIntentEnum.Init
#2091 remove IPersistSagas
Not used for anything.
#2090 Remove IConfigurable interface on Saga
With the removal of ISaga and ISaga<T> the IConfigurable interface is redundant.
#2088 Remove Bus.Subscribe Predicate overloads
Since the Predicate is executed at the subscriber side it is not efficient. Also this is a confusing API since
consumer often, incorrectly, believe it is publisher side filtering. Instead create a Handler that does this
filtering logic and then, optionally, calls DoNotContinueDispatchingCurrentMessageToHandlers. This
Handler should be ordered to run before other handlers.
related to #1546
#2084 InMemory transport removal
#2082 Remove this.Bus() extension method for IHandleMessages implementations
#2081 Remove impersonation
#2078 Move to .net 4.5
The reasons for doing this are as follows
- Allows some better optimization in the core via the use of new APIs provided in 4.5
- Some of our Satellite dependencies are already moving 4.5. For example Unity
- 4.5 was release in mid 2012 so it has been out for reasonable amount of time
- Less testing surface area
- Also allows us to take advantages of the other various improvements in 4.5 http://msdn.microsoft.com/en-us/library/ms171868(v=vs.110).aspx#core
What this means for consumers
- The new minimum Visual Studio version will be Visual Studio 2012
- The new minimum server OS will be 2008
- The new minimum desktop OS will be Vista SP2
- All assemblies (and nugets) that depend on the core will be upgraded to 4.5
Note the earlier versions of NServiceBus will still be compatible and supported for .net 4
For more information on .net 4.5 see
- .NET Framework 4.5 – Core New Features and Improvements http://msdn.microsoft.com/en-us/library/ms171868(v=vs.110).aspx#core
- .NET Framework System Requirements http://msdn.microsoft.com/en-us/library/8z6watww%28v=vs.110%29.aspx
#2070 better handling of missing Feature.Enable
so if a user forgets to have this line Feature.Enable<Sagas>(); but still has a saga no guidance is given as to why that saga is not executed
In fact there is misinformation
Could not find a saga for the message type "Message1". Going to invoke SagaNotFoundHandlers.
#1989 Performance is slow while debugger is attached
#1863 Set DoNotWrapHandlersExecutionInATransactionScope automatically when Disabling transactions
When you call Disable on transactions, your call is still wrapped in a transactionscope
So to get rid of all transactional behavior you need to do both
Configure.Transactions.Advanced(a => a.DoNotWrapHandlersExecutionInATransactionScope());
Configure.Transactions.Disable();
Would be better to remove the scope automatically
#1857 ReturnToSourceQueue error message incorrectly formatted
Fix the incorrect message:
No message found with ID 'NServiceBus.MessageId'. Going to check headers of all messages for one with 'NServiceBus.MessageId' or 'NServiceBus.CorrelationId'.
[#1791 Remove DelegateFactory](https:/...
4.6.5
As part of this release we had 16 commits which resulted in 2 issues being closed.
Bugs
#2353 Timeouts and deferred messages are delivered to local queue, not clustered queue
In NServiceBus 4.6.3, in a clustered distributor setup, timeouts and deferred messages are delivered to local queue on workers and not to clustered queue.
Timeout messages and deferred messages are delivered directly to a specific local queue (on the server which requested the timeout/deferring) and not to the clustered queue. This bypasses the regular path which involves removing a message from the storage queue and deliver the destination queue on the worker. The worker does not know this and reports back that it is ready to handle a new message after handling the timeout message, which causes the storage queue to grow.
See question on StackOverflow for more information
#2072 NRE when sending a message that has no routing
When an endpoint tries to send a message and if no routing information has been specified in the configuration, then the endpoint throws an unfriendly exception.
Where to get it
You can download this release from nuget
4.6.4
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
4.5.3
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
4.4.4
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
4.3.6
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
3.3.11
As part of this release we had 1 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)
Where to get it
You can download this release from nuget
4.2.3
As part of this release we had 2 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
#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
4.1.4
As part of this release we had 2 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
#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
4.0.7
As part of this release we had 2 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
#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