编辑继续后，可视化工作室获取错误“元数据文件‘ XYZ’无法找到”

最终解决这个问题的办法是:

1. 单独清理每个项目(右击 > 干净)。
2. 分别重建每个项目(右击 > 重建)。
3. 重新生成启动项目。

我想出于某种原因，只是清理解决方案有一个不同的效果比具体清理每个项目单独。

编辑:
根据@maplemal 注释，似乎有时也需要删除和重新添加每个引用。

2019年更新:
这个问题在过去得到了很多的流量，但似乎自从 VS 2017发布以来，它得到了很少的关注。
因此，另一个建议是——更新到 VS 的更新版本(> = 2017) ，在其他新特性中，这个问题也将得到解决

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

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

在我的例子中，我注意到一些旧的复数(*)表名称(默认情况下，SQLMETAL 在其上添加一个“ <是的trong>是的”字母)引用 SQLMETAL 生成的类。

因此，我最近禁用了 名称的多元化，在重新生成一些与数据库相关的类之后，有些类丢失了它们的“ <是的trong>是的”前缀。因此，对受影响表类的所有引用都无效。由于这个原因，我遇到了以下几个编译错误:

‘ xxxx’不包含‘ TableNames’的定义，也找不到接受类型为‘ yyyy’的第一个参数的扩展方法‘ TableNames’(是否缺少 using 指令或汇编引用?)

正如您所知，我只在出现错误时才阻止程序集编译。那就是缺少的程序集可链接到依赖程序集，导致原始“元数据文件‘ XYZ’无法找到”

在手动修复受影响的类表引用到它们当前的名称(不复数)之后，我终于能够让我的项目恢复生机！

(*)如果选项 Visual Studio > 工具菜单 > 选择 > 数据库工具 > O/R 设计师 > 名称的多元化被启用，一些 SQLMETALl 代码生成器将在一些生成的表类的末尾添加一个“ <是的trong>是的”字母，尽管表在目标数据库上没有“ s”后缀。有关详情，请参阅 http://msdn.microsoft.com/en-us/library/bb386987(v=vs.110).aspx

希望能有帮助！

一个可能的原因是您已经将您的一些项目(在解决方案中)升级到了更高的版本，例如从。NET 4.0到4.5当我在 VS 2013中打开解决方案(最初使用 VS 2010和。NET 4.0).当我在 VS2013中打开时，我的 C + + 项目被更新为。NET 4.5和我开始看到的问题。

我有这个问题好几天了！我尝试了以上所有的方法，但问题还是不断出现。当显示该消息时，它可能具有“解决方案中的一个或多个项目没有完全编译”的含义，因此文件的元数据从未被编写。但在我的情况下，我没有看到任何其他编译器错误! ! ！我一直试图手动编译每个解决方案，直到 VS2012真正显示了一些我以前从未见过的编译器错误之后，这个问题才消失。

我混淆了构建命令，没有构建命令，引用调试 dll (这是手动编译的) ... 似乎没有什么工作，直到我发现这些错误没有显示在编译整个解决方案！

有时，在编译时，编译器似乎会因为某些错误而退出... ... 我在过去看到过这种情况，在修复问题之后，随后的编译会显示新的错误。我不知道为什么会发生这样的事情，而且我很少有这样的问题。然而，当你像这样拥有它们的时候，想要弄清楚到底发生了什么是一件非常痛苦的事情。祝你好运！

一般来说，这种错误是由人为的错误造成的，比如，如果我们以某种不正确的方式更改名称空间，或者在当前项目中更改资源管理器中的文件夹名称等等，编译器有时无法检测到这些错误。

我遇到了同样的错误，为了解决这个问题，我尝试了几个步骤:

1. 清洁整体解决方案
2. 右键单击解决方案中的每个项目，转到“属性”，使默认命名空间和默认程序集名称与代码中的相同(即类名前的命名空间)
3. 通过浏览资源管理器(项目解决方案所在的位置)检查每个项目的文件夹名称。如果与您的项目名称不匹配，请使其与它们相似(如 第二步)。
4. 从每个项目中删除与另一个相同解决方案相关的所有引用，然后再次添加它。
5. 在“项目解决方案”文件夹中，您将找到 Visualc # 项目文件。右击并用记事本打开。在你的初始行中，你会发现 每个项目的行如下:

项目(“{ FAE04EC0-301F-11D3-BF4B-00C04F79EFBC }”) = “ * * 客户端 * *”，“ * * 客户端 * * * 客户端 * * . csproj”，“{4503E259-0E3B-414A-9074-F251684322A5}” EndProject

再次检查文件夹名称(我已经在 BOLD 中突出显示) ，并使其类似于您在 第二步中所做的。

6. 再次清洗整个溶液

7. 构建解决方案(如果不起作用，请在清理后再次构建个人)

