我正在处理一个WPF、C 3.0项目，我得到这个错误：

以下是我引用用户控件的方式：

每次构建失败后都会发生这种情况。我能得到要编译的解决方案的唯一方法是注释掉所有的用户控件并重新构建项目，然后取消对用户控件的注释，一切都很好。

我已经检查了构建顺序和依赖项配置。

如您所见，它似乎截断了dll文件的绝对路径…我已经读到有一个长度与错误。这可能是个问题吗？

它非常烦人，不得不评论、构建和取消注释，构建变得非常烦人。

我也有同样的问题。Visual Studio没有生成正在引用的项目。

在较新版本的Visual Studio中仍然可能发生这种情况(我刚刚在Visual Studio 2013上进行过这种情况)：

另一个尝试是关闭Visual Studio并删除.sln文件旁边的.suo文件。(它将在下次EDOCX1(或退出Visual Studio)时重新生成)。

在另一台计算机上向解决方案添加新项目，然后在中提取修订时，我遇到了这个问题，但在其他情况下，.suo文件也可能损坏，并导致非常奇怪的Visual Studio行为，因此删除它是我一直在尝试的事情之一。

请注意，删除.suo文件将重置解决方案的启动项目。

更多关于.suo文件的信息在这里。

建议的答案对我不起作用。这个错误是为了解决另一个问题。

我发现我的目标是.NET稍有不同的版本，编译器将此标记为警告，但这会导致生成失败。这应该标记为错误而不是警告。

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

第1节：

一般解决方案：

我有四个此类错误("找不到元数据文件")，还有一个错误说"无法打开源文件("未指定的错误")。

我试图消除"找不到元数据文件"错误。为此，我阅读了许多文章、博客等，发现这些解决方案可能是有效的(总结如下)：

第2节：

我的具体案例：

我尝试了上面的所有步骤，尝试了各种排列和组合，并重新启动了几次Visual Studio。但是，这对我没有帮助。

因此，我决定消除我遇到的其他错误("源文件无法打开"("未指定的错误"))。

我看到一篇博客文章：tfs错误-无法打开源文件("未指定的错误")。

我尝试了那个博客文章中提到的步骤，并且消除了"源文件无法打开(未指定的错误)"的错误，并且意外地消除了其他错误("找不到元数据文件")。

第3节：

故事的寓意：

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

在我的案例，它是由错配造成的。NET框架版本。

什么一个项目和其他项目4.6.1 3.5引用。

关闭并重新打开Visual Studio 2013为我工作！

好吧，之前的答案对我没有任何帮助，所以它让我思考为什么我要点击并希望作为开发人员，我们应该真正理解这里发生了什么。

我觉得很明显，这个不正确的元数据文件引用必须保存在某个地方。

对.csproj文件的快速搜索显示了犯罪行。我有一个名为的部分，它似乎挂在旧的错误文件路径上。

所以一个简单的解决方法是：

请确保您在小提琴前备份旧的.csproj。

我也遇到了这个问题。首先，您必须手动构建您的DLL项目，通过右键单击，构建。然后它就可以工作了。

我得到相同的错误"metadata file".dll"could not found"(找不到)，我尝试了上面描述的一些操作，但错误的原因是我引用的第三方dll文件的目标.NET版本高于我的项目目标.NET版本。所以解决方案是改变我的项目的目标框架。

在我的例子中，我的安装目录是错误的。

如果您的解决方案路径类似于"我的项目%2c非常流行的%2c单元测试%2c软硬件.zip"，那么它无法解析元数据文件，也许我们应该阻止一些无效的字，如%2c。

将路径重命名为普通名称解决了我的问题。

我在我的解决方案中添加了一个新项目，并开始获得它。

原因何在？我引入的项目是针对不同的.NET框架(4.6和我的另外两个是4.5.2)。

对我来说，它试图在以前包含项目的路径中找到一个dll，但我们将它移到了一个新目录。解决方案有正确的项目路径，但是Visual Studio不知怎么地一直在寻找旧的位置。

解决方案：重命名每个问题项目-只需添加一个字符或其他-然后将其重命名回其原始名称。

这必须在Visual Studio中重置某种类型的全局缓存，因为这样既可以清除此问题，也可以清除一些类似的问题，而像clean这样的问题则不会。

对我来说，当我将一个新项目包括到一个解决方案中时，就发生了这种情况。

Visual Studio自动选择.NET Framework 4.5。

我和其他库一样，改成了.NET 4.5.2版本，它起作用了。

