Question

一台新的开发机无法在VS2019上构建我们的.net-framework-3.5-project。到目前为止，这是我们调查的转储。

将这台计算机上的详细日志与运行中的计算机进行比较，我们会在日志的开头（仅在发生故障的计算机上）获得此行：

Property reassignment: $(TargetFrameworkSDKToolsDirectory)="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\" (previous value: "") at C:\Program Files (x86)\Microsoft Visual studio\2019\Professional\MSBuild\Current\Bin\ Microsoft.NETFramework.CurrentVersion.props (90,5)

由于多次（？）之后在日志中出现故障的机器显示

TargetFrameworkSDKToolsDirectory = C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\

一台正在工作的机器显示

TargetFrameworkSDKToolsDirectory = C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\

查看Microsoft.NetFramework.CurrentVersion.props，相关行显示-

<TargetingClr2Framework Condition="'$(TargetFrameworkVersion)' == 'v2.0' or '$(TargetFrameworkVersion)' == 'v3.0' or '$(TargetFrameworkVersion)' == 'v3.5'">true</TargetingClr2Framework>
<MSBuildManagedCompilerPath Condition="'$(TargetingClr2Framework)' == 'true'">$(MSBuildFrameworkToolsRoot)\v3.5</MSBuildManagedCompilerPath >
<TargetFrameworkSDKToolsDirectory Condition="'$(TargetingClr2Framework)' == 'true'">$(SDK35ToolsPath)</TargetFrameworkSDKToolsDirectory>

<!-- If the sdk path is not 3.5 or lower set it to the 40 sdk tools path. This will allow future target framework versions to use the 4.0 sdk tool set
         When a new windows SDK revs they will inplace update the location pointed to by this property. When a new sdk is release this target will have to be
         revised along with another toolsversion. -->
<TargetFrameworkSDKToolsDirectory Condition=" '$(TargetFrameworkSDKToolsDirectory)' == '' ">$(SDK40ToolsPath)</TargetFrameworkSDKToolsDirectory>

因此，由于某种原因，出现故障的机器似乎没有捕获到该项目的TargetFrameworkVersion值为v3.5。

不确定工具集的选择是否会有任何不同，但这确实（probably a different bug）。
在运行中和发生故障的计算机上，MSBuild注册表项和VS2019 / MSBuild文件夹相同。

在我们go reinstalling multiple VS versions之前，是否有人知道可能是什么原因或如何进行更深入的诊断？

Answer 1

如果有一天能对某人有所帮助，我会在这里倾销我的发现。

MSBuild is open source，并略过它似乎包含许多很多额外的跟踪功能。它们是由环境变量触发的-可能是因为它们打算在多个MSBuild进程中使用。这是对我有用的（部分）列表：

MSBUILDDISABLENODEREUSE = 1-避免产生多个进程，有助于调试。
MSBUILDENABLEDEBUGTRACING = 1-启用多个内部Trace.WriteLine调用
MSBUILDDEBUGEVALUATION = 1-围绕一些项目属性评估方法（Trace.WriteLine，IsDirty \ Set Remove），还有GlobalProperty
MSBUILDDEBUG = 1-启用许多Console.WriteLine调用，主要是围绕缓存管理。
MSBUILDDEBUGONSTART = 2-等待附加调试器， = 1-启动新的调试器。
MSBUILDDEBUGSCHEDULER = 1-关于BuildRequest管理的大量详细消息。默认情况下，将其转储到EngineTrace_ {processId} .txt文件中的Path.GetTempPath（）中，并且可以由MSBUILDDEBUGPATH覆盖。

即使不从源代码构建，也可能有很多方法来拦截这些消息。我所做的就是将MSBuild可执行文件加载到VS中并运行它-因此（1）我在输出窗格中看到了所有消息，（2）每当我闯入一个功能时VS为我下载了匹配的CS源（您需要启用源服务器+源链接，位于“工具/选项/调试/常规”下。

我还在工作机器和故障机器之间做了很多消息转储的比较。在我们的案例中，问题是先前VS版本的卸载不正确，但是您可能对此不太感兴趣。

MSBuild分配了错误的TargetFrameworkSDKToolsDirectory

1 个答案: