Can I have a section of App_Code which compiles separately from the rest of the folder?

Question

We have a website with a huge amount of Cached objects stored in static variables within App_Code. Whenever we push an App_Code change to our production webservers it recycles the IIS pool and flushes the cache. It does not flush the cache however when we push out changes to .aspx and .aspx.cs files.

I need to have a bunch of classes that will be updated several times a day to be able to be referenced in App_Code. I would like either a section of my App_Code which I can update several times a day without cycling IIS and flushing my cache, or the ability to reference classes outside of App_Code from within App_Code.

Is there a solution that fits my problem?

Answer 1

Updates to App_Code or /bin/ always recycle your application pools I believe. If you're saying that you have a deployment scenario where .aspx.cs file updates do not recycle your application pool, and if you're able to refer to the page type itself, perhaps you can move your code into the .aspx.cs files so prevent the recycling from happening. That's may be an ugly choice though.

One suggestion is to revise your design to reduce the number of source code updates that are required on a daily basis. Perhaps use XML or database storage, and design your application to be a little more generic, and less prone to binary updates.

Or perhaps partition your application into several smaller virtual applications. The level of effort could be higher to do this, but in this case if your application is more compartmentalized, you won't have to recycle the entire app with each and every deployment. You'd only have to recycle the modules that were impacted with your deployment.

Another suggestion might be to setup clustered server architecture. Schedule the deployments to apply to one cluster node, keeping only the other active while the scheduled update is occurring, and then roll out updates to the second node once the first node update is done the app pool recycled.

Another suggestion would be to change your deployment times to less off-peak times, if that's feasible.

Are the frequent updates happening just because there are a lot of development changes happening?

Answer 2

Another angle would be to use a distributed cache solution instead of HttpRuntime cache.

HttpRuntime cache has two major drawbacks:

1) It is flushed when your app domain recycles. This is by default done every 29 hours anyway, even if you don't modify App_Code.

2) It is localized to a single web server. So if your web server needs to scale to a larger web farm, your cache becomes less and less effective, because cache entries are not in sync across all web servers.

Distributed cache solutions sidestep these issues by creating a separate cache layer in between your web tier and your back end data source.

Example solutions:

• memcached
• redis
• Oracle Coherence (commercial)

Of course, this will result in a more complex architecture and will require more hardware or VMs.