A common user complaint is the appearance of yellow triangles in the dependencies tree with no explanation as to what is wrong or how to resolve the issue.
When a design-time build fails, the dependencies tree often shows all dependencies with a yellow triangle. This happens because the evaluated value was observed, but the resolved item is not found in the build results (due to the failure).
With the semi-recent rewrite of the dependencies tree, we're taking a more cautious approach to displaying these warnings. For example, we don't show yellow triangles during project load, instead waiting until it seems that there's really a reason for concern (i.e. we received build results and the item actually was missing).
This change here takes into account whether the build failed. When it does, no warning icons are added to items.
Ideally, design-time build failures would be surfaced elsewhere, such as in the error list. That work can be done separately.
Today I stumbled upon a repro for the above. A DDRITs solution in the VS repo (ProjectSystemOpenClose.sln) won't open in VS due to:
MSB4019 The imported project "D:\build\Microsoft.CodeIndex.EnvVarDump.targets" was not found. Confirm that the expression in the Import declaration "\build\Microsoft.CodeIndex.EnvVarDump.targets" is correct, and that the file exists on disk.
That comes from this target:
<Import
Condition="'$(RichCodeNavTargetImported)'=='' AND '$(IsMSBuildRetail)' != 'true'"
Project="$(PkgMicrosoft_CodeIndex_EnvVarDump)\build\Microsoft.CodeIndex.EnvVarDump.targets" />
The PkgMicrosoft_CodeIndex_EnvVarDump property is not defined, because the Microsoft.CodeIndex.EnvVarDump package is not referenced in this solution. The path it really wants is D:\NuGetPackages\microsoft.codeindex.envvardump\0.1.2330-alpha-g5c81d269c8\build\Microsoft.CodeIndex.EnvVarDump.targets.
So, given that DTB failure, here's the before/after:
Before
After
In this case, the error impacts normal user-requested builds too, so it's obvious to the user that something is wrong with the solution. If it were a failure in a DTB-only target, for example, it wouldn't be possible to see the source of the error. We should surface DTB errors in the UI somewhere as a future improvement.
A common user complaint is the appearance of yellow triangles in the dependencies tree with no explanation as to what is wrong or how to resolve the issue.
When a design-time build fails, the dependencies tree often shows all dependencies with a yellow triangle. This happens because the evaluated value was observed, but the resolved item is not found in the build results (due to the failure).
With the semi-recent rewrite of the dependencies tree, we're taking a more cautious approach to displaying these warnings. For example, we don't show yellow triangles during project load, instead waiting until it seems that there's really a reason for concern (i.e. we received build results and the item actually was missing).
This change here takes into account whether the build failed. When it does, no warning icons are added to items.
Ideally, design-time build failures would be surfaced elsewhere, such as in the error list. That work can be done separately.
Today I stumbled upon a repro for the above. A DDRITs solution in the VS repo (
ProjectSystemOpenClose.sln) won't open in VS due to:That comes from this target:
The
PkgMicrosoft_CodeIndex_EnvVarDumpproperty is not defined, because theMicrosoft.CodeIndex.EnvVarDumppackage is not referenced in this solution. The path it really wants isD:\NuGetPackages\microsoft.codeindex.envvardump\0.1.2330-alpha-g5c81d269c8\build\Microsoft.CodeIndex.EnvVarDump.targets.So, given that DTB failure, here's the before/after:
Before
After
In this case, the error impacts normal user-requested builds too, so it's obvious to the user that something is wrong with the solution. If it were a failure in a DTB-only target, for example, it wouldn't be possible to see the source of the error. We should surface DTB errors in the UI somewhere as a future improvement.
Microsoft Reviewers: Open in CodeFlow