首页 文章

无法加载文件或程序集或其依赖项之一

提问于
浏览 次
196

我有另一个“无法加载文件或程序集或其中一个依赖项”的问题 .

附加信息：无法加载文件或程序集'Microsoft.Practices.Unity，Version = 1.2.0.0，Culture = neutral，PublicKeyToken = 31bf3856ad364e35'或其依赖项之一 . 定位的程序集的清单定义与程序集引用不匹配 . （HRESULT异常：0x80131040）

我不知道是什么导致这个或我如何调试它来找到原因 .

我已经在我的解决方案目录.csproj文件中进行了搜索，以及我拥有Unity的所有地方：

参考Include =“Microsoft.Practices.Unity，Version = 2.0.414.0，Culture = neutral，PublicKeyToken = 31bf3856ad364e35，processorArchitecture = MSIL”

在我的任何项目中找不到任何与1.2.0.0相对应的参考 .

任何想法我应该如何解决这个问题？

我也很欣赏如何调试这样的问题的技巧 .

c# .net reference compiler-errors

30 回答

  • 5

    • 检查您是否引用了一个程序集，而该程序集又引用了旧版本的unity . 例如，假设您有一个名为 ServiceLocator.dll 的程序集，它需要旧版本的Unity程序集，现在当您引用 ServiceLocator 时，您应该使用旧版本的Unity提供它，这就产生了问题 .

    • 可能是所有项目构建其程序集的输出文件夹，具有旧版本的统一 .

    您可以使用FusLogVw找出谁正在加载旧程序集，只需定义日志路径，然后运行解决方案，然后检查（在FusLogvw中）加载Unity程序集的第一行，双击它并查看调用集会，你走了 .

    回复于
  • 2

    Open IIS Manager

    选择应用程序池

    然后选择您正在使用的池

    转到高级设置（右侧）

    将启用32位应用程序false的标志更改为true .

    回复于
  • 10

    对我来说，没有其他解决方案有效（包括清洁/重建策略） . 我找到了另一种解决方案，即 close and re-open Visual Studio .

    我想这迫使Visual Studio重新加载解决方案和所有项目，重新检查过程中的依赖项 .

    回复于
  • 13

    尝试清理解决方案中的Debug和Release文件夹 . 然后删除并再次添加单位 .

    回复于
  • 15

    以下为我工作 .

    • 删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files

    • 关闭VSTS并再次打开

    • 删除并添加相同的DLL（注意：添加相同的匹配版本）

    回复于
  • 4

    Microsoft Enterprise Library（由.NetTiers引用）是我们的问题，而后者又引用了旧版本的Unity . 为了解决这个问题，我们在web.config中使用了以下绑定重定向：

    <configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

    或者，您可能只想将企业库更新到最新版本 .

    回复于
  • 1

    99％的无法加载文件或程序集或其依赖项之一问题是由依赖项引起的！我建议你按照以下步骤操作：

    • 从http://www.dependencywalker.com/下载Dependency Walker

    • 启动Dependency Walker并打开dll（在我的情况下 NativeInterfaces.dll ）

    • 您可以看到一个或多个带有错误的dll错误打开文件...

    • 这意味着系统中缺少此dll;在我的情况下，DLL的名称是 MSVCR71.DLL

    • 您可以从谷歌下载misings dll并在正确的路径中复制（在我的情况下 c:\windows\system32 ）

    • 此时，您必须在GAC（全局程序集缓存）中注册新的dll：打开DOS终端并写入：

    cd \Windows\System32
