DotNetRuntimeValidation nonshipping archives lose build suffix in stable builds

[mmitche]

Description

DotNetRuntimeValidation is a nonshipping asset, but its archive filename directly concatenates VersionPrefix and VersionSuffix:

https://github.com/dotnet/deployment-tools/blob/main/src/DotNetRuntimeValidation/Directory.Build.targets

DotNetRuntimeValidation-$(VersionPrefix)-$(VersionSuffix)-win-$(TargetArchitecture).zip

When deployment-tools is built with stable/stabilized product versioning, VersionSuffix is empty. This produces names such as:

• assets/x86/DotNetRuntimeValidation-10.0.0--win-x86.zip
• assets/x64/DotNetRuntimeValidation-10.0.0--win-x64.zip
• assets/arm64/DotNetRuntimeValidation-10.0.0--win-arm64.zip

These entries appear in the manifests from VMR build 3049220, with RepoOrigin=deployment-tools, NonShipping=true, and the corresponding Windows_*_Artifacts origin.

This bypasses the repository's nonshipping-aware version flow: Directory.Build.targets sets IncludePreReleaseLabelInPackageVersion=true when IsShipping != true. A deployment-tools package in the same manifest is correctly unique (Microsoft.Deployment.DotNet.Releases.2.0.0-rtm.1.26416.102.nupkg), while the validation archive has no build suffix.

Impact

The empty suffix emits a double separator and, more importantly, gives every stable build the same archive name/version. This creates collisions between builds; examples include build 3030876 and build 3049329.

Regression timing

• Before stabilization, VMR build 20260417.14 produced DotNetRuntimeValidation-10.0.0-preview.1.26217.114-win-x64.zip.
• dotnet/dotnet#5854, merged 2026-04-22, reset deployment-tools to stable build 306729 / deployment-tools commit 95a979e, exposing the filename/property issue under rtm / StabilizePackageVersion=true versioning.
• The earliest archived affected manifest found is VMR build 20260428.18, with DotNetRuntimeValidation-10.0.0--win-x64.zip.

Expected behavior

Nonshipping DotNetRuntimeValidation archive names should retain a unique prerelease/build suffix even when the repository/product build is stable, and should never emit an empty -- separator.

The filename likely needs to consume the nonshipping-aware evaluated version rather than directly concatenating VersionPrefix/VersionSuffix; the exact property and target evaluation ordering should be validated in the fix.