Test and product builds often build the same project with the same assembly name but for different OS Group, configuration, TFM, and other parameters at the same time. We have logic that attempts to always generate a unique path (generally for files and folders) when these projects are building at the same time, but this logic is duplicated in many places and not always updated when a new dimension is added to the full matrix of things we build. This task tracks generating an "unique build string" property that can be consumed wherever this uniqueness is required, creating a single point of servicing and simplifying lots of .targets files.
A driving factor in needing this variable is that we routinely have added new ways to build the same project in parallel with slightly different parameters, leading to potential race conditions anywhere the axes of the full matrix of variables are not used in file or folder paths being written.
The most recent, but certainly not only, time this has happened is with Test Dependency list files. The file name is created here:
.... and was acceptable until we started building the same project with the same configuration in parallel.
Having an uber variable that describes all current known parameters of a build allows us to update this in one place when there are bugs. I'd suggest generating this variable and using it to fix the Test Dependency list file names first, then later expanding there anywhere a unique build moniker is needed.
@weshaggard
Test and product builds often build the same project with the same assembly name but for different OS Group, configuration, TFM, and other parameters at the same time. We have logic that attempts to always generate a unique path (generally for files and folders) when these projects are building at the same time, but this logic is duplicated in many places and not always updated when a new dimension is added to the full matrix of things we build. This task tracks generating an "unique build string" property that can be consumed wherever this uniqueness is required, creating a single point of servicing and simplifying lots of .targets files.
A driving factor in needing this variable is that we routinely have added new ways to build the same project in parallel with slightly different parameters, leading to potential race conditions anywhere the axes of the full matrix of variables are not used in file or folder paths being written.
The most recent, but certainly not only, time this has happened is with Test Dependency list files. The file name is created here:
buildtools/src/Microsoft.DotNet.Build.Tasks/PackageFiles/tests.targets
Line 207 in d468095
Having an uber variable that describes all current known parameters of a build allows us to update this in one place when there are bugs. I'd suggest generating this variable and using it to fix the Test Dependency list file names first, then later expanding there anywhere a unique build moniker is needed.
@weshaggard