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

时间:2014-10-18 17:14:59

标签: visual-studio visual-studio-2013 msbuild

我正在使用带有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。根据{{​​1}},

MSBuild /v:diag

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

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

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

2 个答案:

答案 0 :(得分:4)

事实证明,您可以直接在.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?

找到解决方案

答案 1 :(得分:1)

在导入之前,您的项目中是否定义了PlatformToolset属性?我认为它使用了Project XML元素上的ToolsVersion属性,可以在多个已安装的SDK之间进行选择。我认为,从类似的路径有趣的业务,IDE设置路径来查找基于它在项目中的特定位置查找的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 。确保以粗体显示;也就是说,直接设置而不是继承,即使它有正确的版本显示。

Prop Page dialog from VS10