regsvr32 /i msvcr71.dll
    • 重新启动您的应用程序！
    回复于
  • 2

    尽管最初的问题是在5年前发布的，但问题仍然存在并且相当令人讨厌 .

    一般的解决方案是彻底分析所有引用的程序集，以了解出现了什么问题 . 为了使这个任务更容易，我创建了一个工具（一个Visual Studio扩展），它允许选择.Net程序集（.ddl或.exe文件），并获得所有引用的程序集的图形，其中包含突出显示的冲突或错过的引用 .

    该工具在Visual Studio库中可用：https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

    输出示例：
    enter image description here

    回复于
  • 2

    检查项目中的Web.config / App.config文件 . 查看版本号是否正确 .

    <bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />

    这对我有用 .

    回复于
  • 5

    我有类似的问题 . ** Juntos答案是正确的**但你应该注意一个重要提示！

    为了统一 2.1.505.2 指定了不同的 AssemblyVersion 和 AssemblyFileVersion ：

    enter image description here

    AssemblyFileVersion 由nuget使用但是CLR不关心它！ CLR将只使用 AssemblyVersion ！

    因此，重定向应该应用于 AssemblyVersion: 2.1.505.0 中指定的版本

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>

    另见：What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?

    回复于
  • 2

    screenshot
    在解决方案资源管理器中右键单击项目（不是解决方案），在构建选项卡中选择平台目标："Any CPU" .

    回复于
  • 2

    • 转到： Solution - > Package

    • 点击 Advanced 标签（在页面下方查找）

    • 将 dll 添加到其他程序集（这样我们就可以在sharepoint中添加外部dll） .

    回复于
  • 10

    我也遇到了这个可怕的错误并为此找到了解决方案......

    右键单击解决方案名称单击清洁解决方案重新启动Visual Studio转到项目属性>>构建更改配置以释放开始调试（F5）

    1) , 2)

    Right Click on the Solution name

    4) , 5)

    Change Configuration to Release

    希望这也会对你有所帮助 .

    回复于
  • 64

    不确定这是否有帮助 .

    检查程序集中的Properies中的程序集名称和默认名称空间是否匹配 . 这解决了我的问题，产生了同样的错误 .

    回复于
  • 3

    谢谢Riddhi M.以下为我工作 .

    删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files关闭VSTS并再次打开删除并添加相同的DLL（注意：添加相同的匹配版本）

    回复于
  • 1

    在我的情况下，bin文件夹是一个名为Unity.MVC3的非引用dll，我试图在visual studio中搜索任何引用但没有成功，所以我的解决方案就像从bin文件夹中删除dll一样简单 .

    回复于
  • 2

    你说你的解决方案中有很多项目......好吧，从构建顺序顶部附近开始 . 获得那个构建，一旦你搞清楚，你可以对其余的应用相同的修复 .

    老实说，你可能只需要刷新你的参考 . 听起来您要么更新了版本并且没有更新引用，要么将解决方案保留在源代码管理中，这是一个相对路径问题 . 只需验证您的假设，然后重新添加参考 .

    回复于
  • 2

    这个问题发生在我身上，当我的一个依赖库正在编译带有“任何CPU”的DLL时，父库期望编译“x64” .

    回复于
  • 4

    您必须从输出文件夹中删除您的appname.dll文件 . 清理调试和释放文件夹 . 重建并复制到输出文件夹重新生成的dll文件 .

    回复于
  • 2

    我 "Set as Startup Project" 卸载/未发布的库/项目 .

    然后部署它 .

    有效！

    我认为它找不到.dll，因为它最初不在程序集中 .

    回复于
  • 13

    另一个可能的原因：确保您没有意外地在项目属性中为两个项目提供相同的程序集名称 .

    回复于
  • 9

    以下为我工作 .

    • 删除临时文件C：\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files

    • 然后右键单击Temporary Asp.net文件>属性>安全性，并提供对IIS以及运行我的项目的所有用户的完全控制访问权限

    回复于
  • 10

    我使用Enterprise Library 5的.NET 4.0解决方案是添加对以下内容的引用：

    Microsoft.Practices.Unity.Interception.dll

    回复于
  • 96

    留意有争议的引用 . 即使在清理和重建之后，冲突的引用仍然会导致问题 . 我的问题出在AForge和Accord之间 . 我删除了两个引用，并重新添加了引用，重新选择了特定的引用（特别是我的情况，只是Accord） .

    回复于
  • 4

    对我来说，重建没有Unity C的统一游戏#Proects Checkmark工作 .

    回复于
  • 3

    就我而言，提议的答案都没有奏效 .

    这对我有用：

    • 删除参考

    • 重命名DLL

    • 再次导入参考

    第二步显然很重要，因为没有它就没有用 .

    回复于
  • 2

    尝试检查引用的“复制到本地”属性是否设置为true，并且特定版本是否设置为true . 这与Visual Studio中的应用程序相关 .

    回复于
  • 2

    我今天有这个，在我的情况下，这个问题很奇怪：

    <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
  </dependentAssembly>0.

    注意XML末尾的杂散字符 - 不知何故，这些字符已经从版本号移到了这个XML块的末尾！

    <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
  </dependentAssembly>

    改为上面而且瞧！一切都恢复了 .

    回复于
  • 47

    如果您通过在Windows XP上打开应用程序来获取此错误消息，则意味着首先您已安装该应用程序，因为它在没有net framework 4和Service Pack 3的情况下无法运行 . 你安装了这两个，你又得到了这个错误，所以你应该重新安装该应用程序，但首先从添加和删除卸载

    如果这不起作用请不要虐待我 . 我也是一名大三学生

    回复于
  • 40

    好吧，这听起来可能非常愚蠢，但继续尝试其他所有解决方案并在这个愚蠢的事情上过夜后，我是如何解决这个问题的 .

    我从Bin文件夹中丢失了一些DLL时遇到了同样的错误 . 我试图删除，从Team Foundation Server备份所有内容但没有工作 . 从我的office-matelocal机器上获得了Bin文件夹的副本，并将其替换 . 它也没用 . 最后，我手动FTP服务器，获得了显示为丢失的DLL副本，然后它开始显示文件列表序列中的下一个文件丢失 .

    所以我ftped服务器得到了所有Bin文件夹，手动逐个替换每个文件 . （不是全部操作并替换..我试过：它不起作用 . ）不知怎的，它有效...

    回复于

相关问题