.NET has a lot of IoC containers.  This is undoubtedly a good thing: diversification is a sign of strength in the ecosystem.  MEF is showing how specialization can be used to solve specific issues.  I'm going to try to set out one vision of how IoC containers should evolve.  This is not my opinion of how they all should evolve, it's simply my vision of what I would like from one of the many containers. I've argued for some time that containers are all about configuration.  If you don't believe that, then you should consider why Yadic isn't your...

Linus Torvalds is a busy guy.  Not content with pushing badge-name Unix vendors into the land of the legacy system, and creating an operating system that’s nigh on won the server market (It’s not looking too shabby on mobile and embedded systems, either), he somehow managed to find the time to revolutionise source code management as well.  Anyone who’s jumped straight between Subversion* and git will know quite how radical a change it is.  But the reason I love it is that it’s fundamentally changed the mindset of open source software. You see, although open source projects were meant...

I once took advantage of the published source code of the Microsoft Enterprise Library Data Access Block to make some firm-specific modifications.  One of those changes that only really makes sense in the target environment, nothing particularly general.  The Data Access Block, for those of you who aren’t familiar with it, is basically an improved version of the ADO.NET API, with some pretty useful support for stored procedures.  It’s not NHibernate, but it’s better than coding the API in the raw. While I was there, I decided to rip out the stuff we didn’t use.  That turned out to...

If you're writing SOLID code, you're going to be doing a lot of wiring.  Typically, this wiring only changes in response to business change.  Some wiring is going to be static for years.  If you're building a car, you won't suddenly wire the clutch to the CD player, as entertaining as it would be when your brother-in-law tried to drive it. On the other end of this spectrum, there's stuff that changes all the time.  Every machine you use, it needs to change.  This is actual configuration information.  The rest of it can, frankly, be hard wired.  True configuration...

These two patterns deal with times that you've got a requirement to be able to undo work.  There's Memento, which is a pattern of limited use (if only because a lot of the classic implementations are already available for you to use), and Command, which is one of the most criminally under-used patterns in the whole book. Memento Let's deal with Memento first.  Personally, I think most of the problem with Memento is its name.  It's a checkpoint.  You store checkpoints as you're working, and you restore back to a checkpoint if something doesn't work.  A good design for a...

Previously, I talked about patterns where you were unlikely to implement them yourself, since they are now considered part of the infrastructure that goes with a modern language.  The publish/subscribe model isn't quite ready to be described as infrastructure, but it's getting close.  So, here are two patterns I don't honestly think it's worth knowing.  Here, it's not so much that the patterns are bad, just that you're better off understanding and using the publish/subscribe model.  Here's how the pub/sub model works: Participants are called services. They do not communicate directly...

All of this assumes that you've built NServiceBus in line with what I said on the previous post.  This is just enough to modify the FullDuplex sample to load balance.  Most of this has previously appeared on the yahoo groups, but I've just organized it for comprehension. Step 1: Modify the configs Amazingly, all you need to do is to modify the configs of the samples.  Here's what you need to do. Client c:\NSB\Samples\FullDuplex\Client\bin\debug\Client.exe.config <UnicastBusConfig DistributorControlAddress="" DistributorDataAddress=""> <MessageEndpointMappings> <add Messages="Messages" Endpoint="distributordatabus" /> </MessageEndpointMappings></UnicastBusConfig> Distributor c:\NSB\src\distributor\NServiceBus.Unicast.Distributor.Runner\bin\Debug\NServiceBus.Unicast.Distributor.Runner.exe.config Requires no changes.  It just works.  (!) Server 1 C:\NSB\Samples\FullDuplex\Server\bin\Debug\Server.exe.config <MsmqTransportConfig InputQueue="server1messagebus" ErrorQueue="error" NumberOfWorkerThreads="1" MaxRetries="5"/><UnicastBusConfig...

They've gone to a lot of effort to make nServiceBus easy to get working, but it still takes about half an hour with the readme.  A couple of notes that should save you some time: Relatively obviously, you've got to put MSBuild on the path.  This will usually fix that:  set path=C:\WINDOWS\Microsoft.NET\Framework\v3.5;%path% Build_Src.bat doesn't put anything into the build/output directory, which is unfortunate since build_samples.bat expects it to.  build_with_strong_name.bat does, however. For some reason, my box didn't trust nServiceBus.  This gives you the (in)famous "The Project Location is Not Trusted" dialog box.  The following command fixed it:  caspol -machine...