Visual Studio 2019这对我来说很有效:

关闭Visual Studio 删除隐藏的。vs文件夹 重新打开Visual Studio并重新构建解决方案。

我的项目也面临着同样的问题，我在一个解决方案中添加了控制台应用程序，但那些其他解决方案不起作用，并显示未找到.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引用路径中解决了这个问题。

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

对我来说，这仍然是VS2022当前版本的一个“功能”。

构建一个解决方案的全部~80个项目 取消中间的构建 卸载~70个项目，并做一个重建所有

导致错误。解决办法:

重新加载所有项目 从头到尾重建 然后卸载

并且在没有元数据错误的情况下，重新构建全部成功

The Visual Studio IDE doesn't do any building behind the scenes, the Msbuild application does. The VS IDE essentially just constructs the project file that is used by Msbuild and quite often it makes mistakes if you leave it up to the IDE to figure things out on it's own. If you are getting the Metadata file '.dll' could not be found error it is likely due to the fact that the correct/expected assemblies are not being found. So perhaps Visual Studio might be creating a project file for a 4.5 framework app, and expecting 4,5 assemblies, while you are referencing 4.0 assemblies. So look at your Visual Studio settings for incompatibilities or go into the project file yourself, and manually fix it by specifying the correct path <Reference Include="C:\\correct path to assembly\\yourAssembly.dll" />.

对我来说，这是错误的文件夹名称。如果从将空格替换为'%20'的源代码关闭，则会得到此类错误。 解决方案-重命名命名不当的文件夹。