Castle
Castle
This is a follow up to my previous post. If you haven’t yet – go and read that one first. I’ll wait. So where were we? Aha… In the last post I said, that Windsor (any container in general) creates objects for you, hence it owns them, ergo its responsibility is to properly end their lifetime when they’re no longer needed. Since as I mentioned in my previous post, Windsor will track your component, it’s a common misconception held by users that in order to properly release all components they must call Release method on the container....
Probably the single most misunderstood feature of Castle Windsor is regarding its lifetime management of components. Hopefully in this post (and the next one) I’ll be able to clear all the misconceptions. Why is Windsor tracking components in the first place? One of the core responsibilities of a container is to manage lifecycle of components. At a very high level it looks like in the picture on the right. The container creates the object, sets it up, then when it’s ready to go, it gives it to you, so that you can use it, and when...
A bit later than expected (ah, work) I published beta 2 of Windsor 2.5 today. The release has the following changes as compared to beta 1. Silverlight version (for Silverlight 3 and Silverlight 4) is now included in the package. Synchronize Facility is now included in the package (.NET only) The following code changes and fixes were made (incl. one breaking change) - added support for selecting components based on custom attributes and their properties. See Component.HasAttribute<T>() methods - added WithService.DefaultInterface() to fluent...
Well it’s about time. Due to certain events (like me relocating to the other part of the world) it’s later than planned but it’s here – beta 1 of Castle Windsor 2.5 is available for download. There’s been quite a lot of changes in the release. Not just in the code but in the entire Castle Project. We migrated from Subversion to Git, and you can now access the repositories on github. Hopefully this will make things easier for anyone who wants to contribute features and patches to get going, and will raise the level of community contributions...
What you’re seeing here, is a feature in very early stages of development. It’s very likely to change in the very near future, hopefully based on your feedback which I’m looking forward to. It is often the case with IoC containers, especially when registering components by convention, that you end up with misconfigured components, or with an exception saying that your component can’t be resolved. To aid working in these situations StructureMap provides methods like WhatDoIHave and AssertConfigurationIsValid. That’s the only container I know of that provides this kind of diagnostics. Windsor also has...
Continuing the topic from the previous posts. What would happen? Current behavior of Windsor is somewhat flawed. What it will do is it will resolve foo, and provide it with bar. The flaw of this behavior is that now when we resolve foo via any of the tree containers we’ll get the same instance (since it’s a singleton). This introduced two issues: component from childA (bar) will now be available via childB and parent while logically thinking – it should not. we have temporal coupling in our code. Depending on...
Neal started looking into behaviour of child containers in Windsor. This is an area that’s very rarely used, and as Hammett wrote two years ago – this is speaking with the devil himself. No one really ever uses it so it never got well defined and as Neal found out there are certain inconsistencies, and grey areas there.
This was a don’t ask, don’t tell area, and since Neil opened that can of worms, it’s time to deal with the issue. I’m considering several solutions, and the one I’m leaning towards most would be probably the most controversial.
Remove support for child...
Paul, whom some of you may know as the maintainer of Horn project, left a comment on my blog, that was (or to be more precise – I think it was) a continuation of series of his tweets about his dissatisfaction with the state of affairs when it comes to dependencies between various OSS projects in .NET space, and within Castle Project in particular. I must say I understand Paul, and he’s got some valid points there, so let’s see what can be done about it. Problems One of the goals of Castle Project...
It took a little longer than I planned but here we go again. In the meantime ActiveRecord 2.1 was released, and soon after that a minor update bringing one cool big feature. From now on we’ll be working on version 2.1.2. Picking up from where we left off last time. We have a user entity. Since we’re building a website where users can publish benchmark results, we’ll create now a benchmark entity, and create a relation between these two. I want to see results! Let’s start by adding an appropriate field to the User class: ...
Disclaimer: This post is about the idea, not about the implementation. The implementation is crippled, not thread safe, will work only in few scenarios and only if used properly. Do not copy and blindly use this code. The problem One of unique features of Windsor is that it manages the lifecycle of objects it creates for you. What this means (among other things) is that it will dispose all disposable objects it instantiates. However to do this, it has to keep a reference to these components. Also that means that in...
Update: Due to a regression error discovered in Windsor Factory Support Facility, we decided to act fast and provide updated package of Windsor, without the issue. Get it here. Sorry for the inconvenience.
What better way of starting a new year can there be, than fresh set of releases from Castle Project?!
Core 1.2 (with more)
Castle Core 1.2 has now its own, separate package. Since the beta few things have changed
Email sender component is now integrated with Core, so if you were using it, you now should look for it in Castle.Core.dll. The version shipped with Core...
We’re building an application to gather and compare performance metrics of various laptop configurations in given set of benchmarks. As such we’re going to start with certain set of entities, first of which will be the User. We’ll start off by defining our User entity, configuring ActiveRecord, and some basic tests. Getting started First thing’s first – we need to get ourselves a fresh version of required libraries. At this point in time I’m using the trunk version. You can get the latest binaries here. Everything I show here will work with ActiveRecord 2.1 final version though. ...
We’re getting really close to new release of major Castle Project elements (Monorail 2.0, ActiveRecord 2.1, Windsor 2.1…). Coincidently I started building a small application on top of the stack, and I thought it would be a good idea to make this a “learning in the open” experience, and share my progress on this blog. This will mostly (at least initially) be a rework of Ayende’s old series, but I will update it to the latest version of the projects and try to discuss some new features as we go along. I don’t have the application ready yet....
Disclaimer: Notice that code shown here is quite new and is subject to change. If you’re reading this and it’s 2010 it’s likely that the code now is slightly different. I may come back and revisit the post if there are any changes, but don’t hold my word on it. Pulling from the container General rule of thumb when using IoC containers is – when you’re referencing your container in your components (anywhere outside of your bootstrapping code) you’re doing it wrong. As with all rules there are exceptions, but they...
Few months ago, a user asked the following question on the Castle users discussion group. A friend asked me about the same thing today, so I thought I’d blog this so that’s easier to find than the discussion group thread. Anyway, here’s the question: say I have the following types public interface ISometype<T> {}
public class SomeTypeImpl<T>:ISometype<T> {}
public class SomeSpecificTypeImpl<T>:ISometype<T> where T: ISomeSpecificSpecifier {}
...
Jono just pushed the first beta version of the Castle Dynamic Proxy 2.2 to the SourceForge. Don’t let the minor version number mislead you – this is a substantial improvement over the version 2.1. The changelog contains over 40 positions. I’m going to go over the most important ones here. Official support for Silverlight 2 or newer. Last version to support .NET 2.0. Substantial performance improvements (which includes more aggressive caching). Just see this: If you’re interested the...
I just committed a very cool feature to Castle Windsor/MicroKernel that adds lazy registration capabilities. By lazy registration I mean – you get a chance to register a component right at the spot when it’s about to be resolved. This enables things like integration with external sources of components, like MEF, or WCF config files, lets you distribute your registration in time so that you don’t have to do all of it upfront and many more. Behind all of this, is this interface: /// <summary>
///...
There seems to be much confusion around two kinds of proxies that Castle Dynamic Proxy provides - InterfaceProxyWithTarget and InterfaceProxyWithTargetInterface. On the surface they both appear to be doing the same thing. Rule of thumb: If you’re not sure which one you want – you want the one with the longer, confusing name – InterfaceProxyWithTargetInterface. InterfaceProxyWithTargetInterface seems to be used less often, which is a shame, because what people really want 99% of the time is actually InterfaceProxyWithTargetInterface. However I suppose due to it’s extremely confusing name, and no clear apparent...
We’ve covered almost all of Dynamic Proxy. If you followed along through this series, you now know 95% of Dynamic Proxy 2.1 features that get used 99,9% of the time. Now is the time to wrap up, and with that we’ll review some of the most common pitfalls that you may encounter when developing code on top of Dynamic Proxy. Leaking this Consider this simple interface/class pair public interface IFoo
{
IFoo Bar();
}
public class Foo : IFoo
{
...
Castle Windsor allows you to use single component for multiple services, which is called Forwarded Types. Forwarded Types In other words, you can tell Windsor – when IFoo is requested use FooBar as implementation, and when Bar is requested also use FooBar (when using default lifestyle of singleton you’ll get the same instance). Here’s some code: var container = new WindsorContainer();
container.Register(Component.For<Bar>().Forward<IFoo>()
.ImplementedBy<FooBar>());
var foo = container.Resolve<IFoo>();
...
As of now Dynamic Proxy is passing all the tests under Silverlight. There’s still some work to do, but it is pretty stable the way it is, and it’s been used by Silverlight versions of Rhino Mocks, Moq and probably some others as well for some time. Technorati Tags: Castle,Silverlight,Dynamic Proxy
One thing I don’t think I articulated clearly enough when announcing Castle Blog Aggregator, was that it comes with RSS feed. You may have noticed an RSS icon in your browser when browsing the aggregator site, but in case you didn’t here’s the direct link to the feed that you can use in your favorite feed reader. We’re also open to include other blogs in the feed, so if you blog about Castle, or know any good blogs about Castle project, let us know, either in the comments, or create a suggestion on Castle UserVoice...
Wow, what I had planned as few parts tutorial has turned to nothing less than full examination of Dynamic Proxy capabilities. Of all most important features we' have basically just one left – proxy persistence, which is what we’re going to talk about today.
Discussion
Although Dynamic Proxy’s name suggests that it’s useful for… well creating proxies on the fly at runtime, there are other scenarios where the framework can be useful. We’ve seen one such scenario last time, when we created mixins, not using proxying at all.
Also the dynamic aspect of proxies is not always what we want. This is not...
Mauricio, Castle newest committer, long time community member, and our man on StackOverflow.com, did a fabulous job at creating Castle blog aggregator. You now have one all things Castle RSS feed to subscribe to instead of hunting for content on many various blogs. It has some rules set so that it collects content from only a handful of blogs, skipping posts that are not related to its main topic. It comes mostly from committers and few other blogs that have proven in delivering high quality content. If you know any blogs that you think should be added to the...
So far we covered most of basic features of Dynamic Proxy, except for one – mixins. Not getting into theoretical details, mixin is an object that stitches many other objects together, exhibiting behaviors of all these objects. Let me illustrate that in pseudo code: var dog = Dog.New();
var cat = Cat.New();
var mixin = mixin(cat, dog);
mixin.Bark();
mixin.Meow();
In most languages this is achieved through multiple inheritance, but this is not allowed in the CLR, which imposes certain limitations on how mixins are implemented and work in Dynamic Proxy. We can’t have...
On the course of last few months, I’ve been working with Craig Neuwirt, on what I consider one of the coolest additions to Castle WCF Integration Facility.
Problem
As you probably know by default all WCF calls are synchronous – you make a request, under the cover WCF blocks your thread using a WaitHandle waiting for response, then it unblocks your threads making it look like a local call. This makes things simple for a programmer, who does not have to deal with synchronization, but it’s an overkill from scalability and performance perspective.
There are also one way calls, often mistakenly called ‘fire...
If you’ve been following the tutorial, you should remember that Castle Dynamic Proxy provides proxying capabilities by generating types at runtime. Dynamic code generation is not a lightweight operation, so pretty important aspect of Dynamic Proxy is its caching mechanism which we’ll going to cover in this post.
Let’s consider the following piece of a test:
var proxy1 = generator.CreateClassProxy<Foo>(new FooInterceptor());
var proxy2 = generator.CreateClassProxy<Foo>(new BarInterceptor(), new FooInterceptor());
Assert.AreEqual(proxy1.GetType(), proxy2.GetType());
Will it succeed? The answer is – yes. In this simple case both proxies would be semantically identical, so generator (or more precisely IProxyBuilder that the generator is using) caches the type that...
So far in the tutorial we’ve covered most of the basics. However, we were always proxying just one type, be it a class or an interface. There is quite often a need to do more. What if a class implements more than one interface, and we want them all proxied? What if we want the proxy to implement interfaces the target type does not implement. Today we’ll talk about how to do just that, so let’s get straight to it. If you look into the API you may notice that for every kind of proxy there are overloads that...
As I hinted in my previous post, here comes another release from Castle Land. This time it’s Castle Windsor, No more – “we’ll not use a two year old prerelease software.”. Ayende has all the details, so I’ll just say that if you’re still using RC3 there’s a lot of new good stuff waiting for you. Congratulation to Ayende and the whole Castle Team. Grab the bits here.
Final version of Castle Dynamic Proxy 2.1 is officially released as of today. For the announcement see Jonathon’s blog. This is the first release since the split of monolithic Castle Project into independent projects. It also opens a way for all other projects depending on Dynamic Proxy to get a release (some of them will be released very soon). Also I want to remind you of Castle UserVoice site, where you can suggest features and improvements you’d like to see in the next version. Not only for DynamicProxy, but for any project under Castle umbrella....
I’ve been doing a lot of work with WCF lately. It’s a great framework, and I really like it, but it has its drawbacks. First of all, it is overly complicated in certain places (security!), which makes it really hard to use sometimes. Its sheer size, makes it also hard to grasp. It has a lot of extensions points but the fact that you have to plug into them yourself adds to that complexity. It simply begs for good IoC integration.
You can partially alleviate that by using Castle WCF facility that lets you use IoC container to extend WCF, but...
After a longish break we’re back to the Castle Dynamic Proxy tutorial.
The three kinds of proxies we talked about so far (class proxy, interface proxy with and without target) are the only kinds of proxies most users will ever use. There is however one more kind – interface proxies with target interface.
When I say most users will never use it, by most I mean roughly 99%. I, personally haven’t used it. Whole Castle project stack uses it in only one place that I know of – WCF facility. This proxy kind is used in really rare cases, and you can...
UserVoice is a very nice Web 2.0-ish web application, where users of different projects can speak their mind about projects in question. I like it for its clear interface, readability, and very low friction. Users can suggest improvements to projects, comment and vote on other suggestions. Project owners can give feedback to users, and official responses to suggestions. Some projects I use often like AnkhSvn, and StackOverflow use it as an official channel of feedback, and it seems to work very well. I thought Castle Project could use that too, so few days ago I created a site for...
Quiz Consider the following piece of code (it shows Castle MicroKernel, but since Windsor is built on top of MicroKernel, it works the same way): IKernel kernel = new DefaultKernel();
kernel.AddComponent("sms", typeof(IAlarmSender), typeof(SmsSender));
kernel.AddComponent("email", typeof(IAlarmSender), typeof(EmailSender));
kernel.AddComponent("generator", typeof(AlarmGenerator));
AlarmGenerator gen = (AlarmGenerator) kernel["generator"];
Considering AlarmGenerator has a dependency on IAlarmSender, which one of two registered components will it get?
The answer is: the first one.
In this case we registered SmsSender first, so it will get injected. If we switched the order of registration, EmailSender would get injected. It does...
Patrik Hägne has an interesting post on removing compile time dependencies between assemblies, while still reaping benefits of using fluent interfaces to bootstrap AutoFac container (go read it, I’m not going to reiterate what Patrick wrote) using MEF. It inspired me to do similar thing for Castle Winsor. I created a simple solution with 3 project. One is the main application entry, which also holds a MefInstaller which we’ll talk about in a second. Second one: Services, contains interfaces that our application rely on. Impl contains implementation of these interfaces. Pretty simple huh? The...
This is part VII of my ongoing tutorial on Castle Dynamic Proxy. If you are new to it, you probably want to read previous parts first:
Introduction
The what, why and how
Selecting which methods to intercept
Breaking hard dependencies
InterceptorSelector, fine grained control over proxying
...
This is part VI of my ongoing tutorial on Castle Dynamic Proxy. If you are new to it, you probably want to read previous parts first:
Introduction
The what, why and how
Selecting which methods to intercept
Breaking hard dependencies
InterceptorSelector, fine grained control over...
This is part V of my ongoing tutorial on Castle Dynamic Proxy. If you are new to it, you probably want to read previous parts first:
Introduction
The what, why and how
Selecting which methods to intercept
Breaking hard dependencies
Our Freezable library is starting to work quite well. However, there are still few glitches we need...
In the last part of the tutorial we created a method GetInterceptedMethodsCountFor that I promised I’ll talk about soon. While we’re at it, we’re going to fix another design flaw of our Freezable class.
To do its work, it holds a hard reference to each and every freezable object it creates. This is obviously not a big deal if you create only a handful of freezable objects that are we want to be alive for the entire time the application is running.
private static readonly IDictionary<object, IFreezable> _freezables = new Dictionary<object, IFreezable>();
However, in most cases the objects we create are transient,...
Welcome to the 3rd part of my Dynamic Proxy tutorial.
If you’re new here, you may take a look at previous parts first
Castle DynamicProxy tutorial part I: Introduction
Castle Dynamic Proxy tutorial part II: The what, why and how
We’ll start by updating our CallLoggingInterceptor class, so that we can use it in tests. What we need from it, is to enhance its functionality, so that it not only logs (to the Console) the calls, but also keeps a count of calls. To do that we add a property called Count, which gets incremented each...
After my first attempt at making IInterceptorSelector support in DynamicProxy actually work, there has been a discussion on castle-dev discussion group, about the implementation, its implication and features. To make long story short (find and read the thread if you’re interested) I set up to redo the implementation, moving most of the code that was generated at runtime into another, statically compiled class. Finally yesterday I had some time to actually start working on the implementation, but fixing bugs with code-gen at 1am proved to not be my strongest skill, so I finished the implementation today. Funny thing is, I...
I just got this test pass:
[Test]
public void BasicCase()
{
ProxyGenerationOptions options = new ProxyGenerationOptions();
options.Selector = new AllInterceptorSelector();
var target = this.generator.CreateInterfaceProxyWithTarget(
typeof(ISimpleInterface),
new SimpleClass(),
options,
new NoopInterceptor() ) as ISimpleInterface;
Assert.IsNotNull( target );
target.Do();
}
And here’s how Do proxy method looks like in...