February 25th, 2012

One of the good things – of a few – of my tenure at the CLR team was being exposed to the metal. One of my interest areas was the loader, PM’ed by one of the most arrogant person I’ve ever met. Fortunately the senior dev in charge of it is an awesome person, and helped me with some explorations I was doing on my own, which I’ve blogged before. At that time, pre nuget, I pitched an idea to the leadership team of using runtime packages, similar to win8′s deployment system and OSGi. The idea gained some traction, but in order to have a composable framework many things would have to change, starting with mvc. A very charismatic and public known person whom should remain unnamed blocked the effort saying “no customers were asking for this”. Faulty logic since no customers were asking for cars, for iPads, for .net… Not to mention the “if-I-don’t-understand-it-must-be-a-hack” person, still in that team. So they settle for a simpler solution: Nuget.

Anyway, left MS but the lack of a framework that enforced a stronger modularity was an itchy to be scratched. In the end, the ultimate experience I wanted is to have an app shell that can be composed in runtime with additional functionality, in any level of granularity. To some extend, VS is like that. It’s a dumb shell, and the functionality we all know and enjoy is delivered through “packages”. Those themselves can be composed to augment in features and additional support plugins and vsix extensions (although it’s composed through COM aggregates, which is just sad)

However, Eclipse is far ahead by combining physical packages with isolated scoped: enters OSGi. In OSGi a bundle is a unit of deployment, versioning and execution. In contain all the artifacts required to its execution, including a declaration of its external world dependencies. In runtime, a class loader trick is used to load a bundle in an isolated context, so if you load a bundle that say, uses nhibernate 3.1, it won’t interfere with another loaded bundle that is using nhibernate 3.3. (no jar hell, and no remoting). This problem is also known to .net folks. Clashing of dependencies requires either recompilation of many dependencies or assembly binding redirects. Not fun!

Castle Extensibility aims to solve exactly this problem. Since it’s a complex space, I dont think I can fully explain how to use it or how it works in a single brief blog post. So I’ll save more details for later. It’s worth mentioning that MonoRail 3 is integrated with it, so it’s able to run several “copies” of itself in the same app domain, hosting then many isolated applications in a single web site. Also worth mentioned it’s being used on the stuff I’m working on.

Oh, and obviously it was built in F# :-)

Categories: Castle, OS | Top Of Page | 6 Comments » |

6 Responses to “Castle.Extensibility”

7sharp9 Says:

What percentage is F# 100% and how are you getting true isolation without rogue exceptions causing the whole app domain to crumble i.e. exceptions from Tasks that are not handles etc ?

hammett Says:

100% f#. you can actually see the code at, esp. Hosting.Binder

David Says:

How might this compare at the feature level to MEF?

hammett Says:

It builds on top of MEF. I’m using MEF primitives (each bundle is a composition silo) expressed using MEF’s ComposablePartDefinition.

A'braham Says:

Is this still active?

hammett Says:

Not really. what are you building?

Leave a Reply