我可以将 App_Code 的一部分与文件夹的其余部分分开编译吗？

Question

我们有一个网站，其中有大量缓存对象存储在 App_Code 内的静态变量中。每当我们将 App_Code 更改推送到生产 Web 服务器时，它都会回收 IIS 池并刷新缓存。但是，当我们推送对 .aspx 和 .aspx.cs 文件的更改时，它不会刷新缓存。

我需要有一堆每天更新几次的类，以便能够在 App_Code 中引用。我想要我的 App_Code 的一部分，我可以每天更新几次，而无需循环 IIS 和刷新我的缓存，或者能够从 App_Code 内引用 App_Code 之外的类。

有适合我的问题的解决方案吗？

Answer 1

我相信，对 App_Code 或 /bin/ 的更新总是会回收您的应用程序池。如果您说您的部署方案中 .aspx.cs 文件更新不会回收您的应用程序池，并且您能够引用页面类型本身，那么也许您可以将代码移至 .aspx 中。 cs 文件，因此可以防止回收的发生。但这可能是一个丑陋的选择。

一个建议是修改您的设计以减少每天所需的源代码更新数量。也许使用 XML 或数据库存储，并将应用程序设计得更通用一些，并且不太容易进行二进制更新。

或者也许将您的应用程序划分为几个较小的虚拟应用程序。执行此操作的工作量可能会更高，但在这种情况下，如果您的应用程序更加划分，则无需在每次部署时回收整个应用程序。您只需回收受部署影响的模块即可。

另一个建议可能是设置集群服务器架构。计划部署以应用于一个集群节点，在计划更新发生时仅保持另一个活动节点，然后在第一个节点更新完成（应用程序池回收）后将更新推出到第二个节点。

另一个建议是，如果可行的话，将部署时间更改为更少的非高峰时间。

频繁的更新是否只是因为发生了很多开发变化？

Answer 2

另一个角度是使用分布式的缓存解决方案而不是HTTPRUNTIME CACHE。

httpruntime缓存有两个主要缺点：

1）当您的应用域回收时，它会冲洗。默认情况下，即使您不修改app_code，这是默认情况下每29小时完成的。

2）它本地化为单个Web服务器。因此，如果您的Web服务器需要扩展到较大的Web农场，则您的缓存越来越降低，因为缓存条目在所有Web服务器中都不同步。

通过在Web层和后端数据源之间创建单独的缓存层，分布式缓存解决方案避开了这些问题。

示例解决方案：

• 备忘录
• Redis
• 甲骨文连贯性（商业）

当然，这将导致更复杂的体系结构，并且需要更多的硬件或VM。