错误“在 Visual Studio 中找不到元数据文件 '...\Release\project.dll'”答案

【问题标题】：Error "Metadata file '...\Release\project.dll' could not be found in Visual Studio"错误“在 Visual Studio 中找不到元数据文件 '...\Release\project.dll'”
【发布时间】：2010-10-28 06:24:19
【问题描述】：

最近我开始随机收到这条消息：

在 Visual Studio 中找不到元数据文件“...\Release\project.dll”

我有一个包含多个项目的解决方案。当前的构建模式是 Debug，所有项目的配置都设置为 Debug。但是当我尝试运行主项目时 - 有时它会给我一些错误，所有这些都是“找不到元数据文件'...\Release\projectX.dll'” - 而且，看，它说的是关于 RELEASE文件夹，虽然当前模式是调试。为什么？我尝试在所有解决方案文件中搜索对“Release\projectX.dll”的引用，并在 ResolveAssemblyReference.cache 文件中找到了一个。

我在互联网上进行了很好的搜索，发现有几个人有类似的问题，但没有解决方案，或者至少没有有效的解决方案。

我试图删除对这些项目的引用并阅读它们，但一段时间后我又开始收到这些错误。

这似乎是一个错误。为什么我总是使用 Debug 模式时，它会在 Release 文件夹中搜索引用的项目？

PS. 对于遇到此问题的人：我无法轻松解决。只有在我重新安装 Windows 后它才消失 :(

【问题讨论】：

对于此类问题，首先要删除 .suo 文件并重建。
如果引用的 dll 使用不同（较低）版本的 .net Framework，则会出现此问题
我一直遇到这个问题，直到我关闭并行构建。我认为并行构建依赖检查中存在一个错误，可能与缓存陈旧信息有关。（为了记录，我现在确实使用并行构建，如果问题发生，我会再次构建，这通常是有效的。）
stackoverflow.com/a/17723774/1724702
Metadata file '.dll' could not be found的可能重复

标签： visual-studio debugging release resolveassemblyreference

【解决方案1】：

对我来说，我使用的是 EntityFramework.6.2.0 更新到EntityFramework.6.4.0，问题就解决了。

【讨论】：

【解决方案2】：

检查您的项目路径。不能有逗号、空格等不规则字符

例如，这是不正确的路径： d:\我的应用程序\Project1

这是真正的道路 d:\my_applications\Project1

当磁盘中的路径中有非字母和数字字符时，Visual Studio 无法构建项目，并且没有显示此错误的消息！

还有一些安装工具在开始安装时出现同样的问题，无法解压。

【讨论】：

这个答案是错误的。我的路径中有空格，它编译得很好。

【解决方案3】：

在我的情况下，我正在处理 master 的一个分支。所以我检查了主分支，运行了一个构建，然后检查了我的分支。它解决了这个问题。如果您已经在 master 上，我建议您查看以前的提交，然后构建它。

【讨论】：

哇！我尝试了很多选择，但没有任何效果。但这解决了问题！谢谢队友:)

【解决方案4】：

我遇到了同样的问题，之前提供的答案都没有解决。显然这可能是 .csproj 文件的问题。出于某种原因，对我的代码中甚至没有在任何地方进行的文件的引用仍然“丢失”。

使用文本编辑器打开您的 .csproj 文件并查找丢失的文件、删除、保存并开心。

【讨论】：

【解决方案5】：

我自己也有同样的问题。

Visual Studio 2013 只告诉我它无法引用它，也找不到元数据。当我打开我的解决方案（其中有多个项目）时，它说我使用的项目低于我的一个项目的框架版本。

所以我把所有东西都切换到了 4.5 版，它又可以工作了。

【讨论】：

这与我遇到此问题时的解决方法相同。一些参考使用了比我的基础应用程序更高的框架，当我将基础应用程序中的框架更改为 4.5.2（与其他参考相同）时，问题就消失了。不过，VS 并没有说明不同的框架版本..

【解决方案6】：

我在尝试添加项目引用时遇到了这个问题，经过大量搜索和尝试上述许多事情后，我的构建配置和输出是正确的。

我终于从源和引用项目中删除了 \bin 和 \obj 文件夹。

老实说，我相信是 obj 文件夹不包含正确的元数据或损坏的元数据。

现在一切都解决了。

这是 Visual Studio 2015 - .NET 4.6 项目。

更新：

上述方法在第一次构建时有效，但在随后的构建中失败了，所以我最终重新创建了解决方案文件，并删除并读取了我的项目文件中错误引用的 NuGet 包，这些包指向了不正确的 提示路径。

