Scott Hanselman

Using the ASP.NET Cache outside of ASP.NET

November 23, '05 Comments [12] Posted in ASP.NET | NUnit
Sponsored By

Travis was talking about using the ASP.NET Cache object/subsystem outside of ASP.NET. I found it a little creepy as I've had all sorts of trouble trying to to Mock testing with ASP.NET outside of IIS and ended up using Cassini back in the day.

He convinced me though, check out the sample code on his site. I also started a conversation on a list server and here's what came of that:

Rob Howard said:

Yes, it's fairly common (and easy) to do. You just have to include a reference to the System.Web assembly in non-web applications; which may have led to your "creep out" – for what it’s worth it used to do the same to me :) 
FWIW, I believe (from memory) the recommended way you grab a reference outside of a web application is:
using System.Web;
using System.Web.Caching;

Cache cache = HttpRuntime.Cache;
<snip>...the Cache is just too important of a feature to only belong to ASP.NET.

Scott Stanfield said:

The biggest problem you'll run into using the cache outside of a web app is simply the namespace: System.Web. People freak out in code reviews. We got a lot of trash talk from the J2EE world on PetShop because of this.

Chris Kinsman said he seemed to remember some trouble with the Cache not sticking around in memory when used outside of ASP.NET, but that hasn't been substantiated. I'm going to dig more.

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.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Wednesday, November 23, 2005 6:50:37 PM UTC
Where I used to work, we commonly used the System.Web namespace for MailMessages in non-web applications. I've never tried it for using the cache, but I seem to remember someone in a google group using HttpCookie in a WinForm app not that long ago.

I've never used the VisualBasic namespace, what's in there that's useful? Removal of short-circuiting? :P
Marty Thompson
Wednesday, November 23, 2005 7:23:09 PM UTC
Why not use the Enterprise Library Caching Block from MS Patterns & Practices?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/caching1.asp
Wednesday, November 23, 2005 7:26:28 PM UTC
As long as you use it as a cache with proper fallback on regular data calculation/retrieval, it works great in non-web apps or even libraries that could be used in either scenario. The big pitfall is that the cache will gladly let go of data before it has actually "expired" in scenarios like low memory. I suppose that advice goes for using it ASP.net as well. I've just seen people use it like a big global Hashtable in an app, and then it breaks under stess because things are going away and they think something is wrong with it.
Wednesday, November 23, 2005 7:26:55 PM UTC
In my opinion that block has way too many moving parts. Using the ASP.NET Cache is fairly lightweight, and includes the very useful cache dependancies stuff.
Wednesday, November 23, 2005 8:10:08 PM UTC
public sealed class CacheProvider
{
private CacheProvider(){};

public static Instance
{
get
{
return (HttpContext.Current == null) ? HttpRuntime.Cache : HttpContext.Current.Cache;
}
}
}

or the 2.0 version

return (HttpContext.Current ?? HttpRutime.Cache);
Wednesday, November 23, 2005 8:20:20 PM UTC
I like to pull in the J# DLLs, too. Just to REALLY freak people out.
Wednesday, November 23, 2005 9:57:11 PM UTC
Still wonder why the FX team hasn't just moved caching into another (non web) namespace. It pwns for web stuff, but there's no reason you wouldn't want caching in other types of solutions. (And who wants all the bloat of the enterprise libs, etc.)

Honestly, just a simple static object that supports sliding expirations? Seems that that SQL Server 2005 folks would have been clamoring to get SQL Server Cache invalidation working for winforms/WPF applications too.
Thursday, November 24, 2005 9:35:17 AM UTC
karl...if you look (reflector) at HttpContext.Current.Cache all it does is return HttpRuntime.Cache.
Scott Hanselman
Thursday, November 24, 2005 12:55:43 PM UTC
Scott:
So always use HttpRuntime.Cache istead of HttpContext.Current.Cache ;) thanks

karl
Thursday, November 24, 2005 5:30:32 PM UTC
ObjectDataSource, anyone?

The problem with this one, as I recall, is mostly in setup.

It'd be nice to see BuildProviders pulled out, as well.

Re Cache vs EntLib: Cache has one singular advantage -- it's already there. As much as I pimped EntLib a year ago, it's a download-modify-and-compile project. With all do respect to the hard work that went into it: if I wanted that, I could use Java. I prefer my batteries included.
Keith J. Farmer
Thursday, November 24, 2005 10:28:21 PM UTC
EntLib Caching block is actually pretty easy to use. I too was concerned that it was a bit hefty/intertwined. If you spend a little time writing your first trival app with it, it planes out fast. It has the same types of dependencies and it allows you to do have a variety of stores (you can have two levels of cache with one backed with memory, one backed with db). It's grown on me for non-ASP.NET ctxs.
Grant
Monday, November 28, 2005 5:44:55 PM UTC
Most of the conversation has been around enterprise components and the use of ASP.NET cache. Can anyone think of a good reason why the use of the ASP.NET cache on the client side of a rich client app wouldn't work? For these types of applications, preventing a round-trip all together would be the ideal situation. Granted that with rich-client it's easier maintain state but why "roll your own" cache when there is a robust library to do just that. Thoughts?
Mike Morris
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.