DeployHQ reads `sdk.version` from your `global.json` to select the right **.NET series** (for example, `8.0.x` or `10.0.x`), and the build then runs against whichever SDK patch we ship for that series. So if your `global.json` says `8.0.100` and we ship `8.0.422`, the build uses `8.0.422` -- the series matches, but the patch doesn't.

This is necessary because the .NET CLI's default `rollForward: latestPatch` policy only rolls forward within the same feature band -- it won't cross feature-band boundaries. The third digit of a .NET 8 patch encodes the feature band: `8.0.100` is in the 1xx band, `8.0.422` is in the 4xx band, so pinning `8.0.100` against an installed `8.0.422` would refuse to run. To work around this cleanly, we temporarily rename `global.json` to `global.json.original` for the duration of the build, then restore it on completion. The result is that the SDK we ship for your selected series is the one your build commands actually run against.

If you need an exact patch that DeployHQ doesn't currently ship, you can install it yourself from your build commands using Microsoft's `dotnet-install.sh` script.

For the full resolution order and version list, see [Building .NET applications](Article: building-dotnet-applications).