到目前为止，这似乎已经在后续构建中修复了它。

.csproj 文件中的示例参考

<ItemGroup>
    <Reference Include="Antlr3.Runtime, Version=3.5.0.2, Culture=neutral, PublicKeyToken=eb42632606e9261f, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\packages\Antlr.3.5.0.2\lib\Antlr3.Runtime.dll</HintPath>
    </Reference>
</ItemGroup>

【讨论】：

【解决方案7】：

您是否检查了配置管理器设置？在项目设置对话框右上角。

有时会在所有发布条目之间出现一个调试条目。如果是这样，解决方案的依赖图创建的自动依赖就会变得混乱。

【讨论】：

我查过了。所有项目都具有相同的配置。

【解决方案8】：

我们经常遇到这个问题，但只是从 C# 项目中引用 C++/CLI 项目。这显然是 Microsoft 决定不修复的 Visual Studio 中的一个深层错误，因为它“太复杂”，并且他们承诺对现在针对 Visual Studio 2010 的 C++ 构建系统进行大修。

那是前一段时间的事了，也许这个修复程序甚至进入了 Visual Studio 2008；我没有再跟进了。但是，我们的典型解决方法是

交换机配置
重启 Visual Studio
构建解决方案

【讨论】：

这个问题永远消失还是暂时消失？ “交换机配置”是什么意思？例如，我总是使用 Debug 配置。我该怎么办？
暂时消失。实际上，如果您从不在调试和发布之间切换配置，它可能不是您的解决方案。或者切换到发布然后调试可能会修复它，谁知道;）
好吧，几天前我切换到发布，构建解决方案，然后切换回调试。在此之后，问题发生了变化:)：现在我只得到 1 个这样的错误，而不是几个 - 就像其他项目已被“修复”:)

【解决方案9】：

这个问题是由 pdb 文件或 CodeContracts 引起的。

解决它：

清理输出文件夹并重建解决方案。
重新配置 CodeContracts 或禁用它以进行临时构建。

【讨论】：

【解决方案10】：

对我来说是删除/删除整个 .vs 文件夹（这是一个不可见的文件夹），然后：

- Build
- Rebuild

完成了。

【讨论】：

【解决方案11】：

检查项目根目录中的 .vs 文件夹是否隐藏。我的不是（而且应该），因为我从另一台电脑复制/粘贴。删除它解决了问题，Visual Studio 2015 刚刚为我重新创建了它。

【讨论】：

【解决方案12】：

大多数答案都说您需要删除解决方案的库，这是真的，但是当您重新添加库时，错误将再次显示。 您需要验证所有引用的库是否具有与您解决方案的 .net 框架兼容的 .net 框架。然后修复代码中的所有错误并重新构建解决方案。

【讨论】：

【解决方案13】：

我遇到了这个问题，花了很长时间才弄清楚。当我从解决方案中删除项目并用 nuget 包替换这些项目时，问题出现了。

解决方案似乎没问题，但 .csproj 文件仍然多次包含这些项目作为参考。

似乎 VS 没有正确清理该文件。它仍在后台引用已删除的项目。当手动从 csproj 文件中删除引用时，一切都会再次起作用！呵呵

【讨论】：

【解决方案14】：

对我来说，通常是目标框架关闭（4.5.2 而不是 4.6）如果您修复项目的目标框架以匹配解决方案的目标框架并构建，则会创建一个新的 .dll。

【讨论】：

对于使用旧版 Visual Studio 创建的项目，我遇到了同样的问题。更新 VS 后，使用较新版本的 .NET 创建项目并导致 DLL-not-found 问题。（转到项目的属性窗格以查看/编辑 .NET 版本。）谢谢！
谢谢万次（这是我尝试过的其他解决方案的数量）。这行得通。由于某种原因，我添加的库针对的 .NET 框架版本与所有其他项目不同
我添加了一个新的类库项目 (dll)，它在其他几个项目中被引用。新的 dll 是 .NET Framework 4.8，而所有其他项目都是 4.7.2。将目标框架（在项目属性中）更改为 4.7.2 为我解决了这个问题。谢谢亚当！

【解决方案15】：

在 VS 2015 中，删除“参考”下的“分析器”解决了该问题

【讨论】：

【解决方案16】：

第 30 个答案 :-)

在 VS2015 中：

右键单击解决方案
选择项目构建顺序
查看项目构建顺序中的项目列表
按该顺序构建您的每个项目
检查输出

