我可以将 App_Code 的一部分与文件夹的其余部分分开编译吗？
我们有一个网站，其中有大量缓存对象存储在 App_Code 内的静态变量中。每当我们将 App_Code 更改推送到生产 Web 服务器时，它都会回收 IIS 池并刷新缓存。但是，当我们推送对 .aspx 和 .aspx.cs 文件的更改时，它不会刷新缓存。
我需要有一堆每天更新几次的类，以便能够在 App_Code 中引用。我想要我的 App_Code 的一部分，我可以每天更新几次，而无需循环 IIS 和刷新我的缓存，或者能够从 App_Code 内引用 App_Code 外部的类。
有适合我的问题的解决方案吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我相信，对 App_Code 或 /bin/ 的更新总是会回收您的应用程序池。如果您说您的部署方案中 .aspx.cs 文件更新不会回收您的应用程序池，并且您能够引用页面类型本身，那么也许您可以将代码移至 .aspx 中。 cs 文件，因此可以防止回收的发生。但这可能是一个丑陋的选择。
一个建议是修改您的设计以减少每天所需的源代码更新数量。也许使用 XML 或数据库存储，并将应用程序设计得更通用一些，并且不太容易进行二进制更新。
或者也许将您的应用程序划分为几个较小的虚拟应用程序。执行此操作的工作量可能会更高，但在这种情况下，如果您的应用程序更加划分，则不必在每次部署时回收整个应用程序。您只需回收受部署影响的模块即可。
另一个建议可能是设置集群服务器架构。计划部署以应用于一个集群节点，在计划的更新发生时仅使另一个节点保持活动状态，然后在第一个节点更新完成（应用程序池回收）后将更新推出到第二个节点。
另一个建议是，如果可行的话，将部署时间更改为更少的非高峰时间。
频繁的更新是否只是因为发生了很多开发变化？
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?
另一个角度是使用分布式缓存解决方案而不是 HttpRuntime 缓存。
HttpRuntime 缓存有两个主要缺点：
1）当您的应用程序域回收时，它会被刷新。无论如何，默认情况下每 29 小时执行一次，即使您不修改 App_Code。
2) 它被本地化到单个 Web 服务器。因此，如果您的 Web 服务器需要扩展到更大的 Web 场，您的缓存会变得越来越无效，因为缓存条目在所有 Web 服务器上并不同步。
分布式缓存解决方案通过在 Web 层和后端数据源之间创建单独的缓存层来避免这些问题。
示例解决方案：
当然，这将导致更复杂的架构，并且需要更多的硬件或虚拟机。
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:
Of course, this will result in a more complex architecture and will require more hardware or VMs.