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" />.

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

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

以上几点我都同意，只是有一点不同。 在我的例子中:我使用的是Visual Studio 2019。我结束了VS-2019，以VS-2017开始。并重建项目一切工作都很好! 我的职位日期是2019年4月19日

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

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

我也被这个问题困扰着，但在尝试了之前的答案后，唯一对我有用的是逐个打开我的解决方案中的每个项目并单独构建它们。

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

这很奇怪，因为如果我在解决方案资源管理器中单击每个项目并试图以这种方式构建它们，它们都失败了。我必须单独打开它们各自的解。

在我的案例中，ReSharper是愚蠢的，即使我的项目目标是c# 6，我也被提供了重构来使用c# 7独有的特性。

出于这个原因，我最终修改了这段代码，

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get { return _joinedDate ?? DateTime.Now; }
    set { _joinedDate = value; }
}

进入这段代码:

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get => _joinedDate ?? DateTime.Now;
    set => _joinedDate = value;
}

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