Spring.Net loading xml assembly resources

This might contradict my previous post, but then again, it is a helpful tip in case you have a lot of spring.net xml configuration files.

At some stage in your project, you might want to include all your xml configuration files for spring as embedded resources inside your assembly. This is useful during deployment as you won't need to make sure that your xml files are deployed alongside your code base.

But, your spring configuration sections might start to have quite a few lines to indicate which resources to load.

What I wanted was for spring to load all xml embedded configuration files under a namespace instead so that it would look something like this:

And so I dived into Spring.Net code base to figure out where the resources where being loaded up and if I could intercept that call to add the extra resources I wanted. This wasn't easy to find, but in the end I succeeded in what I wanted to do.

What you need is to override the method InstantiateContext of the context handler in a subclass of your own (don't forget to change the configuration section once you have done so).

The resources array you get passed in is a list of resources definition you have configured under the spring/context section (see above).

The next bit, was easy, all I needed to do was to parse the resource strings with '*' and load up all the resources under the path I specified. The new array I returned contained the full list of resources I wanted spring to load up.

That's it.

Now, if you want to take an easier root, you can download the FluentSpring API dll which contains the classes you need right here.

Fluent Spring Configuration for .NET

Let me start today's blog with this:

instead of

You have probably already guessed, it is a snippet of code to configure my dependency injection container. In this case, the IoC container from Spring.Net.

It has taken me over two years using Spring on our web application to come to the conclusion that spring configuration over xml is just, well, frustrating.

What I would expect from any IoC container configuration is the following:

• It can be tested.
• It can follow a user defined convention for configration
• It can reflect my code changes (i.e. namespace changes, property name refactor, etc.)

The problem with Spring.Net is that it only supports xml configuration. When I first started using Spring.net I didn't mind it at all and everything seemed fine. After one year we ended with humongous files full of xml configuration. We decided to split them into single ones, each with the name of the type it configured (thus giving us a slightly better edge at finding the xml configuration for a component). And now we have a huge number of files. This isn't great.

This is frustrating because of the problems you get when working on your code over a long period of time. You will find that something you wrote a year ago is not cutting the mustard anymore and you need to refactor it. The refactor capabilities you get with Resharper are great, but falls a little short when refactoring xml files.

Also, what I do find is when you implement your code in a TDD fashion, your configuration will happen last, and thus when you think you have finished your work, spring xml configuration will make you work some more. How many times do you get the spring error at runtime when you have misconfigured your objects hmm?

Don't get me wrong though, I like spring.net. I think it is a great framework, it is also a lot more than just a DI container.

And so, after looking waiting long enough for a fluent API for spring, I thought it might be fun to actually write my own one. And so I did, and yes it was fun.

I have called it FluentSpring and it is available on github right here.

This API supports almost all existing xml configuration you can do currently. And if you were scared at this point, don't worry, both configuration methods (xml and fluent) can be used at the same time. I have also extended its capabilities in some place to apply constraints to specific binding elements. I can now bind an interface to an implementation and give that a constraint (which is run at load time or when the object is requested, but you can configure that too).

example of an interface bind:
which means that when I register a property binding like so:
it will bind my SomeObject property to the object which condition evaluation returns true. For the purpose of this example, I have just used a Func that returned true, but since it's a delegate you can use anything you want.

This fluent API has been compiled against Spring.Net 1.3.0 for .Net 3.5 (but if you download the code, you can compile against spring 1.3.1)

I will also implement a convention based configuration (very similar to structure map) which can be used instead of the current auto wiring capabilities of spring. This should be available in the next few days.

You will find all the details as to how to use it on the github repository.