The packaging of NServiceBus 2.0 has been slightly changes compared to 1.9 The reason for this is that the merged NServiceBus.dll started to get to big. While we still strive to keep the number of assemblies down we decided that a split was necessary.

NServiceBus 2.0 will ship the following assemblies:


Contains only the interfaces and classes that enables you to implement your business logic. This means message handlers sagas, classes with a dependency to the IBus interface etc. This is essentially a lightweight assembly containing the public Api of NServiceBus


This assembly contains all the core parts of NServiceBus, transports, subscriptions storages, serializes, etc. Any projects that hosts NServiceBus endpoints needs to reference this assembly. NServiceBus and NServiceBus.Core are the only mandatory assemblies so if you are providing your own hosting solution these are the only things you have to reference. (most likely if you are hosting NServiceBus within a asp.net web application)


NServiceBus 2.0 comes with a new generic host that will take care of hosting your business logic in a flexible way. (Based on topshelf). Justin Ramel has great post on how to use the host

Additional Containers

2.0 will ship with Spring.Net as the default container. If you prefer to use one of the other supported containers, AutoFac, StructureMap, Windsor and Unity you have to reference the NServiceBus.ObjectBuilder.[Name of Container].dll that ships with NServiceBus. We also supply the versions of the actual containers that NServiceBus is compiled against. If you prefer you own version just reference the specific version and assembly redirect accordingly.

The current trunk contains the above packaging and should hopefully be quite stable as we are closing in on the release of NServiceBus 2.0.