我的公司有一些内部实用程序库，包含基本服务，有用的扩展方法等。
我最近完全重写了这些内容，并将它们打包为nu-get软件包，托管在我们的内部网络上。
当我添加了一个NuGet引用添加到项目中的包时，应用程序将构建，但有时在调试或运行它时将无法说找不到库。这似乎完全是随机的，通常如果我重新构建和重新部署问题将暂时解决。
我的一位同事设法通过运行进程监视器来缩小问题范围，并发现应用程序正在查找bin / en-GB / {MyCompany.DllName} / {MyCompany.DllName} .dll中的文件。当文件实际上在bin / {MyCompany.DllName} .dll中时，正如我默认的那样。
作为临时修复，我们可以添加它所需的文件夹结构并能够运行应用程序，但是必须重新添加文件夹结构并在每次清理/重建后手动复制和粘贴dll不长期限解决方案我也不知道：
我不知道问题是关于实用程序库项目，nuget包还是消费项目。
我意识到这可能是一些有用的设计.NET功能，允许特定于语言环境的ddls版本，但在这种情况下我不需要它们，并且dll可以是/是文化不变的。
任何帮助都会受到大力赞赏，因为它阻碍了我们新库的发布。
答案 0 :(得分：1)
.NET中没有任何机制可以查找包含＆＃34; en-GB＆＃34;中的代码的程序集。这样的子目录。它只用于附属程序集，它们不包含代码，只包含资源，而且它是执行探测的ResourceManager类。
这种行为的唯一可能的候选者是应用程序中不正确的AppDomain.AssemblyResolve事件处理程序。如果由于某种原因无法找到您的程序集，将会运行的事件。在代码库中搜索＆＃34; AssemblyResolve＆＃34;，它通常在Main（）方法附近徘徊。
远程拍摄是[AssemblyCulture]属性。它必须是中立的＆＃34;对于包含代码的程序集。我认为可能会影响Fusion探测的位置，因为它无法在正常位置找到装配体。这应该是固定的，但核心问题仍然是它无法找到你的装配。
请注意[AssemblyVersion]，如果您使用NuGet部署库，那么您通常还需要一个带有<bindingRedirect>的app.exe.config，因此您的库的更新不会破坏应用程序。永远不要使用＃34; 1.0。*＆＃34;，这总会造成痛苦。
并使用Fuslogvw.exe来诊断此类加载失败。如果这些提示无法解决您的问题，请告诉我们您获得的痕迹。