对于一个新的构建，可能有一些依赖项没有安装。

这是由于文件夹名和命名空间名的名称不同造成的。如果您使用某个名称创建一个名称空间，然后重命名它，那么该名称空间将具有旧名称本身。编译将采用旧的路径来查找 .dll和 .exe文件。为了避免这种情况，使用文本文件打开每个命名空间的 .csproj文件，并在文件中找到旧路径。

移除这个，清洁和重建解决方案。这对我来说很有效。我花了一整天的时间来解决这个问题。

我犯了一个错误。我跟踪了所有的解决方案，但没有一个奏效。我用的是 VisualStudio2013专业版。我无法让个人项目重建工作，我最终发现有一个 循环依赖在我的参考。如果要添加引用回来的内容的引用，VisualStudio 通常会很好地提醒您，但是由于某种原因，在此实例中它没有这样做。我添加了一个项目的引用，该项目引用了我正在进行的项目——它接受了我的引用。也许是 VS 漏洞？

当一个项目 dll 失败并且被多个项目引用时，就会发生这种情况。所以首先修复它，然后建立个人。

找不到 XYZ，因为还没有建成... ..。

右键单击解决方案并检查“项目依赖项”，“项目生成顺序”也应根据已设置的依赖项进行更改。

我的五分钱。

这个问题开始后的解决方案广泛清洁。

我设法通过将 Active Solution 配置设置为: Build-> Configuration manager 来释放，从而解决了这个问题。然后构建并将其重新设置为调试。在那之后建造成功了。

我遇到过这个问题，并且是在将我们的解决方案作为一个新项目导入 TFS 之后开始的。我偶然发现了这个主题，并且从您的答案中得到了一些灵感，找到了一个快速的解决方案。

我要做的就是重建那个丢失了元数据文件的项目瞧，问题解决了。

还有另外一个愚蠢的理由，你应该耐心地检查... ... 因为它发生在我浪费了4个小时寻找答案之后:

对我来说，我不小心在成千上万的 c # 类文件中更改了一小行代码，然后试图重新构建解决方案。正如你可以想象的那样，我最终丢失了40多个元数据文件错误，其中有一个编译错误——我没有仔细检查，纯粹是认为所有的错误都是一样的！

经过4个小时的搜索，然后偶然双重检查我的错误列表，我发现愚蠢的代码错误，修复它，编译，然后错误消失。

这不是解决你问题的好办法但希望我的案子和你的不一样。

我也有同样的问题。在我的案例中，我错误地把所有的项目与项目区分开来，把主要的方法作为控制台应用。

为了解决这个问题，我选择了 除了具有主要功能的项目之外的每一个项目和 右击 > 属性 > 输出类型 > 类库

确保所有依赖项目都使用相同的。Net Framework 版本。我也有同样的问题，因为一个依赖项目使用4.5.1，而其他所有项目都使用4.5。将项目从4.5.1改为4.5并重建我的解决方案为我解决了这个问题。

据我所知，这种情况发生在项目依赖关系由于某种原因而变得混乱的时候(同时所有的项目间引用仍然完好无损)。在许多情况下，这不是一个代码问题。对于那些拥有多个项目的人来说，一次只看一个项目是不可接受的。

重置项目依赖关系很容易-

1. 选择所有项目并右键单击卸载
2. 选择所有项目并右键单击重新加载
3. 重建解决方案

对于那些在他们的代码中有问题或者其他导致这个问题的问题的人来说，显然你必须首先解决这个问题。

我的答案不仅仅是所有解决方案的总结，而且它提供了更多的东西。

第(1)款:

一般解决方案:

我有4个这类错误(“元数据文件找不到”) ，还有一个错误说“源文件无法打开”(“未指定错误”)。

我试图摆脱’元数据文件无法找到’错误。为此，我阅读了许多文章、博客等，发现这些解决方案可能是有效的(总结在这里) :

重新启动 VS 并再次尝试构建。

转到“解决方案资源管理器”。右键单击“解决方案”。去物业中心。转到“配置管理器”。检查“ Build”下的复选框是否被选中。如果它们中的任何一个或所有的都没有被检查，那么检查它们，然后再次尝试构建。

如果上述解决方案不起作用，那么按照上面步骤2中提到的顺序进行，即使选中了所有复选框，也取消选中它们，再次选中并尝试再次构建。

生成顺序和项目依赖项:

转到“解决方案资源管理器”。右键单击“解决方案”。转到“依赖项目...”。您将看到2个标签: “依赖”和“建立顺序”。此生成顺序是生成解决方案的顺序。检查项目依赖关系和构建顺序，以验证某个依赖于其他项目(比如‘ project1’)的项目(比如‘ project2’)是否试图在那个项目(project2)之前构建。这可能是错误的原因。

检查缺少的路径:

