.net 程序集引用和绑定的自动测试

这一个没有代码示例，只是一个总体问题：

有没有一种好的方法来测试GAC是否与配置引用相匹配，配置引用与为部署而构建的DLL相匹配

我的团队一直在整个应用程序中升级.NET，我们遇到了几个与挂起DLL和不匹配引用相关的问题，这在部署时造成了很多问题。无论是在Debug中构建还是在Release中构建，这些都不会在本地弹出，尽管我们可以运行输出并找到引用错误，但似乎只有在部署到我们的一个环境后才会中断功能

使用FusionLog查找错误本身并不难，我们还可以查看构建输出以查看一些错误。我们已经通过logz.io设置了警报，以便在程序集引用不匹配时通知我们，但我的任务是找到一种方法，在这些差异传递到某个服务器之前，自动发现这些差异

我研究了是否可能创建一套单元测试来验证引用，但发现通过反射的程序集只允许我访问活动运行的代码，而不是应用程序范围的源代码和CurrentDomain程序集（在单元测试的上下文中）我们只代表单元测试和我们所需的一些框架

为此，最后的努力将是对配置进行解析，并根据bin或其他输出目录对其进行审核，但这似乎很麻烦且容易出错，而且仍然是一个解决方案，需要我们在发现问题之前部署一些东西，这只是浪费时间

---

如果有必要，我很乐意提供更多的上下文，但这是我第一次进入程序集及其内部，因此您的问题可能会引发我更多的问题。我非常感谢您对测试这一点的潜在自动化过程的任何帮助或见解，即使它只是朝着正确的方向推进。我在谷歌上搜索现有的测试或流程时运气不太好，所以我在这里只能坐以待毙。

“单元测试”不是。您应该能够轻松地使用Docker images开发集成测试用例，Docker images是一个自动化程序集获取的脚本，并在示例应用程序运行或崩溃时进行断言。我同意不是这样。最初问我的是单元测试，我已经确定这不是方法。我犯了一个错误，我想我已经试过了。我不知道对具有相同程序集的不同应用程序进行关联测试是否是有效的解决方案，因为它不是在我们的环境中，在我们的条件下测试我们的代码，而是在我们的环境中，在其他条件下测试其他代码。我可以合理地向某人保证示例应用程序可以工作，但这与实际应用程序的工作方式无关。