[wix-devs] Intermediate File Path Conflicts

[Sean Hall]

Please help us reproduce the error you're running into because none of us
have seen this locally or on any build server.

1. Which version of nuget.exe are you using? (nuget.exe -help)
2. Which version of Visual Studio do you have installed? "C:\Program Files
(x86)\Microsoft Visual Studio\Installer\vswhere.exe" -version [17.0^,18.0^)
3. Which commit of wixtoolset/wix4 are you trying to build? (sha hash)
4. Is your repository clean and empty of untracked files? (git status)
5. What are the steps to reproduce the error?
6. Most of the build now creates an MSBuild binlog. Please upload it
somewhere and provide a link. If there is no bin log, then please provide
the output from the part of the build that failed.

On Tue, Jan 11, 2022 at 2:42 PM Ron Martin via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> With respect to https://github.com/NuGet/Home/issues/4463, one situation
> I ran into was that multi-targeting makes the situation even worse than
> outlined in the cited nuget issue: It is not sufficient to guarantee
> that each project uses a different intermediate path: all target
> variants of the same project will use the same path for
> project.assets.json, and thus will overwrite each other. If allowed to
> build in parallel, file sharing locks will cause failures. With or
> without parallel building, there is still a possibility that pipelining
> might cause one target variant to use a project.assets.json file
> intended for another target variant..
>
> I spent quite a bit of time investigating ways of creating unique paths
> for each target-specific build variant. I was not successful in changing
> the path of the obj directory created and used by nuget restore. Because
> this is where project.assets.json is placed, I was also unable to
> prevent the specific conflict on the project.assets.json file.
>
> One of the suggested fixes in the cited nuget issue involves including
> the project name in the name of the json file. Since the name is the
> same in the multi-targeted case, this is not a sufficient approach.
>
> I don't know all of the other uses made of the intermediate path, but
> all of them are ultimately subject to the general problem. Any sharing
> of intermediate paths between projects or msbuild targets (in the sense
> of sub-projects, rather than nuget target platforms) will likely break
> if a systematic fix for the underlying problem is implemented.
>
> I have not commented on the cited nuget issue. I wanted to test out my
> observation in friendlier waters first. Perhaps I need to create a
> failing test case to illustrate my point. Let me know what you think.
>
> Ron
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>