在我的例子中，一步一步地做有助于发现我的问题是什么，而没有左右抛出所有错误。

如果您必须知道，当项目设置为 .NET 4.5.2 时，我通过 NuGet 添加了实体框架 (EF) 6.1.3。后来我把.NET Framework降级到了4，然后错误就更明显了。通过 NuGet，我卸载了 EF 并重新添加了它。

【讨论】：

【解决方案17】：

以管理员身份重新打开 Visual Studio。

【讨论】：

【解决方案18】：

我遇到了类似的问题。我删除了类和一个接口，之后我的构建开始失败。

删除所有构建，以便没有项目构建（配置管理器）
检查构建顺序（截图并放入 Paint :D）
一一启用，每次清理并重建和构建。
现在您知道失败的项目了。 :-)

在我的情况下，我有一个文件夹，里面有一个界面。例如FooSolution.StupidProject.Interfaces 发生的事情是我将接口 IUnicorns (FooSolution.StupidProject.Interfaces.IUnicorns) 注释掉了，这样就不会再使用它了。没有其他项目在使用 IUnicorn。一切都很好。

但是... 其他一些项目仍在对该文件夹使用 using 语句：

using FooSolution.StupidProject.Interfaces

解决方案：

而不是像这样评论界面，

//公共接口IUnicorn {

我还注释了接口上方的命名空间，如下所示：

// namespace FooSolution.StupidProject.Interfaces
//{
//   public interface IUnicorn {

我搜索了我的其他项目，并确保不再使用该命名空间！
清洁和重建以及一杯好咖啡 ;-)

结论： 检查您在其他项目中的使用情况。

【讨论】：

【解决方案19】：

嗯，我的回答不仅仅是对所有解决方案的总结，而且提供的还不止这些。

第 (1) 节：

一般解决方案：

我有 4 个此类错误（“找不到元数据文件”）以及 1 个错误说“无法打开源文件（'未指定错误'）”。

我试图摆脱“找不到元数据文件”错误。为此，我阅读了很多帖子、博客等，发现这些解决方案可能是有效的（在这里总结一下）：

重启 VS 并再次尝试构建。
转到“解决方案资源管理器”。右键单击解决方案。转到属性。转到“配置管理器”。检查 'Build' 下的复选框是否被选中。如果其中任何一个或全部未选中，则检查它们并再次尝试构建。
如果上述解决方案不起作用，则按照上面步骤 2 中提到的顺序，即使所有复选框都被选中，也不要选中它们，再次选中并尝试重新构建。
构建顺序和项目依赖关系：

转到“解决方案资源管理器”。右键单击解决方案。转到'项目依赖项...'。您将看到 2 个选项卡：'Dependencies' 和 'Build Order'。此构建顺序是构建解决方案的顺序。检查项目依赖关系和构建顺序，以验证是否某个依赖于其他项目（如“project2”）的项目（如“project1”）正在尝试在该项目（project2）之前构建。这可能是错误的原因。
检查丢失的 .dll 的路径：

检查丢失的 .dll 的路径。如果路径包含空格或任何其他无效路径字符，请将其删除并重新构建。

如果是这个原因，则调整构建顺序。

第 (2) 节：

我的特殊情况：

我用各种排列和组合尝试了上述所有步骤，并重新启动了几次 VS。但是，它对我没有帮助。

所以，我决定摆脱我遇到的其他错误（'源文件无法打开（'未指定的错误'）'）。

我偶然发现了一个博客： http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

我尝试了该博客中提到的步骤，我摆脱了错误'无法打开源文件（'未指定错误'）'，令人惊讶的是我摆脱了其他错误 （“找不到元数据文件”）。

第 (3) 节：

故事的寓意：

尝试上面第 (1) 节中提到的所有解决方案（以及任何其他解决方案）以消除错误。如果没有任何结果，根据上面第 (2) 节中提到的博客，从您的 .csproj 文件中删除所有不再存在于源代码控制和文件系统中的源文件的条目 em>。

【讨论】：

赞成这个答案，因为我们遇到了一个同事的这个问题。他的系统不知何故丢失了大部分/所有依赖项，因此在构建时，它不会以正确的顺序构建，导致““whatever.dll”的元数据文件不存在”。我们只是用另一个系统浏览了他的所有项目，以验证他每个项目所需的所有依赖项。
好...很高兴我的回答对您有所帮助。

【解决方案20】：

