In ASP.NET 2.0 ResourceProviders allow extension of the native resource mechanism with your own resource backing store by implementing a custom ResourceProvider. I’ve recently published an extensive articlethat talks about this process in detail and why this can be quite useful.

One of the issues that I’ve been struggling with is that the ASP.NETResourceProvider(s) are not directly accessible from your ASP.NET code. ASP.NET basically gives you access to HttpContext.GetGlobalResourceObject() and HttpContext.GetLocalResourceObject() but that’s about as close as you can get to the loaded providers ( ASP.NET actually loads many instances of providers – one for each resource set).

Since I built a provider that allows live resource editing as part of the application, and so it’s only logical that you would want to see the changes in the resource provider either immediately or after explicitly refreshing the resources. As it turns out this is not easy to do because ASP.NET hides the Providers from you. No unloading for you!

In the past I’ve used a hack http://west-wind.com/WebLog/posts/5688.aspxto accomplish this: Basically force the AppDomain to unload by either calling HttpRuntime.UnloadAppDomain() or even more hacky by touching web.config causing the timestamp to change and thus forcing ASP.NET to reload the application. Both of these actually work, although both have security issues you need to worry about. The former requires full trust, the latter that you have write file access rights to Web.config neither of which is guaranteed to be available.

*A better way: Hang on to your Hats – er, Providers*

So as I was wrapping up my article I got to thinking about this problem again. With a custom provider implementation it’s actually possible to keep track of the providers as they are loaded. Once you have a list of the providers, unloading the resources is really not difficult – since resources are typically cached in Hashtables/Dictionaries in memory it’s easy to clear them out by releasing each of the dictionaries holding the resource data.

So here’s what I did in my provider (which otherwise is fairly standard implementation so this should be easy to apply to any custom implementation).

I set up a static LoadedProviders property (List<>) that keeps track of all the loaded provider instances, and a method called UnloadProviders() to loop through the list and then call a custom interface method that unloads the providers.

volledig artikel http://www.west-wind.com/weblog/posts/121171.aspx