Home/ Questions/Q 7490753
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T15:45:50+00:00

I have class instantiated in a web service that, in a static member, holds

  • 0

I have class instantiated in a web service that, in a static member, holds on to some resources. If I was not statically holding on to these resources, I’d probably access them through some IDisposable object where I could release the resources on Dispose. Regardless of whether or not holding on to this session is a good idea, does .NET provide any way to call any clean up code when a type is statically deconstructed?

PLEASE DO NOT ANSWER THIS QUESTION WITH ANYTHING LIKE “STOP HOLDING RESOURCES IN A STATIC MEMBER VARIABLE”. I understand the drawbacks to holding on to this information statically and am willing to accept the consequences (we’re using it to cut processing time from 58 hours to 4 hours for some batch processing that we do). The question specifically is: given this situation, is there anyway for me to nicely clean up those resources?

EDIT:
I understand that the class will live for the rest of the process, but with static constructors .NET gives you the opportunity to do something when that type is loaded into memory. Can you do anything on the opposite end?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There actually is no way to do it from managed code. What you want is to handle your assembly being unloaded, but that doesn’t happen under most circumstances when you want it to.

    In more detail:

    There is an AppDomain.DomainUnload event ( http://msdn.microsoft.com/en-us/library/system.appdomain.domainunload.aspx ) you can handle. This handles when your application domain gets unloaded from its hosting process (say ASP.NET).

    However, if you are an EXE, or the hosting EXE is being recycled, this will not be raised. If you set up correctly, you might be able to handle the native DLL_PROCESS_DETACH and bounce that back to managed code, but because of the loader lock you will have to be very careful what you do from that context (anything that triggers an assembly load will deadlock).

    You can read this for some insight on what cleanup is requited (hint: not much): http://blogs.msdn.com/b/oldnewthing/archive/2012/01/05/10253268.aspx

    Basically, the only thing you need to worry about is flushing buffers to disk, and if you need to do anything more complex, you have already screwed up. malloc(), and therefore new() could crash your program instantly. This applies to managed code as well.

    • 0