The ResourceManager.GetObject () documentation states the following:

 If you call the GetObject method multiple times with the same name parameter, do not depend on the return value being a reference to the same object. This is because the GetObject method can return a reference to an existing resource object in a cache, or can reload the resource and return a reference to a new resource object.

Does this mean the ResourceManager caches objects or not? Arriving at my rm.GetObject invocation in the debugger and running the following snippet a few times results in different hash codes each time, leading me to believe the .NET 2.0 ResourceManager implementation is not doing any caching:

object o1 = rm.GetObject (name, culture);
o1.GetHashCode () 
...

On the other hand, I assume satellite assemblies are loaded into the app domain when they're first requested and resources are sitting there in memory--negating the need for caching (apart from any custom code and the resource location\fallback logic).

Any thoughts?

Secondly, where's the best place to store a reference to a ResourceManager object in an ASP.NET app? Should it live in the HttpApplicationState or global.asax or somewhere else? 

Are you sure you're looking at EXACTLY the same object? Different locale will give you a different hashtable.

I've built a number of custom resource managers and in checking the provider loading from database I've only ever seen the ResourceReader  pulling data once for each resource set. So yeah that stuff definitely gets cached, although it's possible that under certain conditions (memory pressure? AppDomain unload) that the resources reload, but I've never seen this.

In ASP.NET applications you shouldn't use a ResourceManager unless your loading assembly specific resources. If you're using ASP.NET's native functionality using the ResourceProvider and HttpContext.GetGlobalResourceObject/GetLocalResource object is the better way to go.

If you do need to tack on a resource manager make it a static somewhere with a static constructor. More effcient than using HttpApplicationState.

+++ Rick ---