GetManifestResourceStream返回不同版本的嵌入式XML文件

Question

背景

编码的UI测试用例正在访问嵌入在开发团队创建的DLL中的XML配置文件。测试用例验证UI是否显示XML文件中提供的相同配置值。 （UI应该从此XML文件加载配置。）

测试用例可以访问XML文件，如下所示：

Assembly assemblyWithResource = Assembly.LoadFrom(assemblyFile: @"C:\Program Files (x86)\Install Location\DevCreated.dll");
Stream stream = assemblyWithResource.GetManifestResourceStream(name: ConfigFileName.xml);

当测试用例执行时，从GetManifestResourceStream调用返回的流不正确。测试用例失败，因为UI值与XML配置值不匹配。 UI显示当前版本的XML文件（正确）。从执行代码返回的流来自旧版本的XML文件（错误）。

这是在敲定架构/框架计划时编写的第一个测试案例之一，因此它已经执行了一年多没有问题。

调试

重复性

只能通过在测试VM环境中通过MTM运行测试用例来重现问题。无法重现在我的个人计算机上运行测试用例，通过MTM在另一个配置的测试VM上运行测试用例或我通常的试用/错误deubg - 将测试用例的内容撕成控制台应用程序。我喜欢这样做，所以我不必乱用检查代码和部署的开销（并且可以轻松地将代码传递回开发团队，而无需他们处理它）。

运行代码，其中测试用例从原始测试用例失败的同一测试VM上的普通旧控制台应用程序中的DLL（上面显示的两行）获取XML文件，返回正确的XML文件内容。

已部署的测试用例代码与控制台应用程序代码的差异

最初专注于MTM执行的测试用例与控制台应用程序之间的不同之处，因为它们可以在同一个VM上运行。查看了大会的以下信息：

• Location，CodeBase，HostContext，GlobalAssemblyCache，PermissionSet
• 从GetManifestResourceNames和ManifestResourceInfo的ResourceLocation转储数组

所查看的任何程序集属性都不相同。看起来好像测试用例代码和控制台应用程序代码从同一位置加载相同的DLL并访问相同的嵌入式文件名但获得了不同版本的文件。

花时间在TFS中挖掘并确实找到了包含与MTM执行的测试用例相同的XML文件的开发代码版本 - 它大约有6周的时间。它在3周前发生了变化，此后一直失败。这确定了基于变更集的时间段。

此DLL中没有嵌入其他XML文件供查看。嵌入在同一时间段内看到更改的其他DLL中的XML文件似乎正在正确加载。

DLL不在GAC中，所有其他不属于已安装版本的DLL都已从VM中删除。

在开发方面，XML文件是使用嵌入式资源的构建操作设置的，不会复制到输出目录。

我已经完成了一定数量的额外研究，以了解有关GetManifestResourceStream调用如何工作的更多信息 - 似乎任何问题都将返回一个空流（不是一个不同的文件）以及如何包含嵌入文件在集会中。

问题

接下来要尝试什么？我正试图缩小关注范围以继续挖掘：

• 这是一个问题，源于开发团队如何构建此DLL？
• 安装程序如何包含/打包DLL是一个问题吗？ （目前正在卸载并计划从构建的drop文件夹中复制/粘贴应用程序和DLL以消除安装程序。）
• 在执行测试用例的VM上是否存在环境问题？
• 将应用程序部署到VM进行测试的问题是什么？
• 测试用例如何部署到VM进行测试是否存在问题？ DLL地狱？

VM将很快重新成像，此时我担心这个问题会消失。这是我的一个非常大的问题，因为我们没有意识到测试用例是使用了错误版本的XML文件。

更新

在尝试不使用安装程序的过程中，将应用程序和DLL复制/粘贴到测试VM上，IIS相关的东西搞砸了，我最终重新做了VM上与IIS相关的大部分事情。从来没有让复制/粘贴工作（因为IIS /配置的东西）所以重新安装应用程序，现在我不再看到测试用例失败。那么IIS与DLL中的嵌入文件有什么关系呢？