msbuild: NuGet static graph restore can cause subsequent builds to fail to expand globs in .NET SDK 6.0.100-preview6

Issue Description

CSC : error CS2001: Source file 'D:\repos\runtime\src\coreclr\System.Private.CoreLib\*.analyzerdata.x64' could not be found. [D:\repos\runtime\src\coreclr\System.Private.CoreLib\System.Private.CoreLib.csproj]
CSC : error CS2001: Source file 'D:\repos\runtime\src\coreclr\System.Private.CoreLib\*.analyzerdata.net6.0' could not be found. [D:\repos\runtime\src\coreclr\System.Private.CoreLib\System.Private.CoreLib.csproj]
CSC : error CS2001: Source file 'D:\repos\runtime\src\coreclr\System.Private.CoreLib\*.analyzerdata.netcoreapp' could not be found. [D:\repos\runtime\src\coreclr\System.Private.CoreLib\System.Private.CoreLib.csproj]

The globbing of items in msbuild isn’t expanded. These files are passed to the compiler as AdditionalFiles items. This was originally reported by @stephentoub.

Steps to Reproduce

This should be easily reproducible by doing the same globbing as in the link below in a hello world app. Note that this seems to be dependent on the exact version of msbuild being used.

Expected Behavior

The items specified in https://github.com/dotnet/arcade/blob/28a6403ee97077256fcdc60f599f0ad9e38e3cfa/src/Microsoft.DotNet.CodeAnalysis/build/Microsoft.DotNet.CodeAnalysis.targets#L21-L25 should be expanded correctly. The wildcard should be expanded and not hardcoded as a literal *.

Actual Behavior

The wildcard globbing isn’t expanded and the wildcard * is written literally.

Analysis

Versions & Configurations

MSBuild version = “17.0.0-preview-21317-11+c579afe9c”

Attach a binlog

Internal link for MSFT employees: https://microsofteur-my.sharepoint.com/:u:/g/personal/vihofer_microsoft_com/EftKjjkbyK5JvpaijHLKfjABIeIYvPIfQk_fIslqqn-rQA?e=suROf8

About this issue

Original URL
State: open
Created 3 years ago
Comments: 21 (18 by maintainers)

Most upvoted comments

I would also argue that MsBuildSkipEagerWildCardEvaluationRegexes ranks higher on the hack-o-meter than MSBUILDNOINPROCNODE so if it’s used in a prod scenario, we should think about making it a command-line argument or API as well.

ladipro on Jun 24, 2021

I finally found dotnet.exe where it is explicitly set. These are two worker nodes launched from the same process:

AHA! State is leaking from NuGet setting this for restore:

https://github.com/NuGet/NuGet.Client/blob/b83566ec2369c4e9fd07e6f95d734dfe370a1e66/src/NuGet.Core/NuGet.Build.Tasks.Console/MSBuildFeatureFlags.cs#L76

https://github.com/NuGet/NuGet.Client/blob/b83566ec2369c4e9fd07e6f95d734dfe370a1e66/src/NuGet.Core/NuGet.Build.Tasks.Console/MSBuildFeatureFlags.cs#L16

cc @jeffkl, @nkolev92

I think this may be new behavior related to dotnet/sdk#18263 (cc @rokonec): before, NuGet’s limit of 1 worker node would have been in-proc; now it’s forced out by MSBUILDNOINPROCNODE.

https://github.com/NuGet/NuGet.Client/blob/b83566ec2369c4e9fd07e6f95d734dfe370a1e66/src/NuGet.Core/NuGet.Build.Tasks.Console/MSBuildStaticGraphRestore.cs#L872-L874

Long term, I think we should teach NuGet to unset MSBUILDNOINPROCNODE or at least set EnableNodeReuse=false.

This suggests a workaround: set the environment variable DOTNET_CLI_DO_NOT_USE_MSBUILDNOINPROCNODE=true, kill all dotnet.exe processes, and it should work ok.

rainersigwald on Jun 22, 2021

I have a local repro with SDK 6.0.100-preview.6.21321.7 and the dotnet/runtime repo as in the OP.

rainersigwald on Jun 21, 2021