Home/ Questions/Q 3795126
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T13:02:10+00:00

We have a website with a huge amount of Cached objects stored in static

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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?

    • 0