Block all ProjectImports.zip files

[asklar]

Fixes #5033 - at least the ProjectImports.zip part :)
Grab yourselves a chair because this is a doozy.
We've seen intermittent reports of Metro bundler hitting file-in-use errors on msbuild.ProjectImports.zip and similar. However there are no such files... WTH is going on and who is creating these files?!

We invoke MSBuild with the /bl flag to produce binary logs that we can inspect should something go wrong while building. These binary logs include all the commands that the build ran as well as all of the project files, props, targets, etc. that were imported. You can control whether the imported files are included in the .binlog file by choosing whether you want to Embed the imports (this is the default), create a separate zip file (ZipFile) or not include the imports at all (None) by specifying something like /bl:ProjectImports=None, etc.

We don't specify any ProjectImports flag so we are getting the default (Embed). So why is Metro complaining? Well, after looking through the MSBuild code, it turns out that the way this is implemented in MSBuild is that the zip file is created, msbuild writes to it as the build progresses, and then when it's about to finish it closes the file, reads all its contents and writes the contents into the binlog, then deletes the file. This approach will create file contention obviously.
Relevant MSBuild code

So then the question is but why does Metro care about this file? Why is it even monitoring it?
It turns out Metro has a set of asset and source extensions that are configurable (see configuration). The default Metro set of asset extensions however, includes zip files: Default metro configuration

This change updates our metro.config.js files to ignore all *.ProjectImports.zip files, not just msbuild.ProjectImports.zip. Note that the prefix is given by the name of the binary log file, which is why we started seeing errors about Deploy.ProjectImports.zip too.

I've also filed a doc bug and a product bug against MSBuild

Microsoft Reviewers: Open in CodeFlow

[ghost]

Hello @asklar!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

Do note that I've been instructed to only help merge pull requests of this repository that have been opened for at least 10 hours, a condition that will be fulfilled in about 9 hours 43 minutes. No worries though, I will be back when the time is right! 😉

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[dannyvv]

[dannyvv]

Was also thinking to update the logging (since the text logs go to %TEMP%, move those to a well defined relative folder i.e. %CD%\BuildLogs, place the binlog there too and then have azdev task to publish that folder each time...

[kmelmon]

Do you also need to update the metro.config.js in packages/playground? #Resolved

[asklar]

Do you also need to update the metro.config.js in packages/playground?

@kmelmon
looks like we don't blacklist it in playground but we should, good catch! #Resolved

[kmelmon]

thanks!

---

In reply to: 636170652 [](ancestors = 636170652)

[kmelmon]