On Windows IIS hosts, most ASP.NET Core sites still publish framework-dependent. That means the worker process loads a shared .NET runtime from the machine—not the one zipped next to your DLLs. If you never set roll-forward policy, the default can pick a newer minor or major than you tested, or refuse to start after a host patch lands.

For .NET 10 apps on IIS, treat roll-forward as a deliberate deploy setting—same class of control as the app pool bitness or the ANCM hosting model. One line in runtimeconfig (or the matching MSBuild property) keeps patch Tuesday helpful and major upgrades intentional.

#What the host actually loads

When the ASP.NET Core Module starts an in-process or out-of-process site, the shared framework resolver reads your app’s *.runtimeconfig.json. That file names the target framework (for new work, Microsoft.NETCore.App 10.0.x) and optional rollForward / applyPatches behavior. Self-contained publishes bypass this path; framework-dependent FDD and many Web Deploy drops do not.

On a maintained Windows Server 2025 box you often have several 10.0 patches side by side, and sometimes a preview or an older LTS for other sites. Without an explicit policy, you are betting on installer defaults and whatever else was installed for a different customer app pool.

#Pick a policy that matches shared hosting

For production sites on shared or reseller Windows pools, the practical default is latest patch on the same major.minor you built against. That absorbs security and reliability fixes on the host without jumping you to an untested band.

  • LatestPatch — stay on 10.0.*, take newest patch (usual production choice on a patched host).
  • Minor / LatestMinor — allow newer 10.x feature bands; only if you regression-test those bands.
  • Major / LatestMajor — dangerous on multi-tenant IIS; a host-wide install could move you across LTS boundaries.
  • Disable — exact framework only; fails closed if the host moved forward and removed the old patch.

Disable is useful for forensic repro or a golden-image VPS you fully control. On shared IIS it often turns a routine host patch into an outage for any app pinned too tightly.

#Set it in the project, not by hand after publish

Prefer MSBuild so every Web Deploy or folder publish emits the same runtimeconfig. For a .NET 10 web app that should ride host patches on 10.0:

xml 
<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
  <RollForward>LatestPatch</RollForward>
  <!-- optional: keep applyPatches explicit -->
  <ApplyRuntimeForwardPolicy>true</ApplyRuntimeForwardPolicy>
</PropertyGroup>

After publish, confirm the generated MyApp.runtimeconfig.json. You want the framework name/version you expect and rollForward set—not a hand-edited one-off on a single server.

json 
{
  "runtimeOptions": {
    "tfm": "net10.0",
    "rollForward": "LatestPatch",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "10.0.0"
    }
  }
}

If you must override on one machine without republishing, editing runtimeconfig works, but the next deploy will clobber it—encode the policy in CI instead.

#Verify on the IIS box before traffic moves

SSH/RDP habits differ; the checks are the same. List shared frameworks, then start the site under the target app pool identity and read the failure in the event log or stdout log if ANCM cannot resolve a framework.

powershell 
# Shared frameworks present for FDD apps
dotnet --list-runtimes

# From the published site folder (framework-dependent)
dotnet MyApp.dll --urls http://127.0.0.1:0
# Ctrl+C after it binds; fixes missing runtime before IIS recycle

Also confirm web.config still points ANCM at your app and the intended hostingModel. Roll-forward does not replace a wrong processPath, a 32-bit pool loading a 64-bit graph, or a missing ASP.NET Core Module. It only answers: given this TFM, which installed runtime is allowed.

When you deliberately move from .NET 8/9 LTS to .NET 10, change TargetFramework, run full smoke tests (including SQL connectivity and Data Protection key load), then deploy. Do not use Major roll-forward as a silent migration mechanism on IIS.

#Practical takeaway

Ship framework-dependent .NET 10 apps to IIS with RollForward=LatestPatch baked into the project file, verify *.runtimeconfig.json in the artifact, and spot-check dotnet --list-runtimes on the server after host maintenance. That gives you patch uptake on Windows Server without letting a shared runtime install yank the app across minor or major bands you never tested. On hosts that already keep the .NET 10 shared framework current, this is the smallest config change that prevents both “framework not found” surprises and accidental upgrade nights.