我也在为这个问题发愁，但是在尝试了前面的答案之后，唯一对我有用的就是在我的解决方案1中逐个打开每个项目并分别构建它们。

然后我关闭了Visual Studio 2013，重新打开了我的解决方案，它编译得很好。

这很奇怪，因为如果我在解决方案资源管理器中单击每个项目并尝试以这种方式构建它们，那么它们都失败了。我不得不独自打开它们，用它们自己的方法解决问题。

对我来说，以下步骤奏效了：

• 查找未生成的项目
• 删除/添加对解决方案中项目的引用。

我的问题实例是由一个公共项目引起的，该项目中有一个重复的类名(在另一个文件名下)。奇怪的是，Visual Studio无法检测到这一点，而只是破坏了构建过程。

我在Visual Studio 2012的一个有很多项目的解决方案中遇到了这个问题。以与项目生成顺序相同的顺序手动重新生成解决方案中的每个项目(右键单击并在解决方案资源管理器中重新生成)为我修复了它。

最终我得到了一个编译错误。我修正了这个错误，然后解决方案就会建立正确。

在我的例子中，问题是我手动删除了一个标记为"丢失"的非编译文件。有一次，我删除了对现在丢失的文件的引用并重新编译，一切都很好。

几年后回到这个问题，这个问题很可能与Windows最大路径限制有关：

命名文件、路径和命名空间，最大路径长度限制

在我的例子中，问题是由一个简单的构建错误引起的，

error CS0067: The event 'XYZ' is never used

因为任何原因，这都不会出现在错误窗口中。

因此，Visual Studio生成系统似乎忽略了错误，并尝试生成依赖项目，而这些项目又因恼人的元数据消息而失败。

这个建议听起来很愚蠢：

首先看看你的输出窗口！

我花了半个小时才想到这个主意…

我也面临同样的问题。在我的例子中，我引用了一个类库项目，该项目的.NET版本高于我的项目，而VS未能构建该项目，并引发了与您发布的相同的错误。

我只需将类库项目(破坏了构建的项目)的.NET版本设置为与引用项目的.NET版本相同，并解决了问题。

我也有同样的错误。作为信息隐藏在下面的路径。在其中一个路径的DLL文件被称为是"D:组件样assembly1.dll文件夹"。

但其中的原始路径是组装或"D:组件% assembly1.dll 20folder "。

由于这个变化的路径名称，不能检索大会从其原始路径和从这个"元数据不存在"的错误。

解决方案中的堆栈溢出问题是我如何替换所有空间与# 20 % C？。。。。。。。

看起来这类错误与Visual Studio没有提供有关错误的正确信息有关。开发人员甚至不理解构建失败的原因。它可能是语法错误或其他错误。通常，要解决这些问题，您应该找到问题的根源(例如，查看构建日志)。

在我的例子中，问题是事实上，Error List窗口没有显示任何错误。但实际上有语法错误；我在Output窗口中发现了这些错误，在修复它们之后，问题就解决了。

根据错误消息，我认为文件路径没有被截断。看起来是不正确的。如果我正确地阅读了该消息，它似乎正在查找以下位置的dll文件…

WORK=-\Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug\BusinessLogicLayer.dll

这不是有效的路径。是否可能在生成过程中将宏定义设置为无效值？

在我的例子中，我在一个特定的(空的)命名空间中对类进行了注释：

当我删除了名称空间代码和它的导入(使用)命令时，它修复了这个问题。

在构建过程中，它还说-以及缺少的项目dll文件：

error CS0234: The type or namespace name 'W' does not exist in the namespace 'X.Y.Z' (are you missing an assembly reference?)

我正在运行Visual Studio 2013。

似乎生成依赖项不正确。删除*.suo文件确实解决了我遇到的问题。

只需指出显而易见的一点：如果您没有启用"在构建开始时显示输出窗口"，请确保您注意到构建是否失败(左下角的"构建失败"小错误)！！！！！

如果解决方案名称中有空格，这也会导致问题。从解决方案名称中删除空间，因此路径不包含%20将解决此问题。

如果使用假程序集，则可能会显示此错误。移除假货会成功构建项目。

尝试发布Web应用程序时出现此错误。结果发现一个类属性被包装到

但财产的使用却不是。显然，发布是在没有DEBUG符号的发布配置中完成的。

在我的例子中，这些错误是由nuget包管理器中的一些损坏引起的。未生成解决方案的子项目，但由于元数据错误，未显示任何错误。

