.NET 应用程序在特定于语言环境的子文件夹中查找 DLL

Question

我的公司有一些内部实用程序库，其中包含基础服务、有用的扩展方法等。

我最近从头开始完全重写了这些，并将它们打包为 nu-get 包，托管在我们的内部网络上。

当我在项目中添加对包的 NuGet 引用时，应用程序将构建，但有时在调试或运行时会失败，提示找不到库。这似乎完全是随机的，通常如果我重新构建和重新部署，问题将暂时得到解决。

我的一位同事通过运行进程监视器设法缩小问题范围，发现应用程序正在寻找 bin/en-GB/{MyCompany.DllName}/{MyCompany.DllName}.dll 中的文件当文件实际上在 bin/{MyCompany.DllName}.dll 中时，正如我所期望的那样。

所以作为一个临时修复，我们可以添加它需要的文件夹结构并能够运行应用程序，但是必须重新添加文件夹结构并在每次清理/重建后手动复制和粘贴 dll 并不长长期解决方案。我也不知道：

1. 为什么它有时会起作用。
2. 是什么导致了这种行为。

我不知道问题出在实用程序库项目、nuget 包还是消费项目。

我意识到这可能对 .NET 功能的设计有所帮助，允许特定语言环境的 ddls 版本，但在这种情况下我不需要它们，并且 dll 可以/是文化不变的。

我们将不胜感激任何帮助，因为它阻碍了我们新库的发布。

Answer 1

.NET 中没有任何机制可以让它在类似的“en-GB”子目录中查找包含代码的程序集。它仅用于附属程序集，它们不包含代码，仅包含资源，并且是 ResourceManager 类进行探测。

这种行为的唯一可能候选者是应用程序中不正确的 AppDomain.AssemblyResolve 事件处理程序。如果由于某种原因无法找到您的程序集，则将运行的事件。在代码库中搜索“AssemblyResolve”，它通常悬停在 Main() 方法附近。

远距离射击是[AssemblyCulture]属性。对于包含代码的程序集，它必须是“中性的”。我认为这可能会影响 Fusion 在无法在正常位置找到程序集时探测的位置。这应该是修复的，但核心问题仍然是它找不到你的程序集。

请注意 [AssemblyVersion]，如果您使用 NuGet 部署库，那么您通常还需要一个带有 <bindingRedirect> 的 app.exe.config，因此库的更新不会破坏应用程序。永远不要使用，比如“1.0.*”，这总是会导致痛苦。

并使用Fuslogvw.exe 来诊断这样的负载故障。如果这些提示不能解决您的问题，请向我们展示您获得的跟踪信息。