最近我开始随机收到这条消息：
在Visual Studio中找不到元数据文件'... \ Release \ project.dll'
我有一个包含几个项目的解决方案 . 当前的构建模式是Debug，所有项目的配置都设置为Debug . 但是当我尝试运行主项目时 - 有时它会给我一些错误，所有这些都是“元数据文件'... \ Release \ projectX.dll'找不到” - 而且，看，它说的是关于RELEASE文件夹，虽然当前模式是Debug . 为什么？我试图在所有解决方案文件中搜索“Release \ projectX.dll”的引用，我在ResolveAssemblyReference.cache文件中找到了一个 .
我通过互联网进行了很好的搜索，发现了一些有类似问题的人，但没有解决方案，或者至少没有可行的解决方案 .
我试图删除对这些项目的引用并阅读它们，但有一段时间我又开始重新获得这些错误 .
这似乎是个bug . 当我总是使用调试模式时，为什么要在Release文件夹中搜索引用的项目？
PS. 对于那些遇到这个问题的人：我无法轻易解决 . 它重新安装Windows后才消失:(
30 回答
您是否检查了配置管理器设置？在项目设置对话框的右上角 .
有时会发生所有发布条目之间的调试条目 . 如果是这样，解决方案的依赖关系图创建的自动依赖关系会变得混乱 .
今天有同样的问题 .
我的应用程序，一个Windows窗体应用程序，意外地引用了自己 . 奇怪的 .
删除后，错误就消失了 .
每次我将位于Windows窗体项目本身的用户控件拖到窗体时，都会添加引用 .
我同意大部分内容答案发布在这里 . 但是，如果所有建议的解决方案都不起作用，请考虑您的错误列表中可能存在其他类型的错误，即阻止VS构建其他项目所需的项目DLL . 然后，无论构建顺序或配置如何，在解决其他问题之前，您将无法摆脱“元数据”错误 .
每个人都是正确的...尝试一切......（按一点点浪费很多时间）
你有错误的代码吗？先解决这个问题 .
清理解决方案并重新启动Visual Studio
删除/添加引用
检查您的构建订单与更大的项目并验证
手动重建子项目
将项目之间的dll手动复制到关联的bin文件夹中
去喝杯咖啡，弹一些弹球明天回来......你可能会想到其他的东西 .
我有同样的问题 . 拥有50个项目的大型视觉工作室
所有参考文献都作为项目添加 . 项目构建顺序是正确的（右键单击项目并选择构建顺序） .
但是，在构建一些较高级别的项目时，他们所依赖的“根”项目并未构建 .
问题是这些项目没有选择在当前配置下构建（不知道这是怎么发生的） .
要选中此选项，请选择“Configuration Manager”（“构建”菜单），然后检查是否将有问题的项目设置为构建 .
当您说您删除了对这些项目的引用并重新添加它们时，您是如何重新添加它们的呢？您是否在Visual Studio的“添加引用”对话框中使用“浏览”选项卡？或者，您是否使用了“项目”选项卡（列出了解决方案中的相邻项目）？
Edit ：如果使用"Browse"选项卡，并手动将引用添加到位于/ Release文件夹中的.dll，则Visual Studio将始终在该位置查找.dll，无论您当前使用的是什么模式（调试或发布） .
如果您从Release文件夹中删除了实际的.dll文件（手动或通过“清理解决方案”），那么您的引用将会中断，因为.dll不存在 .
我建议删除对ProjectX.dll的引用，并再次添加它 - 但这一次，使用“添加引用”对话框中的“项目”选项卡 . 当您以这种方式添加引用时，Visual Studio知道从哪里获取相应的.dll . 如果您处于调试模式，它将从/ Debug文件夹中获取它 . 如果处于发布模式，则为/ Release文件夹 . 您的构建错误应该消失，并且在调试模式下您也将不再（不正确地）引用Release .dll .
好吧，我的答案不仅仅是所有解决方案的总结，而且还提供了更多 .
Section (1):
In general solutions:
我有4个这种错误（'无法找到元数据文件'）以及1错误说'源文件无法打开（'未指定错误'）' .
我试图摆脱'无法找到元数据文件'的错误 . 为此，我阅读了许多帖子，博客等，发现这些解决方案可能有效（在此汇总）：
重新启动VS并再次尝试构建 .
转到 'Solution Explorer' . 右键单击Solution . 转到 Properties . 转到 'Configuration Manager' . 检查 'Build' 下的复选框是否已选中 . 如果未选中任何一个或全部，请检查它们并再次尝试构建 .
如果上述解决方案不起作用，则按照上面步骤2中提到的顺序进行操作，即使选中了所有复选框，也要取消选中它们，再次检查并再次尝试构建 .
Build Order and Project Dependencies:
转到 'Solution Explorer' . 右键单击Solution . 转到 'Project Dependencies...' . 您将看到2个标签： 'Dependencies' 和 'Build Order' . 此构建顺序是构建解决方案的顺序 . 检查项目依赖项和构建顺序，以验证某个依赖于其他项目（例如'project2'）的项目（比如'project2'）是否正在尝试在该项目之前构建（project2） . 这可能是导致错误的原因 .
检查丢失的.dll的路径 . 如果路径包含空格或任何其他无效路径字符，请将其删除并再次尝试构建 .
如果这是原因，则调整构建顺序 .
Section (2):
My particular case:
我尝试了上面的所有步骤，其中包含各种排列和组合，重启VS几次 . 但是，它没有帮助我 .
所以，我决定摆脱我遇到的其他错误（'源文件无法打开（'未指定错误'）'） .
我遇到了一个博客：http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539
我尝试了那个博客中提到的步骤，我摆脱了错误 'Source File Could Not Be Opened (‘Unspecified error ‘)' ，令人惊讶的是我摆脱了其他错误 (‘metadata file could not be found’) .
Section (3):
Moral of the story:
尝试上面第（1）节（以及任何其他解决方案）中提到的所有解决方案以消除错误 . 如果没有任何结果，根据上文第（2）节中提到的博客， delete the entries of all source files which are no longer present in the source control and the file system from your .csproj file .
我之前遇到过这个问题，我发现解决它的唯一方法是运行Clean Solution然后重新启动Visual Studio .
以管理员身份重新打开Visual Studio .
对我而言，通常关闭目标框架（4.5.2而不是4.6）如果修复项目的目标框架以匹配解决方案和构建的目标框架，则将创建一个新的.dll .
大多数answare都说您需要删除解决方案的库，这是正确的，但是当您重新添加库时，错误将再次显示 . You need to verify if all the libraries referenced have a compatible .net framework with the .net framework of your solution. 然后修复代码中的所有错误并重建解决方案 .
我也在解决方案中看到了这个错误，我有多个项目（通常是netTiers项目，我已经更新了一个或多个子项目来定位4.0框架） . 删除可能会有问题 . 但是，通常可以通过首先修复子项目中的所有其他错误（例如，任何缺少的引用），单独重建这些子项目，然后在Visual Studio中删除/添加对这些子项目的任何引用来解决它 . 就个人而言，通过单独清理解决方案，我很难解决这个错误 .
我们最近在从Office 2007升级到Office 2010后遇到了这个问题 - 我们不得不手动将项目中的引用更改为我们在某些项目中使用的Office Interops的第14版 .
希望有所帮助 - 花了我们几天时间来弄明白 .
在我的情况下，它是由两件事引起的（VS.2012）：
1）其中一个项目是为AnyCPU而不是x86配置的
2）被引用的项目以某种方式取消选中“Build”复选框 .
检查你的Build | Configuration Manager可以概述正在构建的内容以及适用于哪个平台 . 另外，请确保检查Debug和Release，因为它们可能有不同的设置 .
就我而言，我的代码中有一些错误 . Visual Studio显示您遇到的错误而不是实际错误，如语法错误或未知类名 . 尝试清理解决方案并在项目后构建项目 . 这样您就会发现实际错误 .
再次，这正是造成我错误的原因 .
我遇到了这个问题并花了很长时间才弄明白 . 当我从解决方案中删除项目并用nuget包替换它们时出现了问题 .
解决方案似乎没问题，但.csproj文件仍然多次包含这些项目作为参考 .
似乎VS没有适当地清理该文件 . 它仍在引用被删除的项目 . 当手动删除csproj文件中的引用时，一切正常！ wohoo
此问题是由于pdb文件或CodeContracts .
要解决它：
清理输出文件夹并重建解决方案 .
重新配置CodeContracts或禁用它以进行临时构建 .
我们经常遇到这个问题，但只能参考C＃项目中的C / CLI项目 . 它的很明显，微软决定不修复Visual Studio中的一个错误，因为它“过于复杂”，并承诺对C版本系统进行大修，该系统现在是Visual Studio 2010的目标 .
那是一段时间以前，也许修复甚至进入Visual Studio 2008;我没有再跟进了 . 但是，我们的典型解决方法是
交换机配置
重新启动Visual Studio
构建解决方案
我自己也有同样的问题 .
Visual Studio 2013只告诉我它无法引用它，它无法找到元数据 . 当我打开我的解决方案（其中有多个项目）时，它说我使用的项目低于我的一个项目的框架版本 .
所以我把所有东西都改成了4.5版本，然后再次运行了 .
我似乎记得几个月前有类似的问题 . 我通过将引用的DLL复制到Release文件夹暂时解决了它，从而满足了Visual Studio的期望 . 后来，我在实际代码中发现了对Release DLL的引用 . 您应该尝试搜索\ release \ project.dll的整个项目 .
另外，我注意到Visual Studio单元测试项目有时会在指向目标DLL的每个测试方法上放置一个“DeploymentItem”属性，如果在Debug和Release之间切换，如果不再使用DLL，Visual Studio会感到困惑在预期的位置 . 根据我的经验，如果您没有将这些属性作为“单一部署”方案的一部分放在那里，则可以安全地删除这些属性 .
我有这个问题，这是由于违规库（dll）中的一个无效方法没有返回值，例如
当我把这一切都提出来编译:)
有时VS2010将我的配置从任何CPU切换到混合平台 . 发生这种情况时，我收到此错误消息 .
要解决它，我切换回任何CPU：
1.右键单击解决方案并选择属性 .
2.单击Configuration Properties，然后单击Configuration Manager ...按钮 .
3.在Active solution platform下，选择Any CPU
我发现这通常发生在我仍然有一个接口的方法声明，一个类实现，但我后来删除并忘记将其从接口中删除 . 我通常只需每隔30分钟保存整个解决方案，然后如果我找不到错误，只需恢复到早期版本 .
我最终删除了我的引用（我已经使用项目选项卡正确添加它们，并且它们用于构建就好了），手动编辑我的.csproj文件并删除不属于的奇怪条目 - 并设置我的输出以进行调试和发布，x86和x64以及任何cpu都是“\ bin” - 我构建了一次，然后重新添加了引用（再次使用项目选项卡），一切都开始为我工作了 . 根本不需要重新启动Visual Studio .
对我来说，这是由于Build目标被重写为不输出dll引起的 . 删除此选项以回退到默认的Build目标，修复了该问题 .
当您签出一个包含多个项目的解决方案时，似乎会发生这种情况，这些项目之间有引用，而您之前没有构建它 . 如果您直接引用dll，而不是引用该项目，您将收到此消息 . 应始终使用“添加引用”对话框中的“项目”选项卡在同一解决方案中添加对项目的引用 . 这样，VS就可以知道构建解决方案的正确顺序
Vidar所描述的今天也发生在我身上 .
我在Helper库中有一个Build错误（由其他项目引用），而不是告诉我Helper Library中有错误，编译器会出现MetaFile-not-found类型错误列表 . 纠正Helper Library中的Build错误后，MetaFile错误消失了 .
VS中是否有任何设置可以改善这一点？
我有同样的问题 . 我注意到我的db上下文（EF4）位于项目dll中由于某种原因无法识别 . 我删除了它并创建了另一个 . 这解决了我 .
检查你的项目路径 . 它应该没有像逗号和空格那样的不规则字符
例如，这是不正确的路径：d：\ my applications \ Project1
这是真正的路径d：\ my_applications \ Project1
当视觉工作室在磁盘中的路径中存在非字母和数字字符时，它无法构建项目，并且它没有显示此错误的消息！
此外，某些安装工具在开始安装时也存在同样的问题，无法解压缩 .
我有同样的问题 . 手动删除和添加dll没有帮助 . ClassLibraries没有为所有项目编译，并且在项目的 ...\bin\Debug 文件夹中缺失[因为我错误地清理了解决方案] . Since the class library did not compile that means there may be some errors somewhere in one of those sub projects .
Solution: 由于我的dll用于 ...\bin\Release 文件夹，我尝试在发布模式下重建，并在其中一个子项目的一行中发现错误 . 解决错误并重建解决方案可以消除构建错误 .