做Windows服务器（2008）caching.net程序集？

我的同事有以下问题（所以有些细节可能需要进一步审查）：

服务器是Windows 2008 Server。有一个正在运行的Windows服务（exe（.net），也使用.NET程序集）。有一些DLL和/或exe的错误。一些debugging消息被添加到和从DLL中删除。这个DLL的新版本及其重新编译的exe被ftp转移到这个服务器，服务被停止，现有的dll和exe被重新命名，并被replace为新的，服务启动。

我们仍然可以看到从DLL中删除的debugging消息。它们不存在于新代码中。

服务器重新启动。

旧的dll会被caching到什么地方？不知何故？谢谢。

UPDATE

以下事情发生了：

最近更名为assembly.old被删除（这是唯一的副本）
旧的debugging信息仍然在那里！
服务卸载/重新安装（虽然我们认为我们可以离开重启）
作品。

所以，知道这之前（包括操作系统的重启）发生了什么，以及现在发生了什么，不知何故/某些Windows正在跟踪DLL的（？），当一个副本重命名，Windows藐视更新和关联介意）该assembly.old将assembly.dll。不是新的assembly.dll放在它的位置？

由于assembly.dll和assembly.old在同一目录中，操作系统重新启动后 – 老dll不断地看着。 assembly.dll和没有assembly.old – 工程。

让我感到困惑的是你如何控制这个？或者这个文档在哪里？

其他信息：服务器的64位版本。一个VM。

这可能是由于.NET如何查找程序集，请参阅以下文档：

.NET运行时如何find程序集
http://msdn.microsoft.com/en-us/library/yx7xezcf%28v=VS.100%29.aspx

请注意以下几点：

“编译器会在构build时在程序集清单的元数据中logging静态引用，dynamic引用是由于调用各种方法（如System.Reflection.Assembly.Load）而dynamic构build的。

如果您的引用是静态的，那么您可以检查清单执行程序集的元数据。可以使用ILDASM或其他工具（如ILSpy）来检查清单。如果是dynamic的，定位过程复杂而复杂。

我的经验是，如果存在多个CLR版本（例如2.0和4.0），结果可能是意想不到的。还有其他几个因素，例如：

机器configuration和应用程序configuration;
如果应用程序是全部托pipe代码，或者有一些非托pipe代码（COM / Interop）;
如果执行/调用程序集和调用程序集是独立于平台（“任何CPU”）或特定于平台的（x86或x64）。

也可以同时在进程中运行2.0和4.0 CLR代码（并行执行）。

我认为这应该在开发环境中是可重复的，期望消费者知道或处理所有可能的情况是不现实的。

.NET进程内并行执行
http://msdn.microsoft.com/en-us/library/ee518876%28VS.100%29.aspx

程序集：定位，绑定和部署
http://www.codeproject.com/KB/install/assemblydeployment.aspx

当您运行Microsoft SysInternals的Process Explorer时，请select服务进程和.NET程序集选项卡，它应该会显示所有各种加载的程序集，以便您可以validation是否加载了正确的文件：

在这里输入图像说明

那么你在那里回答你自己的问题。你把一个新的DLL放到你的磁盘上，但是当你运行一些代码时，它似乎还在使用旧的DLL。因此，必须有一个旧的DLL的副本仍然留在你的记忆中的某个地方。

试试这个 – 创build一个快捷方式，并使用这个命令来运行：

％windir％\ system32 \ rundll32.exe advapi32.dll，ProcessIdleTasks

把它命名为“Memory Cache Flusher”。在程序的testing运行之间运行它。