就我而言，在合并期间，解决方案文件似乎缺少一些项目引用。手动将项目重新添加到解决方案中修复了它。您也可以手动编辑解决方案文件，但您需要小心并知道自己在做什么。

【讨论】：

【解决方案21】：

您是否在项目中使用了 SQLMETAL 之类的数据库代码生成工具？

如果是这样，您可能会面临从多元化到非多元化的过渡问题。

在我的例子中，我注意到一些旧的复数 (*) 表名（SQLMETAL 默认在其末尾添加一个“s”字母）表引用由生成的类SQLMETAL。

因为，我最近禁用了名称的多元化，在重新调整了一些与数据库相关的类之后，其中一些失去了它们的“s”前缀。因此，对受影响表类的所有引用都变得无效。出于这个原因，我有几个编译错误，如下所示：

“xxxx”不包含“TableNames”的定义，并且找不到接受“yyyy”类型的第一个参数的扩展方法“TableNames”（您是否缺少 using 指令或程序集引用？）

如您所知，我只接受错误以防止程序集编译。那就是缺少的程序集可链接到依赖程序集，导致原始“找不到元数据文件'XYZ'”

在将受影响的类表引用手动修复为其当前名称（未复数）后，我终于能够让我的项目恢复活力！

(*) 如果选项 Visual Studio > 工具菜单 > 选项 > 数据库工具 > O/R设计器 > 名称的多元化开启，一些SQLMETALl代码生成器会在一些生成的表类的末尾添加一个“s”字母，虽然表没有“s”后缀在目标数据库上。更多信息请参考http://msdn.microsoft.com/en-us/library/bb386987(v=vs.110).aspx

这篇文章有很多很好的建议。又加了一个。

【讨论】：

【解决方案22】：

我今天也遇到了这个问题。我的问题是由循环依赖引起的。项目 A 引用了项目 B，反之亦然。

【讨论】：

【解决方案23】：

对我来说，这是由于构建目标已被重写以不输出 dll 造成的。删除它以回退到默认的构建目标解决了这个问题。

【讨论】：

【解决方案24】：

就我而言，我的代码中有一些错误。 Visual Studio 显示的是您遇到的错误，而不是实际的错误，例如语法错误或未知的类名。尝试在项目后清理解决方案并构建项目。这样你就会发现实际的错误。

同样，这正是 me 出错的原因。

【讨论】：

【解决方案25】：

此问题已解决。我打开包管理器设置并单击“允许 NuGet 下载丢失的包”。该项目现在构建。

https://github.com/gitextensions/gitextensions/issues/1969

【讨论】：

【解决方案26】：

我遇到了同样的问题，这个问题背后的原因是参考项目的 dll 文件正在被其他进程使用。就我而言，我正在调试一个应用程序，并且应用程序与 Visual Studio 调试器相连。当我重新构建另一个使用相同项目的应用程序时，我收到了这个错误。解除附加后，我能够成功构建第二个应用程序。

【讨论】：

【解决方案27】：

我最终删除了我的引用（我已经使用项目选项卡正确添加了它们，并且它们过去构建得很好），手动编辑我的 .csproj 文件并删除不属于的奇怪条目 - 并设置我的输出对于调试和发布，x86 和 x64 以及任何 cpu 都必须是“\bin”——我构建了一次，然后重新添加了引用（再次使用项目选项卡），一切又开始为我工作了。根本不需要重新启动 Visual Studio。

【讨论】：

【解决方案28】：

对我来说，Visual Studio 创建了一个“Visual Studio 解决方案用户选项”类型的 projectname.v11。我删除了这个文件并重新启动，一切都很好。

【讨论】：

【解决方案29】：

我遇到了同样的问题。手动删除和添加 dll 没有帮助。 ClassLibraries 没有为所有项目编译，并且在项目的 ...\bin\Debug 文件夹中丢失[因为我错误地清理了解决方案]。 由于类库没有编译，这意味着这些子项目之一中的某处可能存在一些错误。

解决方案：由于我的 dll 用于 ...\bin\Release 文件夹，因此我尝试在 Release 模式下重建并在子项目之一。解决错误并重建解决方案摆脱了构建错误。

【讨论】：

【解决方案30】：

就我而言，这是由两件事引起的（VS.2012）：

1) 其中一个项目配置为 AnyCPU 而不是 x86

2) 被引用的项目不知何故未选中“构建”复选框。

请检查您的构建 |配置管理器以概览正在构建的内容以及针对哪个平台。还要确保检查调试和发布，因为它们可能有不同的设置。

【讨论】：