Skip to content

4.2.0
Compare
Choose a tag to compare
@SimonCropp SimonCropp released this 05 Nov 01:56
· 7082 commits to master since this release
4.2.0
60c8365

To see the full list of issues see Milestone 4.2.0.

To see the full list of commits see this compare.

Improvements

#1431 Better pipeline for the handler execution

Partially inspired by the Fubu Russian doll model the internal execution of handlers now takes a nested execution approach.

We refer to this nested approach referred to as a Chain. Each step in this Chain is referred to as a Behavior.

So part of the chain would be

Start chain
invokes ApplyIncomingMessageMutatorsBehavior 
    invokes CallbackInvocationBehavior 
        invokes LoadHandlersBehavior 
            invokes SagaPersistenceBehavior 
                invokes InvokeHandlersBehavior

This allows each behavior to have control of

  • What is executed before the nested behavior
  • Optionally not invoke the nested behavior
  • Handle exceptions that occur during the nested execution
  • Optionally wrap the nested action in a transaction
  • What is executed after the nested behavior
  • Manipulate the data passed into and received from the nested behavior

Bugs

#1717 If persistence is disabled in the fluent configuration but persistence key is present in the config file, persistence is enabled

The logic should be disabled and give a warning that configs are not consistent.

Related to #1716

#1714 Lack of 32-bit host in NServiceBus.Host32 package

The NServiceBus.Host32 package 4.1.1 does not contain NServiceBus.Host32.exe, but NServiceBus.Host.exe

The output from CorFlags illustrates the issue

CLR Header: 2.5
PE        : PE32
CorFlags  : 9
ILONLY    : 1
32BIT     : 0
Signed    : 1

#1713 SagaPipeline - Saga is not started, when an event is published

#1712 Remove dependency T4

T4 Scaffolding are not adding much value. Also there are compatibility issues with Visual Studio 2013

#1708 Autofac 3.0.0 leaks memory

When child containers is used. Fix is to upgrade Autofac to 3.0.1

From Autofac Release Notes

Rollback of Issue 397 (Nested lifetime scopes aren't disposed when the parent is disposed) due to memory leak.

#1699 Messages processed by the Gateway satellite are being forwarded to the audit queue causing duplicates in the audit queue.

#1687 Windows Server 2012 installing MSMQ using Powershell Cmdlet fails

Fails with the error

Error: 0x800f080c

Feature name MSMQ-Container is unknown.
A Windows feature name was not recognized.

Change to use the /all option in DISM on Server 2012

#1685 Powershell error when installing NServiceBus nuget package regarding registry key

Add a check to see if the key exists

#1642 Remove impersonation feature

Historically ImpersonateSender was renamed to RunHandlersUnderIncomingPrincipal as part of #1104.

However the new API adds little clarity.

Dissecting RunHandlersUnderIncomingPrincipal gives the impression that "Handlers will be run under the principal of the user who sent the message"

When in reality all this API is about is "telling the handler who made the call" not anything to do with security or impersonation. It does this by setting Thread.CurrentPrincipal to a fake principal containing the username of the user who sent the message. It extracts this username from the message headers. The handler code is free use use Thread.CurrentPrincipal or to ignore. Either way all handler code will be run under the account the process is running as.

This API will be removed. If people want to access the sending user they can do so by using the message headers like they do for any other message metadata.

#1640 ReturnToSource does not recognize the Id in the message headers and does not return the message.

Fix so that ReturnToSource is backwards compatible with earlier versions

#1629 TimeToBeReceivedAttribute.TimeToBeReceived should not be optional

TimeToBeReceivedAttribute has an empty constructor and hence TimeToBeReceived is optional. This should not be the case. The empty constructor should be obsoleted and then removed.

#1337 upgrade to Castle Windsor 3.2.1 to fix scoping lifetimes when used in Azure

From the Castle Windsor Release Notes

It fixes a problem some users encountered, when CallContext scoped lifestyle is used in certain cross-AppDomain contexts. It specifically affected users of some testing framework or NServiceBus when deployed to Azure. The bug would manifest itself with the following exception:

SerializationException — Type is not resolved for member
“Castle.MicroKernel.Lifestyle.Scoped.CallContextLifetimeScope+SerializationReference,    
Castle.Windsor, Version=3.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc”

Where to get it

You can download this release from:

Assets 3
Loading