Improve MSB4019 to include unevaluated path

[danmoseley]

Example -- I got this

C:\git\aspire-samples\samples\AspireWithJavaScript\AspireJavaScript.Angular\node_modules\lmdb\dependencies\lz4\lib\dll\example\fullbench-dll.vcxproj(28,3): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.pr
ops" was not found. Confirm that the expression in the Import declaration "\Microsoft.Cpp.Default.props" is correct, and that the file exists on disk.

this originates from this line in the .vcxproj:

<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />

It would be useful to know that $(VCTargetsPath) is evaluating to empty. It takes me a little closer to the problem.

At the point that MSB4019 is emitted, can it access the unevaluated value of the attribute, and include that in the message?

[rainersigwald]

Yes we should definitely do this for the general case.

For your specific error (C++), we should extend the special-casing from https://github.com/dotnet/msbuild/issues/8967 to flag it.

[AR-May]

We soon should have a build-in analyzer for catching similar situations: #9883. But if we can improve the error here, that will also help.

@baronfel what you think about it and in case we should improve the error, what would be your idea of the wording?

[rainersigwald]

My proposed wording is:

Confirm that the expression in the Import declaration "$(VCTargetsPath)\Microsoft.Cpp.Default.props", which evaluated to "\Microsoft.Cpp.Default.props" is correct, and that the file exists on disk.

where the first one is the unevaluated value and the second one is the evaluated one we're currently logging.

[danmoseley]

My proposed wording is:

Sounds good to me

[danmoseley]

do you label 'help wanted' to things like this?

[wpostma]

Random internet person wondering if this msbuild related task is going to hopefully make MSB4019 errors less confusing and misleading.

Currently I have a project which fails to build with this error:

Severity Code Description Project File Line Suppression State Details Error MSB4019 The imported project "C:\cppdev\wordtsar-mercurial\QtMsBuild\Qt.props" was not found. Confirm that the expression in the Import declaration "C:\cppdev\wordtsar-mercurial\QtMsBuild\Qt.props" is correct, and that the file exists on disk. wordtsar C:\cppdev\wordtsar-mercurial\wordtsar.vcxproj 159

The thing that annoys me is that QtMsBuild is not needed for this project to work, and QtMsBuild appears to get installed without my consent and not uninstalled by whatever THIRD PARTY vendor makes the QT Tools for Visual Studio.

I think that's a valid example case of where things are confusing when msbuild fails. I have no idea how to debug this issue, and am close to "format drive C and reinstall windows" as the only possible way to find and fix what's wrong with msbuild, or visual studio.

The folder QtMsBuild does not, and should not exist, in the working copy of the above C++ app repo (wordtsar-mercurial). I suspect that it's being inserted just because msbuild is assuming everything wants to exist must be in a folder in its search path.

The vcxproj contains this

<ImportGroup Condition="Exists('$(QtMsBuild)\qt_defaults.props')">
    <Import Project="$(QtMsBuild)\qt_defaults.props" />
  </ImportGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x64'" Label="QtSettings">
    <QtInstall>6.4.3_64</QtInstall>
    <QtModules>core;gui;widgets;printsupport</QtModules>
    <QtBuildConfig>debug</QtBuildConfig>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'" Label="QtSettings">
    <QtInstall>6.4.3_64</QtInstall>
    <QtModules>core;gui;widgets;printsupport</QtModules>
    <QtBuildConfig>release</QtBuildConfig>
  </PropertyGroup>
  <Target Name="QtMsBuildNotFound" BeforeTargets="CustomBuild;ClCompile" Condition="!Exists('$(QtMsBuild)\qt.targets') or !Exists('$(QtMsBuild)\qt.props')">
    <Message Importance="High" Text="QtMsBuild: could not locate qt.targets, qt.props; project may not build correctly." />
  </Target>

It appears that detecting and removing these extension-importgroup from broken projects is very difficult to google. If the IDE itself made it possible to inspect and remove broken elements from the .vcxproj without surgery in a text editor, that would be lovely.