How to handle .NET Runtime updates with running applications

Question

How to handle .NET Runtime updates with running applications

Nico-87 0

Last friday we faced an issue with our application where a user was unable to save their data and got a missing file exception.

We believe this might be related to the update of the .NET 8 Runtimes, while our (.NET8) application was running.

The User opened our software on Friday 23rd January at 0800. application is then linked to 8.0.22.
IT security issued a .NET update on the 23rd of January to update .NET 8 from 8.0.22 to 8.0.23.
This update was applied on the users machine while our application was running using 8.0.22 like around 0900
The User pressed Save the first time around 1000.
Only on save it first uses ZipOutputStream and System.Security.Cryptography.Algorithms.dll
Application tries to load it from the 8.0.22 folder which is removed by the security update.

Result: Save fails

Is it correct that the .NET 8 Runtime installer can update the runtime to a newer version, while other .NET 8 apps are still running?

If so, is there a way to prevent this? Or for our application to handle this scenario better?

Looking forward to your advise.

0 comments

3 answers

Your answer

Answer 1

Jack Dang (WICLOUD CORPORATION) 16,115 Microsoft External Staff Moderator

Hi @Nico-87 ,

Thanks for reaching out.

In practice, the most reliable approach is to restart the app after an update or use a self-contained deployment. This ensures all required DLLs are available and avoids runtime errors.

.NET runtime patch updates can replace older patch folders while an app is running. When your app tried to load System.Security.Cryptography.Algorithms.dll from 8.0.22, that folder had already been removed by the 8.0.23 update.

To prevent or mitigate this:

Apply .NET servicing updates only when affected applications are stopped or during maintenance windows to avoid missing-file errors. (https://dori-uw-1.kuma-moon.com/en-us/dotnet/core/releases-and-support)
Catch failures when loading runtime assemblies and prompt users to restart the app. This ensures the process binds to the new runtime instead of failing.
Ship critical runtime dependencies with your app so it doesn’t rely on the shared system runtime. In a self-contained deployment, your app includes all required .NET files and is isolated from system runtime updates. (https://dori-uw-1.kuma-moon.com/en-us/dotnet/core/deploying/)

Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

Nico-87 0 Reputation points

2026-01-29T10:48:00.5433333+00:00

Thanks for the response. I understand that a user is not meant to update the framework while an application is running. Though when it's updated through Microsoft support, the user is not always involved in the update and it may just happen in the background.

In older (.NET Framework) releases, the path didn't change during the upgrade, so maybe it was never a problem. Today the path changes from 8.0.22 to 8.0.23, which is the breaking change.

I don't see delivering all runtime assemblies ourselves as a solution to this problem. We like the fact the runtimes are on the machine, and our product installer ensures the right minimum version is on the system.

It would be nice if the cleanup of the old .NET Runtime versions happens on the next reboot, ensuring running applications continue to run on the previous version.

As more applications move to .NET Core, even apps running "always" in the background. How is this supposed to work with the .NET Core runtime updates?
Bruce (SqlWork.com) 83,666 Reputation points

2026-01-29T20:51:48.0733333+00:00

It is an optional update configuration to purge previous runtime versions when a patch release is installed, especially n-1.
Jack Dang (WICLOUD CORPORATION) 16,115 Reputation points Microsoft External Staff Moderator

2026-01-30T10:41:07.4633333+00:00

Hi @Nico-87 ,

Thanks for your feedback.

With .NET 8, patch updates can remove older runtime folders while apps are running, which may cause errors like failing to load System.Security.Cryptography.Algorithms.dll from 8.0.22. Unlike older .NET Framework updates, the folder paths for each patch version can change. To reduce the risk of such issues, consider applying updates during maintenance windows, catching assembly load failures and prompting a restart, or using self-contained/containerized deployments for always-on apps. Configuring updates to defer cleanup until reboot is another approach to keep running apps stable while using shared runtimes.
Nico-87 0 Reputation points

2026-02-02T09:55:01.68+00:00

I understand what you say. But i think that apps should be able to rely on the .NET 8 Runtimes on the system.
If Windows Updates run in the background and update this to a newer version, while removing the old version, this can break running applications.
As updates are not always triggered by the user, or maybe non-technical users don't see this connection, the update might run, while .NET 8 apps are running.

In our case, our IT department wants to keep the .NET framework current, to ensure all vulnerability fixes are applied. For that same reason, previous installations of .NET 8 are removed, so only the latest remains.

I think the best option would be to enhance the .NET 8 runtime installers to defer the deletion until the next reboot, or maybe a post reboot task. This ensure that any application that is running is not impacted by a sudden deletion of the file.
Jack Dang (WICLOUD CORPORATION) 16,115 Reputation points Microsoft External Staff Moderator

2026-02-02T10:14:43.79+00:00

Hi @Nico-87 ,

Thanks for your prompt feedback.

There’s a trade-off between keeping .NET 8 runtimes up to date for security and ensuring running apps aren’t disrupted. Current .NET 8 patch updates can remove the previous version’s folder while apps are running, which can cause missing-file errors. To reduce risk, updates are typically applied during maintenance windows, or apps catch assembly-load failures and prompt a restart. In line with your suggestion, deferring deletion of old runtime folders until reboot or as a post-reboot task would help long-running apps, and sharing this feedback with the .NET team is the best way to influence future improvements. (Microsoft docs on .NET servicing)

If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.
Nico-87 0 Reputation points

2026-02-10T10:32:31.4366667+00:00

I have submitted a request in the developer community, i don't think we can fix this in our client.
https://developercommunity.visualstudio.com/t/NET-runtime-update-installation-may-bre/11038185

Answer 2

This issue can occur if the .NET Runtime is updated while the application is actively running, especially if the update replaces or modifies runtime files being used by the application.

To handle .NET Runtime updates safely, follow these best practices:

Avoid updating the runtime while the application is running. Always stop the application or service before applying runtime updates.
Restart the application after the runtime update to ensure it loads the updated runtime properly.
Use self-contained deployment if you want your application to use a specific runtime version and avoid dependency on system runtime updates.
In production environments, schedule maintenance windows for runtime updates to prevent unexpected issues.
Monitor application logs and verify runtime version compatibility after updates.

Following these steps ensures stability and prevents missing file or runtime-related exceptions during updates.

Answer 3

Bruce (SqlWork.com) 83,666

All .net core runtimes, even patched versions are installed side by side, so updates can be applied while applications are running. But if you configure the updates to delete the previous patch, then running apps should be stopped before updates.

0 comments

Share via

How to handle .NET Runtime updates with running applications

3 answers

Your answer