I'm very pleased to formally announce a project that Aaron and I started a few months ago and have been quietly contributing to. MultiFunctionMachineMachine, MFMM, or just Machine is a collection of common code and projects that we've collected into one place for our own consumption. In the same way that Ayende has his Rhino repository, we have our Machine repository. It's not exactly an OSS project in the typical sense. For us it's just a place to store experiments and code common to our various projects. It's a repository of usefulness! Now, there's far too much in the repository to be described in one post. I'm just going to give a brief synopsis of what's in there so far and based on people's reactions I can dive deeper. That is, if people hate it I'll pretend I never wrote any of it. Here is a breakdown of the important sub-projects:

• Machine.Core - Very common services and utilities. I usually need a few of these services in a project and decided to package them up. Of particular usefulness is some code that I've used in a number of GUI applications. It's an AOP approach to automating the ISynchronizeInvoke pattern. My original implementation for this used Reflection.Emit to create proxies. I've since adopted the IInterceptor approach used by a number of people. In addition, I have code to perform the inverse - spawn new background threads to perform long-running operations. I use this extensively in my GUI applications. I'm always looking to add more to this project, sort of my own standard library.
• Machine.IoC - My thin wrapper around Windsor to make it behave the way I want. Most of this code just automates component naming and makes registration a little easier. Nothing too grand, but I found myself doing this everywhere and so boom, Machine project.
• Machine.Container - Well, this one is a long story. This is my own personal container that I wrote for a project where using Windsor was impossible. It's very small and works very similarly to Windsor but has some behavioral differences. Aaron used an early incarnation of it in Resharper.TestDrive.
• Machine.Migrations - At Eleutian we used rails migrations for a long time. Now we use our own migrator that works very similarly but allows us to write the migrations in .NET. This is a series of blog posts at least. One interesting thing here is we can use our NHibernate entities when we need to. I must warn you, this approach is not for everybody. We'll probably catch flak for not contributing to one of the existing implementations but we have our own grand scheme still brewing.
• Machine.MonoRail.Extensions - MonoRail ViewComponents. This has not grown at the rate I expected it to.
• Machine.BackgroundJobs - A very small library that implements an asynchronous job pattern. We had some long-running operations that were going to be spawned off and managed from a central location and I felt it warranted its own framework. It seemed like it could get more complicated but hasn't. It has remained largely static since I checked it in.

None of these projects are mature so exercise caution when using them as things may be a little rough. I have some very crude experiments in there that you're welcome to browse over. I believe the CodeWeaving stuff I mentioned in an earlier post is there, that sort of thing. Finally, I feel the need to provide two disclaimers:

1. It's possible code got copied and pasted from somewhere in a quick experiment and I forgot to acknowledge the original author. I have to admit, this is a constant fear of mine because I read so much code. Drop me an e-mail, I'm friendly.
2. David Laribee is the genius behind the name. A name is important. I can think of no machine more pivotal to the human race than one that actually makes machines with multiple functions.

Well, that's it! In case you missed the earlier link, here is the Assembla page and the repository. As always, I welcome any questions, suggestions, or bug reports!