At the moment I'm implementing some piece of code that makes use of the HttpContext.Current.Application as some kind of caching system. To me it looks like it could easily be replaced by a static Dictionary though, removing the dependency on the HttpContext.
There is this question that is quite similar, but in the answer there is no explanation why anyone would ever go for the HttpApplicationState approach at all.
In summary: what particular problem does the HttpApplicationState solve that is not already solvable in a myriad of other ways?
You should not have a dependency on HttpContext anyway
You can define a interface contract for Cache mechanism
And then implement that by HttpContext, AppFabric and so on
Static will be shared across all http applications hosted within the same application pool, HttpContext.Current.Application would be scoped to the current app. They would only be equivalent if the app pool is hosting only one application.
Related
Are singletons in ASP.NET shared between users/sessions? And if they are, are there any safety considerations? Think serializing/deserializing vulnerabilities, thread safety etc.
Is it the way to go using settings from the database that are the same for all users?
Hand crafting the anti-pattern called "Singleton" in C# code is a really bad idea in general, ASP.NET or not.
The singleton lifetime that is supported in the dependency injection framework is a good idea if it does what you need.
I would advise you to only use it for read-only data, like settings, though. You don't have an application on the desktop as of old. Your application might be recycled on the fly, or maybe stretched across multiple nodes on a server farm. So suddenly your "singleton" is actually only a singleton if you have a single instance of your program running. Building your application so this becomes an artificial problem (i.e. the framework would support it, but your own code is build to fail if you actually do so) is not a smart way to go about this.
So to summarize: Singleton lifetime in your dependency injection container? Might be okay. Depends on your use case. An actual "Singleton" pattern in your code? Bad. Very Bad. Tells me you don't actually do any unit testing and nothing is planned to bring this application over a few thousand hobbyist users who don't care if your app is down every time you deploy.
We have an environment with a vendor deployed application to several front ends on it. It makes heavy use of the ASP .Net storage (Session, Application, and Cache). Problem is with the load this environment quickly brings IIS to it's knees with the amount of data it's trying to keep in memory.
The solution we are trying to go with is to override the storage mechanism and implement our own. (Specifically a Redis server to manage the storage)
We have implemented their cache interface and set up Microsoft.Web.Redis.RedisSessionStateProvider in the web.config to manage the session. That part all works fine. The problem is that the caching inside the vendor application does not always use their provided interface. Decompiling the dll and examining dump files show that there are several instances of them directly calling (for example):
HttpContext.Current.Cache.Insert(...) and HttpContext.Current.Application[...] = ...
Is there any way we can override the HTTPContext* calls so that they'll use Redis to cache instead of the Asp .Net application storage?
When it is a "3rd" party which uses HttpContext.Current you probably have no chance to change that behavior.
Is this other application running within your context (do you control the app domain). Or is it a standalone application?
I once tried to change HttpContext.Current.Cache for unit testing and ended up mocking the whole HttpContext because it was so very internal somewhere in the Microsoft stack.
All this is pretty hard to do, not really recommended and can lead to all kinds of other errors.
In short, don't use HttpContext.Current.Cache. Use something you can inject.
In general, libraries should never use that static context.
It is much more flexible to have abstractions + DI for those kind of things...
For caching, you could use CacheManager for example.
I have a legacy application that is extensively using HttpContext.Cache...
This application is now suppose to move to Windows Azure (multi-role).
It will of course cause problems with cache going out of sync on different roles.
I was thinking about injecting (I'm using Autofac) my "AzureCacheWrapper" (wrapper on Microsoft.ApplicationServer.Caching.DataCache) into HttpContext.Cache so legacy application continues working but uses Azure cache instead?
Normally we should implement something like ICacheProvider but unfortunately there are some 3rd party DLLs that are using cache that we don't have access to (and don't know when 3rd party library is using Http cache)
I don't think cache provider can be configured through web.config (like OutputCaching) so the only solution seems to me to somehow inject my implementation into Add/Insert/Get methods on Runtime Cache.
Unfortunately because of .NET implementation of System.Web.Caching.Cache (sealed class) I don't think I can override HttpContextBase to return different cache or inject into System.Web.Caching.Cache itself...
Thanks for any help! :)
I think your application needs code/architectural change...
If you had your own class which handles getting and setting the cache, Which may easier now to change your code/architecture in one place.
If you are going to use Single role then no problem exist in your scinario. If possible you can run your webrole in ExtraLarge slot.
I`m searching for a solution that would let me update an asp.net website with new pages that are defined in various assemblies without the primary appdomain unloading (i.e. xcopy to /bin won't work).
While the cross appdomain invocation seems to be crystal clear for me, would it be possible to "provide" a System.Web.UI.Page living in another appdomain to the appdomain that is serving ASP.NET requests?
Searching around build providers, virtual path providers and appdomains leaves me with a thought that the primary appdomain restart may be negligible compared to the effort and potential unstability of any secondary appdomain or custom build provider implementations.
Thanks for your ideas!
I don't think it's quite as onerous as you suspect. I've worked with cross AppDomain invocation for an Outlook add-in to dynamically load different versions and there wasn't much to it. I've not done it in ASP.NET though, so don't know what traps you might fall into there.
Personally, I would explore two options:
Hit a break-point on a Page_Load event and examine the stack trace. See the call by System.Web.dll - IExecutionStep.Execute(), which steps into your web apps DLL? Something further down the stack has registered or otherwise determined which Page class is going to handle the request. The trick? subvert the standard behavior (sorry, not sure where or how, but I vaguely recall reading something about this once).
Subvert / bypass more of the web pipeline by implementing a module to explicitly handle your requests.
Edit: To elaborate on option 1, PageHandlerFactory class is the one I was thinking of. http://msdn.microsoft.com/en-us/library/system.web.ui.pagehandlerfactory.aspx Of particular interest in the article is the comment "To build a custom page handler factory, implement the IHttpHandlerFactory and register the custom PageHandlerFactory class in the Web.config file for the application in the httpHandlers Element (ASP.NET Settings Schema) configuration section."
In other words, if you implement your own PageHandlerFactory, you should be able to handle page requests however you want, including handing the requests to another AppDomain.
Is there a way in .Net to switch out the Cache provider just like I would a membership provider, or role provider? I would like to keep the code untouched but switch to using a distributed cache like memcached or AppFabric.
All I am finding is how to switch out the output cache provider. This might be necessary, but it doesn't solve the issue of when Cache is called directly from within my code.
I've found many libraries and they abstract Cache behind an interface, but this would mean I have to go to every spot in my code and inject the new abstraction. Also I am using PLINQO, which internally uses Cache.
Is OutputCache the only thing I can switch out through configuration?
Thank you in advance.
You may take a look at the following presentation which explains the pre-.NET 4.0 state of caching and what .NET 4.0 brings in this respect. In .NET 4.0 the caching has been completely reworked into a separate assembly (System.Runtime.Caching) and rendered extensible. That's true for both object caching and page output caching. Unfortunately if you have current code that relies on the old Cache class this has to be changed as this class works with in-memory objects only.