Graph restore fails due to unexpanded wildcards

[dfederm]

NuGet Product Used

MSBuild.exe

Product Version

various

Worked before?

no

Impact

It's more difficult to complete my work

Repro Steps & Context

Project with something like:

    <ZipContent Include="ItemTemplates\**\*">
      <Archive>ItemTemplates\$([System.IO.Path]::GetDirectoryName('%(RecursiveDir)')).zip</Archive>
      <ArchivePath>%(Filename)%(Extension)</ArchivePath>
    </ZipContent>

results in:

MSB4184: The expression "[System.IO.Path]::GetDirectoryName('')" cannot be evaluated. The path is not of a legal form.

Upon inspecting the binlog (after commenting out the metadata):

Poking around I found that static graph restore sets MSBuildSkipEagerWildCardEvaluationRegexes to avoid expanding wildcards.

Note: For this specific case a workaround is to use this instead:

<Archive>ItemTemplates\$([System.String]::Copy('%(RecursiveDir)').TrimEnd('\')).zip</Archive>

Since the intent of using Path.GetDirectoryName was simply to remove the trailing slash from %(RecursiveDir)

Verbose Logs

No response

[zivkan]

I was able to reproduce. It only happens with MSBuild.exe, not with dotnet restore.

[zivkan]

If I put the <ItemGroup> in a <Target>, rather than the project evaluation, the warning isn't raised on restore (since MSBuild doesn't need to create the items yet).

@dfederm as far as I can tell item ZipContent isn't "well known", as in something built into MSBuild will read these items. Therefore, I assume you have a custom target somewhere where these items are passed to some task. Are these guesses correct? Is there a good reason that your project is defining this item at evaluation rather than in a target?

When people are back from holidays, we'll discuss in the triage meeting, but I suspect disabling wildcards is part of the design goal of static restore. Static restore was created for huge repos with hundreds of projects, and one of the ways to make restore faster is to not have MSBuild create items that restore doesn't need, like <Compile Include="**/*.cs" />. All that file globbing is measurably slow on large enough repos.

Therefore, maybe we have a docs improvement, otherwise I'm guessing this might end up being a won't fix. But the team will discuss it in January.