Remove build-nuget from dml-vs-2022.yml (#24372)
The Azure DevOps pipeline template
[/nuget/templates/dml-vs-2022.yml](https://github.com/microsoft/onnxruntime/blob/main/tools/ci_build/github/azure-pipelines/nuget/templates/dml-vs-2022.yml)
is used to build the ONNX Runtime DirectML (DML) components. It
historically contained two potential mechanisms for creating NuGet
packages:
1. Invoking `python tools/ci_build/build.py` with the `--build_nuget`
flag.
2. Executing a specific `NuPackScript` (usually calling `msbuild
/t:CreatePackage`).
This redundancy created a significant problem during release builds
(when the pipeline parameter IsReleaseBuild is set to true). Here's why:
- Duplicate Package Creation: Both packaging methods would execute.
- build.py --build_nuget created a package with a
development/pre-release version suffix (e.g.,
Microsoft.ML.OnnxRuntime.DirectML.1.21.1-dev-20250408-0849-84808eb710.nupkg).
- The NuPackScript's msbuild call, influenced by IsReleaseBuild=true,
created the clean release version package (e.g.,
Microsoft.ML.OnnxRuntime.DirectML.1.21.1.nupkg).
- ren Command Failure: For the x86 and arm64 builds, the NuPackScript
contains a command like:
```Bash
ren Microsoft.ML.OnnxRuntime.DirectML.* win-dml-x86.zip
```
This command fails when two files match the pattern
Microsoft.ML.OnnxRuntime.DirectML.* (the dev package and the release
package), as ren requires a single source file when using wildcards for
renaming.
- Result: This caused build failures specifically when attempting to
create release candidates or final release builds for x86 and arm64 DML
components. This issue did not typically occur in regular nightly builds
(IsReleaseBuild: false) because only one package (the dev version) was
likely produced, allowing the ren command to succeed. Therefore we only
found the problem when doing a patch release for ONNX Runtime 1.21.
(@amarin16, the release manager of ONNX Runtime 1.21, found the issue
and explained it to us why the pipeline was not working)
The change is relatively simple. This PR removes the `--build_nuget`
flag from the `python tools/ci_build/build.py` command within the
dml-vs-2022.yml template. By removing the redundant packaging step from
build.py, only the NuPackScript's msbuild command generates a package
file. This ensures only one file matches the
Microsoft.ML.OnnxRuntime.DirectML.* pattern, allowing the subsequent ren
command in the x86 and arm64 scripts to execute successfully during
release builds.
# Background (how the DML packaging pipeline works)
The build has two stages:
1. Individual Architecture Builds (Using dml-vs-2022.yml): Each stage
(x64, x86, arm64) runs, now reliably using only its specific
NuPackScript to generate its artifact without the risk of the ren
command failing during release.
x64 produces: Microsoft.ML.OnnxRuntime.DirectML.[version].nupkg
x86 produces: win-dml-x86.zip
arm64 produces: win-dml-arm64.zip
(arm32 is not built/included).
2. Final Packaging Stage (e.g., stages/nuget_dml_packaging_stage.yml):
Downloads these artifacts and combines them by unpacking the base x64
.nupkg, injecting the contents of the .zip files into the appropriate
runtimes/ directories (e.g., runtimes/win-x86/native/,
runtimes/win-arm64/native/), and re-packing the final,
multi-architecture Microsoft.ML.OnnxRuntime.DirectML.nupkg.
In stage 1 only x64 produces a nuget package, therefore specific MSBuild
parameters: `/p:IsReleaseBuild=${{ parameters.IsReleaseBuild }}` is
passed to all architectures' MSBuild calls, while
`/p:CurrentData=$(BuildDate) /p:CurrentTime=$(BuildTime)` are passed
only in the x64 script. BTW, the property "CurrentData" apparently is a
typo. It should be `CurrentDate`.
