好吧，之前的答案都不适合我，所以这让我思考为什么我要点击，作为开发者我们应该尝试着理解这里发生了什么。

在我看来，这个不正确的元数据文件引用必须保存在某个地方。

对.csproj文件的快速搜索显示了错误的代码行。我有一个名为<itemGroup>的部分，它似乎挂在了旧的不正确的文件路径上。

<ItemGroup>
    <ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
        <Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
        <Name>Beeyp.Entities</Name>
    </ProjectReference>
...

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

备份.csproj文件。 在.csproj文件中找到不正确的路径并适当地重命名。

请确保在修改之前备份了旧的.csproj。

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

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

如果你有项目A、B和C:

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

您可以单独构建每个项目，但无法重新构建以以下内容结尾的解决方案:找不到元数据文件“C.dll”。

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

当我试图发布一个web应用程序时，我遇到了这个错误。原来一个类属性被包装成

#if DEBUG
    public int SomeProperty { get; set; }
#endif

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

在我的情况下，我有一堆其他的构建错误(一些简单的类型转换)以及这个，我抓着我的头试图解决这个问题，我没有关注其他错误。

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

因此，如果您有其他构建错误以及丢失的DLL文件错误，并且没有其他方法为您工作，则尝试先修复其他错误，然后再次构建解决方案。

我有一个非常不寻常的错误案例，但也许有人会从中受益。

我在解决方案(目标框架netstandard 2.0)中丢失了一个项目的.dll文件，我正在处理这个错误，并且引用(到Microsoft.Office.Interop.Word)这个项目使用的错误。

这个解决方案是从git存储库克隆出来的，同样的解决方案对我团队中的其他人来说编译得很好。

我尝试了每一个提出的解决方案的问题-重新启动VS，计算机;清洁工程;检查和取消检查构建复选框;检查构建顺序是否正确等。

我发现这个项目的清单在默认情况下没有被选中(项目属性中的清单下拉菜单为空并且禁用)。因此，我试图添加它，但没有工作。

最后，我开始比较这个项目的.csproj文件与这个项目的另一个旧版本，编译没有问题。 经过一些无用的尝试后，我发现，通往Microsoft.Office.Interop.Word的路径在两个项目中是相同的，即使它是一个相对路径，开头有很多“go up”符号(..\)。没有工作的项目比其他项目低一个层次。

再增加一个“go up”符号(..\)在project .csproj文件中的Microsoft.Office.Interop.Word引用路径中解决了这个问题。

我不知道为什么这个路径是这样创建的，在我的情况下不更新，而它在我的团队中的其他人正常工作。