Use dotnet fallout instead of ./build.cmd in AppVeyor and Azure Pipelines steps

[ChrisonSimtian]

Fixes #516 for the providers where the bug still lives on main.

Problem

AppVeyor and Azure Pipelines emit a ./build.cmd invocation that only runs on Windows agents:

• AppVeyor emitted - sh: ./build.cmd … — a Unix shell running a .cmd.
• Azure ran script: './build.cmd …' in CmdLine@2 regardless of agent OS.

Both break on Ubuntu/macOS agents. (GitHub Actions — #516's original repro — was already fixed on the 2026 line via dotnet fallout in #203/#204, so it needs no change here.)

Fix

Same shape as the GitHub Actions fix: invoke the cross-platform fallout local tool.

• AppVeyor: dotnet tool restore + dotnet fallout <targets> (emitted under both - cmd: and - sh: so each image runs the matching pair; command is identical).
• Azure: script: 'dotnet tool restore && dotnet fallout <targets>' (&& works in cmd and bash; CmdLine@2 uses the agent's default shell).

No OS branching, no build-script selection.

Out of scope

• TeamCity and SpaceAutomation already select .sh on non-Windows — not broken, left unchanged.
• BuildCmdPath stays on the config types (public API) but is no longer consumed by these two writers.

Verification

Regenerated Verify snapshots; ConfigurationGenerationSpecs 18/18 green.

[ITaluone]

Ahmm.. build.cmd can execute on Unix, but the requirements have to meet: chmod +x (which is probably not set for build.cmd)

The reasons why this should work are:

• extensions are meaningless on unix
• the first part targets unix systems (: is a comment in windows cmd, but a command on unix -> : = the "null command" making this a valid syntax (on windows -> line comment, on unix command)

I think the reason why this doesn't work here: there is no build.cmd file anymore :)

Ou.. and: the : operator only works in bash not in pure /bin/sh, maybe this was an error as well?

(script path should be quoted: "${SCRIPT_DIR}/build.sh" "$@")

Edit: I just tested this against a local project of mine (unix/docker executor).. works fine for me...

[ChrisonSimtian]

Ahmm.. build.cmd can execute on Unix, but the requirements have to meet: chmod +x (which is probably not set for build.cmd)

The reasons why this should work are:

• extensions are meaningless on unix
• the first part targets unix systems (: is a comment in windows cmd, but a command on unix -> : = the "null command" making this a valid syntax (on windows -> line comment, on unix command)

I think the reason why this doesn't work here: there is no build.cmd file anymore :)

Ou.. and: the : operator only works in bash not in pure /bin/sh, maybe this was an error as well?

(script path should be quoted: "${SCRIPT_DIR}/build.sh" "$@")

Edit: I just tested this against a local project of mine (unix/docker executor).. works fine for me...

typical claude PR description ... the whole point of this PR was to go and unify the build entry to use dotnet.
Here is my narrative for changing it:
you wanna build dotnet, therefore a requirement is dotnet is installed on the build agent. Hence we can use dotnet to run fallout, why bother with OS agnostic scripting languages as a bootstrapper?

Claude just tripped over it because we got windows AND linux runners at work and it tried to spin up a linux runner but found the windows one hardcoded, hence made the assumption its because of the CMD (which in return triggered me to say "hey holdup, I changed this already, havent I?")

So all good, just ignore the blurb at the beginning :-)
PR also shouldve been raised in draft, which obviously also went hayway... Must be either my cold making me prompt silly or claude simply being made dumber now that fable is out :D

[ITaluone]

Ok... got it :)

But this will change the behavior for consumers, right? IMHO we should not change the "build agent agnostic" behavior, because it has a real use-case by installing and setting up all which is needed for the pipeline to run.

[ChrisonSimtian]

hence the draft status. Github already does that, my reasoning here is if GH works that way why have the other platforms work differently?
But I also got other plans for CI platforms, so lets see where that goes and what comes in first