为什么 Visual Studio 2013 对 lc.exe 使用错误的 SdkToolsPath？

Question

我正在使用带有 asp.net 项目的 Visual Studio 2013。其中一个项目给出了以下错误。 为什么它在错误的路径中寻找 LC.exe？我的 Windows 8.1 SDK 已安装，并且我在

处有一个 lc.exe

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools

和一个 64 位版本，我在

有一个注册表项

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.1A

我正在查看C:\Windows\Microsoft.NET\Framework\v4.0.30319 下的 Microsoft.Common.targets，并且此密钥存在：SdkToolsPath="$(TargetFrameworkSDKToolsDirectory)"。然后查看了

下的Microsoft.NetFramework.CurrentVersion.props

C:\Program Files (x86)\MSBuild\12.0\Bin

而TargetFrameworkSDKToolsDirectory 定义在$SDK40ToolsPath。根据MSBuild /v:diag，

SDK40ToolsPath = C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools 

看起来不错。 .NET 4.0 中 VS 中的项目目标。

那么为什么它仍在查看错误的文件夹或注册表项？有趣的是，当我收到错误消息后重新构建项目时，项目构建正常。

Error   5   
Task could not find "LC.exe" using the SdkToolsPath 
    "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\" 
or the registry key 
    "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86".
Make sure the SdkToolsPath is set and the tool exists in the correct processor 
specific location under the SdkToolsPath and that the Microsoft Windows SDK is 
installed   
    C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets  2428    5   SuperReports

Answer 1

我采用了与上面 Hans Passant 建议的方法略有不同的方法。 我的场景是我的构建是通过 Jenkins（一个 CI 工具）在 Windows 2008 服务器中使用 MSBuild 2015 执行的。

根据文档，Microsoft SDK 10 不支持 Windows 2008。我尝试同时使用SdkToolsPath 和FrameworkOverride msbuild 命令行参数但没有成功（没有一起尝试，刚刚在打字时意识到）。

无论如何，可行的方法是，是的 - 我无法强制 msbuild 使用较新的 SDK 版本而不是 Windows 7 中的版本 （它坚持从C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools 获取LC.exe） - 所以我的黑客是用SDK 10 中的一个覆盖LC.exe（我已经安装在我的本地机器上，而不是在运行Windows 2008 的构建服务器中）。

我的构建终于成功了。

Answer 2

原来你可以直接在.csproj文件中指定SDK的路径：

<TargetFrameworkSDKToolsDirectory>C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools</TargetFrameworkSDKToolsDirectory>

并且构建以这种方式找到了 lc.exe。

我之前希望使用<SdkToolsPath> 进行设置，但那没有用。在 Microsoft.Common.targets 中，SdkToolsPath 是从 TargetFrameworkSDKToolsDirectory 设置的，所以我尝试了它并且它有效。这是在 Visual Studio 2015 上，从 ant 调用 msbuild。

通过MSBuild Using Incorrect Version of sgen.exe to Generate XmlSerializer dlls?找到解决方案

Answer 3

在导入之前，您的项目中是否定义了 PlatformToolset 属性？我认为它使用它，也许使用 Project XML 元素上的 ToolsVersion 属性在多个已安装的 SDK 之间进行选择。我认为，从类似的路径有趣的业务来看，IDE 设置 paths 以根据它在项目中特定位置查找的 PlatformToolset 查找内容（从 MSBuild 命令行构建时它可以工作不管它是如何设置的）。

这是来自 vcxproj 文件的示例：

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" 
    ToolsVersion="4.0" 
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <!-- NB: see ToolsVersion in above -->

⋮

<PropertyGroup Label="Globals">
  <ProjectGuid>{⋯⋯⋯}</ProjectGuid>
  <RootNamespace>blahblahblah</RootNamespace>
  <ConfigurationType>StaticLibrary</ConfigurationType>
  <PlatformToolset>Windows7.1SDK</PlatformToolset>
  <!-- NB: PlatformToolset must be repeated in each top-level project file -->
  <Keyword>Win32Proj</Keyword>
</PropertyGroup>

我认为如果将它放在一个公共属性页中会产生有趣的结果，我认为有两个原因：首先，它需要在导入标准内置逻辑之前设置（例如Microsoft.Cpp.Default.props），其次是 IDE 不知何故设置路径本身或对生成的解决方案文件执行某些操作，并在主文件中查找该属性。当我通过按 F7 构建时遇到错误的路径（使用了错误版本的 EXE），当它从命令行调用 MSBuild 工作正常时，我了解到这一点。

在 IDE 中，在项目的属性编辑器中检查 Platform Toolset。确保它以粗体显示；也就是说，直接设置在那里而不是继承，即使它显示了正确的版本。