一旦所有的nuget包都被纠正，这个项目就可以重新正确地构建。

我遇到这个问题是因为我的存储库中没有包含.nuget
uGet.exe。虽然我在nuget.targets中启用了DownloadNuGetExe，但它在尝试下载时报告了一个代理错误。这导致了项目构建的其余部分失败。

我也有同样的问题。在我的例子中，这个项目仍然在发布模式下构建，当我尝试在调试中构建时，它失败了。

我最终解决这个问题的方法是简单地将所有的DLL(以及我的发布文件夹中的其他文件)复制到我的调试文件夹中。在为每个项目做了这些之后，错误就消失了。

我在4.6.1中有一个类引用了4.6.2中的接口…将类升级到462修复了它。

在我的案例，我有这个错误，因为一个项目，我使用不同的.NET Framework版本和其他的解决方案。一包管理器安装使用nuget log，所以，我想，它安装的.NET版本的这个项目。

我想所有的解决方案在本岗位工作，但没有人。i删除解决方案和一个log，所有相同的东西，cs006：一个编译时错误。

它是当我删除所有文件在本项目中，obj\Debug编译解决方案。

在我的例子中，解决方案中的一些项目是针对任何CPU的，其中一些是针对x86的。在解决方案中统一平台目标后，编译错误消失。

解的packages文件夹在文件夹nuget含解决方案为我工作。重建后的一切工作了。检查References在解决方案和检查的参考，有一个黄色的三角形。

美国电影：例子

当我对一个非常旧的库进行反编译时，也遇到了类似的问题，这个库部署在一个生产环境中，但是源代码丢失了。

我取了.dll，反编译并生成了项目和解决方案。由于这种错误，我无法构建解决方案。

以前答案中的提示没有帮助，但过了一会儿，我注意到一些项目中缺少对System.dll等几个程序集的引用。

假设项目A依赖于项目B。项目B中没有对System.dll的引用，但生成后的错误类似于"找不到元数据文件"b.dll。

项目B中缺少System.dll没有错误。

在项目B中添加对system.dll等库的引用解决了这个问题。(System.Data、System.DirectoryServices等)

我在打开引用实体框架的项目后收到此错误，因此我删除了这些引用，并通过pthe acket manager重新安装了实体框架版本6.0.0.0：

错误仍然在显示，所以我认为这些引用是存在的，因为在项目上有一个旧版本的实体框架，据推测是"预装的"，但它并没有真正起作用。

所以我查阅了文件packages.config，发现还有另一个参考：

然后我删除了这条线，清理并重建了这个项目和容器解决方案，最终成功了。

aaaaaa和六年后在升级到Visual Studio 2015的过程中，也出现了同样的问题。因为这个特定的解决方案不在这个列表中，所以我要添加到其中。

C:WindowsSystem32中有两个引用的dll…文件夹。将它们移动到非系统文件夹，并添加对新文件夹的引用，最终解决了问题。其余的问题确实是其他人已经说过的。

问题的原因可能是混合添加了对解决方案中的dll文件和项目的引用。

如果您有项目A、B和C：

• A引用B和C作为解决方案中的项目。
• b引用c作为dll文件(引用文件)

可以单独生成每个项目，但不能重新生成以以下结尾的解决方案：找不到元数据文件"c.dll"。

在解决方案中将引用从文件更改为项目会有所帮助。

正如user@burzhuy指出的那样，查看Output窗口可能很重要，而不仅仅是Error List窗口。

在我的例子中，我正在修改Roslyn编译器。它的构建项目运行一个额外的检查，以查看公共字段是否与定义为编译器公共接口的字段一致，否则会产生rs0016或rs0017错误。我添加了几个公共字段，并通过将鼠标悬停在错误上并选择"添加到公共API"来修复rs0016错误。

后来我改变主意，把公共场所搬到了另一个班级。由于某种原因，这产生了"找不到元数据文件的错误"，我越是处理它，得到的错误就越多。

您需要找到正确的PublicAPI.Unshipped.txt文件(在我的例子中，它在E:
oslyn\32414\src\Compilers\Core\Portable中)，然后手动编辑它以删除不再相关的行。

在我个人的案例中，我没有添加对解决方案中某个项目的引用，这正是导致我出错的原因。

在我的例子中，这是因为Resharper是一个哑巴，即使我的项目目标是C 6，我也被提供重构来使用C 7-唯一的功能。

因为这个原因，我最终更改了这个代码，

进入这个代码：

由于某些原因，使用表达式体的getter和setter会使编译器产生元数据错误，而不是语法错误。

