path: root/
diff options
authorSven Boemer <>2019-01-30 16:24:33 -0800
committerGitHub <>2019-01-30 16:24:33 -0800
commit1b43bd8139d053e24ec51c193054555e3352371a (patch)
treea61f5c4012ef53d7058edb6ff2fe26fbe07ddccb /
parentdbb42159bba3d147559032ee496b55aa7e94e6f7 (diff)
Remove run.exe and config.json (#21608)
This moves us one step away from buildtools and towards arcade. This replaces and run.cmd (and all invocations) with " msbuild" and "msbuild.cmd". - I'm using these wrapper scripts for now instead of those in eng/common in order to retain the very helpful "Running <command>" output in the build logs. - I'm using msbuild.cmd instead of to match the current behavior that uses desktop msbuild on windows, instead of dotnet. All of the arguments that used to be implicitly generated by run.exe and config.json are now explicit, resulting in longer (but easier to copy+paste) commands. Some of these arguments are likely unnecessary, but in this change my goal is just to match the run.exe behavior. Later, I would like to go through and clean up parameters that don't need to be passed in every invocation. I might also consider moving more of the common arguments out into variables in a later change. Some of the wrapper scripts now have limited support for parsing "-Argument=Value" style parameters, to support our existing buildpipeline infrastructure, since I thought this was easier to test than changing our buildpipeline definitions. We can remove that parsing logic once we stop using buildpipeline (which has happened at this point). Some subtle parts of the change: * Add msbuild.cmd This simulates the behavior of Tools\msbuild.cmd, which calls desktop msbuild. * Fix BuildOS processing in package build and publish Previously, config.json had its own processing that would set OSName. Instead, we now pass it in explicitly where it's needed (building packages), or not at all (publishing them). * Handle "=" in publish-packages.cmd and other scripts This seems necessary to properly handle the azure access token * Set __BuildOS in PublishPackages Required for cases where the build OS isn't detected during the build such as freebsd. * Use dotnet msbuild in This prevents us from having to deal with different quote escape behavior on windows and linux. Previously, arguments like fileloggerparameters and the logger were given quotes to escape semicolons in the argument. On unix, this prevented the argument from being split up by bash. On windows, it seems that the run.cmd/run.exe tools would prevent the extra quotes from being passed to msbuild.exe (desktop msbuild would choke on the quotes if they were passed along). Unlike desktop msbuild, dotnet msbuild is able to parse the quoted strings, so we simply psas the quoted arguments directly to it on windows. We may be able to do the same on unix. * Fix problem with BuildOS When copying native files during the unix test build, we rely on __BuildOS being set. Fixing the import order and always setting __BuildOS fixes this. We should eventually fix the inconsistent use of BuildOS vs __BuildOS.
Diffstat (limited to '')
1 files changed, 6 insertions, 3 deletions
diff --git a/ b/
index 8d8b16734f..3421c6203b 100755
--- a/
+++ b/
@@ -16,7 +16,10 @@ unprocessedBuildArgs=
# Assume the default '-p' argument if the only arguments specified are specified after double dash.
# Only position parameters can be specified after the double dash.
if [ $# == 0 ] || [ $1 == '--' ]; then
- buildArgs="-p"
+ buildArgs="./build.proj /p:RestoreDuringBuild=true /t:Sync"
+ if [ $1 == '--' ]; then
+ shift
+ fi
while [[ $# -gt 0 ]]
@@ -27,7 +30,7 @@ do
- buildArgs="-p"
+ buildArgs="./build.proj /p:RestoreDuringBuild=true /t:Sync"
unprocessedBuildArgs="$unprocessedBuildArgs $1"
@@ -35,7 +38,7 @@ do
-$working_tree_root/ sync $buildArgs $unprocessedBuildArgs
+$working_tree_root/ msbuild /nologo /verbosity:minimal /clp:Summary /flp:v=detailed\;LogFile=sync.log $buildArgs $unprocessedBuildArgs
if [ $? -ne 0 ]
echo "ERROR: An error occurred while syncing packages; See $working_tree_root/sync.log for more details. There may have been networking problems, so please try again in a few minutes."