Share via

Net roll Forward

T S 0 Reputation points
2026-03-09T02:34:49.81+00:00

8.0.7 will not roll forward to 8.0.24. How do I fix?

Windows for home | Other | Windows update
0 comments No comments

2 answers

Sort by: Most helpful
  1. Carl-L 12,350 Reputation points Microsoft External Staff Moderator
    2026-03-13T07:41:52.77+00:00

    Hello T S,

    Welcome to Microsoft Q&A forum.

    There are a few reasons for the .NET not automatically roll-forward. So in this case, we should go through them one-by-one.

    1. .NET 8.0.24 is not installed. This is the most obvious reasons for these inquiries due to a misunderstanding about the process of roll-forward. Roll-forward only choose the best version of .NET is your computer to run, which can exceed the requirements of the apps itself. This process won't download anything. So if the targeted version is not installed, roll-forward will not do anything. In this case, the solution is simple, you can download and install the version of .NET 8.0 in the Microsoft official website.
    2. The app is self-contained. These types of apps will carry their own .NET runtime in their kit, which is optimized by the developer for the app to run correctly and the user don't have to install .NET runtime of their own. In this case, the app will need to be republished by the developer with a new kit that include the newer version of .NET.

    If you want to, can you please tell me the issue you see and the apps that you are having issue with so I can check what happened. I'm waiting for your reply.


    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.


  2. Q&A Assist
    2026-03-09T02:35:00.44+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    For .NET, “roll forward” only happens within the same major/minor family and is controlled by the runtime/host and configuration, not by Windows Update alone.

    Key points from the context:

    1. For framework-dependent apps (using the shared runtime on the machine):
      • The host chooses the latest patch in the requested major/minor family.
      • Example: if the app targets net5.0 and 5.0.2 is the latest installed, 5.0.2 is used.
      • If no acceptable 8.0.* version is installed, the app won’t run.
      • Roll-forward behavior can be controlled via:
        • <RollForward> in the project file.
        • rollForward in *.runtimeconfig.json.
        • DOTNET_ROLL_FORWARD environment variable.
        • --roll-forward parameter on dotnet commands.
      • Values like LatestPatch, Minor, LatestMinor, etc., determine how far forward the runtime can move.
    2. For self-contained deployments:
      • The runtime version is fixed at publish time, not at run time.
      • dotnet publish selects the latest patch in the specified family at restore/publish time.
      • There is no runtime roll-forward; the app carries its own runtime.
      • RuntimeFrameworkVersion in the project can force an exact runtime version for self-contained apps.
    3. For .NET 8 servicing on Windows:
      • .NET 8 servicing updates are upgrades: installing a newer 8.0.x (for example, 8.0.7 or 8.0.8) removes the previous 8.0.x.
      • The update is offered via Microsoft Update/WSUS/MU Catalog if .NET 8.0 is installed on a supported Windows version.

    Given that 8.0.7 does not “roll forward” to 8.0.24:

    • If the app is framework-dependent and the machine only has 8.0.7 installed, it cannot use 8.0.24 until that runtime is actually installed.
    • If the app is self-contained and was published with 8.0.7, it will never roll forward to 8.0.24; republishing with a newer runtime is required.
    • To “fix” this, ensure:
      1. The newer .NET 8.0.x runtime (for example, 8.0.8 or later when available) is installed via Microsoft Update/WSUS/MU Catalog on the machine.
      2. For framework-dependent apps, verify the roll-forward settings (RollForward/rollForward/DOTNET_ROLL_FORWARD/--roll-forward) are not set to Disable or a mode that prevents using the latest patch.
      3. For self-contained apps, republish the application with the desired runtime version (or set RuntimeFrameworkVersion appropriately) and redeploy.

    Once a newer 8.0.x runtime is installed and roll-forward is not disabled, framework-dependent apps that target 8.0 should automatically bind to the latest available 8.0 patch.


    References:

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.