4.6.0
As part of this release we had 53 commits which resulted in 14 issues being closed.
Improvements
#2065 Assembly scanner improvements
- Allow to configure the Assembly scanner to not throw exceptions
- If we find a valid
IEndpointConfig
, we should skip scanning - If there are errors, but if we can find endpoint config, we continue, but don't pass in bad assemblies.
So only do this if there are no errors:
if (arguments.ScannedAssemblies.Count > 0 -- && no errors)
{
serviceCommandLine.AddRange(arguments.ScannedAssemblies.Select(assembly => String.Format(@"/scannedAssemblies:""{0}""", assembly)));
}
- The host should not throw, so that we can still start the endpoint
AppDomain
so that any binding redirects kick in
Content trimmed. See full issue
#2012 Remove the warning when a 4.x endpoint receives an event from a 3.x pub, when the event is an interface.
- Relates to #1834
- Refactored the MessageMetadataRegistry class.
- Facilitated to remove the un-necessary warning which is displayed when a 3.x endpoint publishes an event which is an interface, where the 3.x endpoint added an __impl to the event type in the header.
#1983 Obsolete IBus.InMemory
So there are several confusion of this API
- Do Mutators run?
- Is it run in the same transaction?
- can complex+deep messages be sent? do they need to be serialized?
- does encryption run? should they?
- are databus properties supported?
- can a saga be started from InMemory?
- does the inMemory handler get an isolated set of headers or are they shared with the original message?
- of the standard message actions (Send, Publish, Reply, Return, Timeout) what ones does InMemory support?
- do FLR and SLR come into play?
Content trimmed. See full issue
#1893 When a message is forwarded to the error queue, the stack trace of the exception is too large
When a message is forwarded to the error queue, the stack trace that is stored in the header information for the message in the error queue is currently too long. We should include the inner exception that caused the problem instead of the entire stack trace which includes the entire pipeline steps.
#1313 Remove CLS compliance
So in all our assembly attributes we say we are CLS compliant. However we are not. See warnings below
We need to do some significant breaking changes to achieve this.
Warning 58 Type of 'EasyNetQ.ConnectionFactoryInfo.ConnectionFactory' is not CLS-compliant C:\Code\NServiceBus\src\RabbitMQ\NServiceBus.RabbitMQ\EasyNetQ\ConnectionFactoryInfo.cs 13 34 NServiceBus.Transports.RabbitMQ
Warning 52 Type of 'EasyNetQ.HostConfiguration.Port' is not CLS-compliant C:\Code\NServiceBus\src\RabbitMQ\NServiceBus.RabbitMQ\EasyNetQ\HostConfiguration.cs 6 23 NServiceBus.Transports.RabbitMQ
Warning 51 Type of 'EasyNetQ.IHostConfiguration.Port' is not CLS-compliant C:\Code\NServiceBus\src\RabbitMQ\NServiceBus.RabbitMQ\EasyNetQ\IHostConfiguration.cs 6 16 NServiceBus.Transports.RabbitMQ
Warning 41 Type of 'NServiceBus.SagaPersisters.Azure.DictionaryTableEntity.this[string]' is not CLS-compliant C:\Code\NServiceBus\src\azure\NServiceBus.Azure\SagaPersisters\Azure\DictionaryTableEntity.cs 154 31 NServiceBus.Azure
Warning 123 Type of 'NServiceBus.Serializers.XML.Test.MessageWithLists.SBytes' is not CLS-compliant C:\Code\NServiceBus\src\NServiceBus.Core.Tests\Serializers\XML\ListTests.cs 76 28 NServiceBus.Core.Tests
Content trimmed. See full issue
Bugs
#2064 NServiceBus Host 4.5.0 causing assembly scanning exception
After upgrading to 4.5, I've started to get an exception with the NServiceBus Host:
Unhandled Exception: System.Exception: Could not enumerate all types for 'C:\Ser
vices\Server\FluentNHibernate.dll'.
at NServiceBus.Hosting.Helpers.AssemblyScanner.ScanAssembly(String assemblyPa
th, AssemblyScannerResults results) in c:\BuildAgent\work\31f8c64a6e8a2d7c\src\N
ServiceBus.Core\Hosting\Helpers\AssemblyScanner.cs:line 149
at NServiceBus.Hosting.Helpers.AssemblyScanner.GetScannableAssemblies() in c:
\BuildAgent\work\31f8c64a6e8a2d7c\src\NServiceBus.Core\Hosting\Helpers\AssemblyS
Content trimmed. See full issue
#2061 Registry trial license cannot be written using default LocalSystem
The trial license won't work if NServiceBus is running as LocalSystem
Here is the error:
2014-04-17 14:29:21,257 [4] FATAL NServiceBus.Licensing.LicenseManager [(null)] <(null)> - Could not access registry for the current user sid. Please ensure that the license has been properly installed.
And this is on purpose because LocalSystem does not have a HKCU, see https://github.com/Particular/NServiceBus/blob/develop/src/NServiceBus.Core/Licensing/LicenseManager.cs#L53
#2057 EndpointConfig.cs can get overwritten
When IConfigureThisEndpoint
implementation is in a different project EndpointConfig.cs
content gets replaced with the default empty template.
To replicate this create a VS solution with 2 2 projects and in proj1 add:
public abstract class BaseClass : IConfigureThisEndpoint, IWantCustomInitialization
{
public void Init()
{
}
}
Content trimmed. See full issue
Where to get it
You can download this release from nuget