检查失踪人员的路径。DLL.如果路径包含空格或任何其他无效的路径字符，请删除它，然后再次尝试构建。

如果这是原因，那么调整构建顺序。

关闭 VS，定位并从视觉工作室外移除“包”文件夹。重新启动 VS 和 build-> 重新安装所有依赖项

它发生在我身上是因为我在名称空间中有一个奇怪的冲突: 是的 集合 命名空间 项目名称空间 女巫定义了 A 级 以及同一程序集中另一个具有名称的命名空间 AssemblyA.ParentNamespace. ChildNamespace 女巫定义了一个不同的 ClassA (但名称相同)

然后我在 AssemblyA.ParentNamespace IInterfaceB 中找到了一个方法，它在一开始返回 IEnumable，而 ClassB 实现了 IInterfaceB

后来我修改了 ClassB 中的方法以返回 IEnumable，但是我忘了更新 IInterfaceB 定义，所以那里的方法仍然返回 IEnumable 有趣的事实是，如果我重新构建了所有内容，解决方案仍然可以编译，但是测试引用 AssemblyA 不起作用，并返回“ Metadata file could not be found”错误。

更新 InterfaceB 以正确返回 IEnumable，因为它的实现者 ClassB 确实解决了这个问题，不幸的是错误消息是模糊的，而且编译工作的事实使我认为编译器中可能有需要修复的地方

我有这个，并设法修复它使用这样的答案: 找不到元数据文件

我不得不取消选中所有复选框，单击 Apply，重新启用所有复选框，然后再次单击 Apply，但它解决了这个问题。

我只是碰到了这个问题，并在一个小时的鬼混后意识到，我已经添加了一个 阿斯伯格综合症文件到我的产品，具有相同的名称作为我的一个 Linq-To-Sql类。
类和“队列”所在的页。
将页面更改为 QueueMgr.aspx，一切都构建得很好。

唯一对我有用的是 删除解决方案用户选项(.suo)文件。注意，这是一个隐藏文件。

若要找到此文件，请关闭 VisualStudio 并在项目中的文件资源管理器中搜索. suo。

附注: 一个新的。Suo 文件将在您重新构建项目时再次创建，希望这个新创建的文件不会给您带来问题。

我希望这能帮助某人摆脱这个令人厌烦的错误:)。

一个同事遇到了这个问题，而原因却逃避了我们。最终，我们意识到项目目录(因此 NuGet 包的路径)包含 %20(谢谢，一些 Git gui 工具，不应该被命名) ，错误信息显示编译器正在寻找一个非常相似的路径，但它必须到 %20，而不是一个空格。显然，构建系统中的某个程序在本地文件系统路径上执行 HTML 解码。

重命名工作拷贝目录，一切开始工作。

Visual Studio 2019 Community 16.3.10
我在发布版本时也遇到过类似的问题，调试版本编译时没有任何问题。 原来问题是由 OneDrive 引起的。最有可能的情况是，在任何备份驱动器或云服务中都会遇到类似的问题。

根据阿维 · 特纳的回答，我把所有东西都清理干净了。

此外，我手动删除 obj 发布文件夹从我的 OneDrive 文件夹，也登录到 OneDrive 的浏览器和删除文件夹也在那里，以防止 OneDrive 加载云版本回来编译。
在那之后，一切都恢复正常了。

我也有这个问题。

在我整理项目中的一个小文件夹之后就开始了。 然后我尝试编译，得到了许多重复的类错误。(尽管它们没有被复制。我认为这种联系是不正常的)

在检查这些错误之后，所有错误都会消失，只留下“ Metadata file... debug application.exe could not be found”错误。

我通过在构建输出窗口中查找哪些类被复制来解决这个问题。

然后右键单击类名并“转到定义”。

有两个定义可供选择，同时打开它们，第二个定义似乎又打开了同一个文件，但是第二个定义将标识为错误源(红色下划线)。

从文件中删除所有代码并保存(这不会影响实际的文件)。
现在应该可以正确编译了。

确保项目路径中没有空格..。

我正在使用 Windows 10和 Visual Studio Community 2019，我正在克隆一个多项目解决方案，因为它来自一个 GIT 回购。这个错误与解决方案中的所有其他依赖项一起出现，还有一个 E _ Pointer错误。它的路径继承自 GIT，有类似 C:/repos/我的项目名称/..。

我删除了它，重新克隆了它，并确保它的路径不包含像 C:/repos/我的 _ 项目 _ 名称/这样的空格..。

解决了我的问题。

我也有同样的问题。

在我的例子中，我最近在项目中的某个地方添加了一个内部类。解决方案中的一个依赖项具有相同的类名，并且这两个依赖项都被正确地添加到引用中。

我改变了我最后的活动和重建，它的工作。

确保编译器消息有效。在我的情况下，我从那里捕获引用错误，没有列为错误列表中的错误。