MSBuild 错误地设置了 TargetFrameworkDirectories

Question

当我尝试构建 C# 控制台应用程序(可能还有其他应用程序)时，似乎 TargetFrameworkDirectories设置不正确；特别是它省略了 Facades 目录。

由于我一直在尝试诊断问题，这里列出了可能相关的事实。

当尝试在 Visual Studio 2012 中构建一个引用 Reactive Extension 库(使用 NuGet 管理)的项目时，问题就出现了。错误(或警告)是 warning MSB3267: The primary reference "System.Runtime", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.5" . msbuild执行ResolveAssemblyReference时出现问题

我可以用 msbuild 从命令行重现错误，这看起来更简单

其他工作站不会出现此问题。在一台好的机器上运行 msbuild 时，日志文件中出现了一些差异

在好机器上TargetFrameworkDirectories ( ResolveAssemblyReference 的参数)是 C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\但是在一台坏机器上，它缺少第二个条目(Facades 目录)

扫描好的和坏的 msbuild 日志文件会发现以下差异:

目标 AssignProjectConfiguration在坏构建中被跳过，但在好的构建中运行

许多目标，如 GetInstalledSDKLocations在好的构建中被跳过，但在坏构建中没有被提及

ResolveAssemblyReference任务通过Assemblies与 Implicit=true在好的构建中，但不是在坏的构建中。

ResolveAssemblyReference任务被传递任务参数 TargetFrameworkDirectories与 C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\在坏的构建中，但好的构建 Facades 目录(见上文)作为第二个项目。

由于这是由 C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets 驱动的我在好的和坏的机器上区分了那个文件。它们包含许多差异。第一个区别是 project 元素(第 17 行)，它有一个额外的属性 TreatAsLocalProperty="OutDir"在好机器上。在好的机器上，targets 文件包含更多的注释，例如 <!-- VS10 without SP1 and without VS11 will not have VisualStudioVersion set, so do that here --> .跳转到 AssignProjectConfiguration目标，好机有 Condition="'$(CurrentSolutionConfigurationContents)' != '' or '@(ProjectReference)'!=''"而坏机有 Condition="'@(ProjectReference)'!=''" (我认为这解释了为什么它被跳过)。

我尝试的最后一件事是修复“Microsoft .NET Framework 4.5”和“Microsoft .NET Framework 4.5 Multi-Targeting Pack”。它没有帮助。

任何建议将不胜感激，特别是如果我可以避免重新安装 Visual Studio 2012!

更新:似乎重新安装 .NET 4.5 然后“仅仅”修复 VS2012 解决了我的问题。我对导致此问题的原因的最佳猜测是我的 Microsoft.Common.targets 以某种方式被更改为旧版本。我不知道是什么改变了目标文件。

Answer 1

正如@leppie 所建议的那样，这是一个 .NET 问题。出于某种原因，修复 .NET 似乎没有解决问题。然而，重新安装 .NET 4.5(随后修复 VS2012)似乎确实解决了它。