Is it OK to use HttpRuntime.Cache outside ASP.NET applications?

Question

Scott Hanselman says yes.

Adding System.Web to your non-web project is a good way to get folks to panic. Another is adding a reference to Microsoft.VisualBasic in a C# application. Both are reasonable and darned useful things to do, though.

MSDN says no.

The Cache class is not intended for use outside of ASP.NET applications. It was designed and tested for use in ASP.NET to provide caching for Web applications. In other types of applications, such as console applications or Windows Forms applications, ASP.NET caching might not work correctly.

So what should I think?

Answer 1

Why not avoid the question completely and use the Caching Block of Enterprise Library? You could use the System.Web.Caching, but you probably won't get Microsoft support if you run into issues and you'll raise eyebrows so it might not be worth it.

Answer 2

One thing to keep in mind is that Microsoft have a released the .NET Framework Client Profile Setup Package. This is a version of the 3.5 framework that is targeted at client applications and has a reduced footprint. The Client Profile does not include the ASP.NET pieces of the framework.

If your application depends on System.Web it will stop your application being able to take advantage of the Client Profile.

See Scott Gu's Blog for more details.

Answer 3

Don't use it, even if it does work it can stop working in the next service pack/version.

The moment you do something based on internal implementation details and not the contract (in this case, MSDN) you can expect to get into trouble in the future.

Answer 4

There shouldn't be any problem with using HttpRuntime.Cache. It's a sophisticated in-memory hash-table that can be very useful outside of the web context. Still, it might be a bit of a code-smell to reference HttpRuntime.Cache in a non-Http related application, so it can be a good idea to wrap it behind some ICache interface and use that wherever possible.

Answer 5

There doesn't seem to be anything in current versions of System.Web.Caching.Cache that depend on the HTTP runtime except for the Insert() method that accepts a CacheItemUpdateCallback, so Scott is right for the most part.

This doesn't prevent Microsoft from modifying the class in the future to be more integrated with the HTTP infrastructure.

I wrote a WeakReference-based lightweight cache in another answer.

Answer 6

I once used it, but it didn't feel right and IIRC increased the memory footprint quite dramatically. Instead, I implemented my own lightweight cache mechanism which is surprisingly easy to do.

It utilized the WeakReference class which allowed the cache to keep references to the object, but also allows the Garbage Collector to reclaim the memory if the reference is unused.

The only thing I didn't have was a separate thread to clean up stale items in the cache. What I did do is if the cache had > x items in it, I would go through all the cached items and turf out the old items before adding the new item.

If you need something more robust, use something like the MS Enterprise Library Caching Application Block.

Answer 7

I realize this question is old, but in the interest of helping anyone who finds this via search, its worth noting that .net v4 includes a new general purpose cache for this type of scenario. It's in the System.Runtime.Caching namespace:

http://msdn.microsoft.com/en-us/library/dd997357%28v=VS.100%29.aspx

The static reference to the default cache instance is: MemoryCache.Default

Answer 8

If you are looking for a general solution: This is a typical situation for the dependency injection approach. Using this approach you can follow Scott Hanselman and MSDN!

Inject a System.Web dependency like HttpRuntime.Cache without having a System.Web reference in your library.