我的问题出现在我编写C 7代码时，但该项目使用的是.NET框架的旧版本

此问题可能是由于代码中的语法错误导致的，因为元数据错误，代码中的语法错误可能对您不可见。因此，在执行前面答案中的任何操作之前，请检查源文件。

我发现，如果在项目中删除Microsoft.CSharp程序集作为引用，则会出现此错误。

我面临这个问题。在我的例子中，多个C项目被引用为DLL文件。在用作dll文件的项目(在其他项目中)中，任何编译时错误都会导致大量错误。原因是，编译时错误会阻止创建相应的dll文件，这会导致项目中出现一系列引用缺少的dll文件的错误。

因此，当您在解决方案资源管理器中重新生成时(忽略微不足道的编译时错误)，会出现一堆"metadata file.dll could not be found"(找不到元数据文件.dll)错误(使您认为除了简单的重新生成外，您还做了什么错误)。

如果您正面临这个问题，那么最好的解决方案是清理解决方案，然后逐个构建每个项目，以确定哪个项目正在启动错误。

这是一个错误在Visual Studio  ； ；2015年，当我删除的类型注释从调用扩展方法，它只在左括号后面的空角。

这不是一个obj.extensionMethod<>()obj.extensionMethod()。

我想作为一个主分类表本虫在Visual Studio，因为我不了解那是个错误，产生错误。

我同意以上的一切只是一个区别。在我的例子中：我使用的是Visual Studio 2019。我于2019年关闭，于2017年开启。重建项目，一切都很好！我的职位日期是：2019年4月19日

对我来说，问题是我打开了两个Visual Studio窗口，我的项目在一个窗口中的debug中运行，我试图在另一个窗口中构建它。

我不得不停止调试，然后它让我成功地构建。

在我的例子中，我得到这个错误消息的原因很简单，就是从tfs获取项目的最新版本后，解决方案中的错误项目被标记为启动项目。选择正确的项目作为启动项目为我解决了这个问题。

哇，似乎这样的误差是可以来的。

无论如何，我添加了一个新webapi MVC控制器应用到我和它有一nuget automagically所有引用。删除后的第一参考点从nuget UI，但我忘了删除的文件在使用他们(IU System.Http)。

一些原因，我是什么错误，这一简单的警告，以及一个变量是一个需要使用。

该变量"I Get RID至少指定的预警和重建我一切非文件这是使用现有的资料。这些文件的代码后，我们走吧。

在我的例子中，我在注意到我引用了一个.NET Framework 4.7项目作为对.NET Framework 4.6.1项目的依赖之后解决了这个问题。在将项目4.7迁移到4.6.1之后，我的应用程序正常编译

Visual Studio IDE不在后台进行任何构建，而msbuild应用程序则在后台进行。vs-ide基本上只是构造msbuild使用的项目文件，如果将其留给ide自己解决问题，它通常会出错。如果您得到的是Metadata file '.dll' could not be found错误，很可能是因为没有找到正确/预期的程序集。因此，也许Visual Studio正在为4.5框架应用程序创建一个项目文件，当您引用4.0程序集时，需要4,5个程序集。因此，请查看您的Visual Studio设置中的不兼容性，或者自己进入项目文件，并通过指定正确的路径手动修复它。

我有同样的问题和另一个解决方案。

问题：一个解决方案，多个项目。使用某些其他结果的主应用程序失败，说：

csc:错误cs0006:找不到元数据文件"c:
epos heapplication heapplicationcommonindebug heapplication.dll"

但实际上这个项目产生了C:
epos\TheApplication\TheApplicationCommon\bin\Debug\TheApplicationCommon.dll。另一个项目也使用了同样的DLL，编译得很完美。

在我更新内部nuget包之前，该包使用了postsharp 3.x.x.x，现在使用了postsharp 4.x.x.x。我的解决方案是将此包添加到我的*.csproj文件中：

另一个解决方案->清理，另一个解决方案->重建，它在本地和构建服务器上工作。

希望它能帮助别人。这个线程很旧而且很长，但是这个问题经常返回，我还没有看到这个解决方案。btw使用Visual Studio 2017(15.8.x)。

当我进行构建时，它通常会在Visual Studio 2017中显示如下错误：

但有时这样的错误会显示几秒钟，然后它会消失并切换回上面的消息：

所以我花了很多时间对第一个错误进行故障排除，但真正的问题是由于第二个错误。首先，我必须删除所有的/bin和/obj目录，然后我还删除了如上所示的.suo文件。这允许我将问题缩小到一个接口问题。

