多程序集场景下编译单个程序集后LINQPad缓存丢失问题咨询

这不是LINQPad特有问题，本质是.NET程序集加载机制的预期行为，LINQPad的运行模式只是让这个现象更直观。

核心原因：程序集加载与静态缓存的生命周期 #

• .NET中，每个加载到应用域的程序集都是独立的实例：如果程序集（比如你的Data Assembly）被重新编译，哪怕只是修改了引用它的Calculation Assembly，CLR会将新编译的程序集视为完全不同的组件，不会复用之前加载的旧版本。
• 缓存通常存在于静态字段中，而静态字段是绑定到程序集的类型上的。新程序集加载后，对应的类型会重新初始化，静态缓存字段自然是空的——旧的缓存还在旧程序集的实例里，但新代码无法访问，所以看起来像是“缓存丢失”。

为什么修改Calculation Assembly会触发缓存重置 #

• 当你重新编译Calculation Assembly后，LINQPad在运行时会加载这个新的程序集副本，同时会为它重新加载依赖的Data Assembly（即使Data Assembly本身没修改）。
• 这种情况下，Data Assembly的新实例会被加载到应用域，其静态缓存字段会重新初始化，自然没有之前的数据。

LINQPad的特殊运行逻辑 #

LINQPad默认每次运行都会创建新的应用域或隔离加载程序集，不会复用之前的运行环境。这意味着：

• 每次重新编译运行，所有相关程序集都会被重新加载，静态状态（包括缓存）都会被重置。
• 而在常规桌面应用中，如果不重启应用，直接替换程序集可能会遇到文件锁定，但如果是通过热重载修改代码（不重新加载程序集），缓存可能保留。但一旦重启应用，程序集重新加载，缓存同样会重置。

结论 #

缓存丢失是.NET的预期行为：程序集重新加载后，类型的静态成员会重新初始化。LINQPad的运行模式让这个行为更明显，但本质是CLR程序集加载规则导致的。

内容的提问来源于stack exchange，提问作者Eugene