It is now wednesday evening, … and I know.
Overshooting my estimate by two days.
I think it’s a component burden issue.
I have been using Castle.Windsor quite a lot lately, because I really like the way it allows the imperative programmer to use functional constructs.
I have been pushing the container to the limit, and surprisingly enough, it has never let me down.
The more I learned, the more code I could remove.
The more I demanded, the more it delivered, and there was even more (infrastructure/implementation) code I could remove.
Making the whole model much more declarative and reusable.
Today it let me down.
It’s still my favourite dotnet lib ever though.
[Fact]
public void StrangeSingleCallToRelease()
{
IWindsorContainer container =
new WindsorContainer()
.Register(Component.For<MyComponent>()
.LifeStyle.Custom<SingletonLifestyleManagerSpy>());
var componentOne = container.Resolve<MyComponent>();
var componentTwo = container.Resolve<MyComponent>();
Assert.Equal(componentOne, componentTwo);
Assert.Equal(2, SingletonLifestyleManagerSpy.TimesResolved);
container.Release(componentOne);
Assert.Equal(1, SingletonLifestyleManagerSpy.TimesReleased);
container.Release(componentTwo);
Assert.Equal(1, SingletonLifestyleManagerSpy.TimesReleased);
}
I don’t get this without looking at the Castle.Windsor code.
The boolean returned by the lifestyle managers resolve function seems to serve as a guard for not destroying the components any singleton (or perwebrequest and the likes) depends on.
Still, very implicit behaviour.
Not sure if it would affect performance much, but if this boolean could serve the purpose of not removing the instance from the ReleasePolicy’s (component-) Burden collection, I reckon it would lead to a much more intuitive API.
And my naive implementation, mentioned above, would work
I do have a workaround, but its rear-end-ugly.
Any thoughts ?