在我的界面中，我有：

但在我的实际实现中，我使用了以下代码：

在我将接口更新到以下位置后，生成成功完成：

因此，当实际问题是CS1503错误时，似乎是VS中的缓存导致它不断显示CS0006错误。

对我来说，问题是一个在构建输出中没有出现的错误，也就是说，我最初有两个实用程序类，它们位于不同的名称空间中。我更改了第二个实用程序的名称空间以匹配第一个实用程序的名称空间(在不知道第一个实用程序类中还有另一个实用程序类的情况下)，这时出现了这个错误。

我设想出现了构建输出错误，因为无法构建逻辑层库DLL文件，而主应用程序找不到它。

解决方案是将第二个实用程序类改回另一个名称空间，这时真正的构建错误开始涌入。在把它们分类之后，构建过程就很顺利了。

作为一个概述，如果前面的任何解决方案对您不起作用，您可能已经抑制了Visual Studio未显示的代码中的错误，因此请尝试重新检查编码步骤并检查是否有任何异常。

PS：这是Visual Studio 2015社区版

在我的例子中，我还有很多其他的构建错误(一些简单的类型转换)，还有这个错误，我在努力解决这个问题，但是我没有关注其他的错误。

最终解决我的问题的是，我修复了所有其他的构建错误，然后我再次构建，并且成功地构建了它。

因此，如果您有其他生成错误以及丢失的dll文件错误，而其他任何东西都不起作用，请尝试先修复其他错误，然后重新生成解决方案。

在我的例子中，设置目标框架解决了这个问题：

我看到这个错误是因为我的代码中有以下行(看起来我仍然在考虑SQL模式)：

Visual Studio(2017)在设计或编译时未报告任何错误，但该项目不会生成，并给出"missing.dll"错误。将错误行更改为：

问题解决了。

在大量更改解决方案、搁置更改并撤消更改之后，我开始遇到此问题。

解决这个问题的唯一方法是删除并再次添加从tfs到本地文件夹的映射。

以前的解决方案都不适合我，所以我会和大家分享。

在合并了另一个分支中相互引用的一些新类库之后，我遇到了这个问题。删除项目中的引用并重新创建它们最终解决了问题。显然，Visual Studio合并了错误的文件路径。

面对这一问题后getting latest(Team Foundation Server(TFS)命令)。

在我找到解决冲突后，使用一个namespace that does not exist in the project声明。

所以我using语句删除，然后clean and rebuild，一切是好的。

在我的情况下，在我的Web.config文件中修改这个

对此

解决了我的问题

在我的例子中，当我在本地引用nuget包并将它们的目录移动到其他地方时，我更改了NuGet.Config中的路径，但不幸的是，我发现应该手动更改.csproject文件以更新引用路径，但是错误消息CS0006远没有描述这个问题。相对长度单位。通常情况下，当有一个对dll的引用找不到时，也会发生这种情况，为了能够识别问题，在项目中搜索您的引用，您会发现一些与它们相关联的带有警告图标的引用，请尝试修复这些引用，它应该按预期工作。

检查.csproj主项目文件。Visual Studio不清理干净在你删除的项目或年龄的参考案例的解决方案。

我有一个旧的项目文件中引用的三.csproj时报编译错误和那些被发现在一个项目。

很奇怪！我想所有的答案和不幸的没有以前的工作在我的案例。

我遇到两个错误：

我有一个错误的第一和第二清除去除函数是已复制在另一个地方。

这是我的第一个错误。DLL文件有它自己的解决失踪。

我想说，如果你有超过一单错误。DLL文件的缺失以及一个错误，请尝试先解决其他的错误。也许是它自己的solves。DLL错误！

到目前为止，几十个答案中没有一个对我有用。在我的例子中，我还得到了错误：

Tuple element name 'Value' is inferred. Please use language version 7.1 or greater to access an element by its inferred name

这出现在"元数据文件".dll"在生成时找不到"错误旁边，但很快就消失了，因为错误有时会像IDE"赶上"一样。

双击错误以找到它，并删除有问题的代码，修复它。

否则，您可以在Visual Studio中尝试：

菜单项目→properties→build→button advanced→language version→c(例如"c 5.0")。

这也解决了问题。

看起来"metadata file".dll"could not be found"通常是一些其他潜在问题的症状，因此，如果没有一个顶级解决方案对您有效，请检查其他错误和警告，并尝试找到真正的问题。