Module Lifetime (destruction issue)

Dec 12, 2008 at 12:17 PM

I have a module that uses a resource that should be closed before the application starts garbage collecting the works.

I can think of several ways to do it, but I thought I'd ask if anyone out there has a  good pattern for it.

One option I tried was to call 


in a new Bootstrapper.Close() method which I hooked up to Application.Current.Exit, but that an infinite recursion => stack overflow. It seems that the UnityBootstrapper adds the container to itself (see this post).

My next attempt will be to, instead of disposing the container, publish an event ApplicationExit which any module may subscribe to. Anyone have an opinion of this, or a better idea?

(Wouldn't it be nice to have an IModule.Close method?)

Dec 14, 2008 at 1:12 AM

I could make some assumptions here and try to reply but I got a bit lost. Can you please provide a bit more info of what resources you need to close, and what do you mean by closing resources before GC collecting the works?
You cannot dispose the root Prism unity container, or you can but you application will be gone as well and stack overflow exception is expected in this case. Also even if you would manage to get notification before GC, you would not be able to obtain the reference for your object as the GC would not collect it f there would be references. 

Anyhow, if you can provide a bit more info of what you want to accomplish...

Dec 14, 2008 at 5:35 PM
Edited Dec 15, 2008 at 11:15 AM
I'll gladly provide more info.

My issue is that I have a WCF service which uses uses stateful semantics. My module calls the service which creates a computationally expensive report assigning it a certain report id. My module will call the service several times to access various parts of the report. When my module won't need the report it should call a service method 


in order to free memory from the service. Specifically, when the applicaiton exits, the service method should be called. The service is shared between many clients.

The service design is of course not the primary choice one would make but for performance reasons we had to make some sacrifices.

By the way: Calling the service method from the finalizer won't work because apparently it will use an already disposed object, resulting in an ObjectDisposedException.

Dec 15, 2008 at 12:42 PM



This is a known issue that was solved in Unity 1.2 which is used by Prism-v2, as Bob Brumfield explains in an Issue Tracker WorkItem. If you want to use Unity with Prism-v1 you might find this post by Ade Miller useful:

·         Composite Application Guidance for WPF with EntLib 4.1


After doing this, you can remove the Container.RegisterInstance<IUnityContainer> from the UnityBootstrapper.cs file.


Please let me know if this helps.


Damian Schenkelman