This project is read-only.

WCF integration: Dispose not called on dependencies if exception is thrown from constructor

Jul 8, 2013 at 1:54 AM
Hi all,

I'm experiencing a problem with the SimpleInjector WCF integration.

I have a WCF service object "A" that has a dependency "B" injected. Both A and B implement IDisposable. Both A and B are registered using the WcfOperationLifestyle with disposeInstanceWhenOperationEnds set to true.

Under normal circumstances (i.e., no exceptions are thrown), the service runs correctly and B is correctly disposed when the service operation completes.

However, when an exception is thrown from A's constructor, Dispose is not called on B.

It seems as though IInstanceProvider.ReleaseInstance isn't called for service objects that fail to construct (which makes sense for WCF), but it doesn't end the SimpleInjector WCF lifetime scope.

Vanilla lifetime scopes work in the way I'd expect (i.e., B's Dispose is called when A throws from its constructor). Is this a bug in SimpleInjectors WCF integration?
Jul 8, 2013 at 5:11 AM
This seems like a bug. Can you supply me with the code and configuration to reproduce the problem?
Jul 8, 2013 at 5:56 AM
I have emailed through a simple project that demonstrates the problem. Let me know how you go :)
Jul 8, 2013 at 9:42 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jul 11, 2013 at 8:26 PM
Edited Jul 29, 2013 at 10:32 AM

I just checked in a fix for the issue. The issue was actually pretty serious, because the complete lifetime scope was never disposed in case object graph construction failed. This would mean that that scope would keep hanging around and could influence other requests as well, which is definitely not good. I peeked in the source code of another container and they seem to have implemented the same behavior, which probably means that that container contains the same bug.

I will publish a patch release of Simple Injector within a.s.a.p. This release will contain a fix for this issue including some other bug fixes.

Thanks for reporting this.
Jul 12, 2013 at 4:44 PM
This issue has been fixed in v2.3.1.
Marked as answer by dot_NET_Junkie on 2/26/2014 at 1:39 PM