The past months I have been working for a large international company in building a new back office solution. This solution is based on the Smart Client concept where we use zero touch deployment from .NET 1.1 (There are some difficulties upgrading the desktops to XP SP2 and therefore we can’t use Click Once and .NET 2.0)
In a smart client application that uses multiple back office service, you need to be very careful in terms of roundtrips you make to the services. Especially because our application is used for data entry purposes we need the application to perform really well. For that reason we need to cache data when possible and we decided in our design that we would use the ASP.NET cache object to provide us with a good cache implementation. The ASP.NET cache already implements the concept of removing items based on least recently used, provides expiration options like sliding window, absolute, etc and very well suits the needs for many .NET applications.
The thing is that our client application gets deployed on a web server within the intranet. This means our application will run with the permission set of the local intranet zone!
Now here we get to the point where out of the box “security” makes the cache object completely unusable…..
Probably during a security push for ASP.NET they have decided to request the AspNetHostingPermission. when using the cache object. While this sounds good in a Web Scenario, this becomes a real big problem when using it outside this context. It also is no problem when you have used the cache object and have a full trust permission set like you get when deploying an application to the desktop but this bites you very hard when you want to use the cache in a scenario that hase any permission set below full.
Now you can of course change the defaul permissionset the application gets when downloaded from the URL, but this requires you to change the configuration of the desktop machines. The change required is placed in your machine configuration and this is a big problem in large organizations. Updating a security policy on tens of thousands of desktops is very challenging from an organizational, procedural and policy perspective. The technical aspect is the least to worry about. So here we pay a very high price to the fact the AspNetHostingpermission is requested.
I have asked around why the permission is demanded and there seems no real security reason to do so. The cache object is perfectly save to use outside the ASP.NET context but it seems that the request is added with a security push. It looks like the fact that the cache object is part of the System.Web namespace caused this permission request. I would say that the cache is a multipurpose component to use and the System.Web namespace is a wrong namespace in the first place.
So I logged this issue now as a bug at the MSDN feedback center.( https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=176368) If you guys feel the same and would like to get this fixed in the next release of .NET, you might want to vote for this bug. Click the obove link and vote at the feedback center. Perhaps this can convince the team to remove it and then we can at least in the future use the cache outside the context of ASP.NET.
While this is not a solution for my current project, I do hope it gets fixed. This will help a lot of developers out there to focus on stuff that brings business value in stead of writing pluming again.