Workarounds for ".NET DllNotFoundException after Windows Update"

[logicaloud]

Hi, this is a question about issue #60144 for a long running service application using the shared framework across various plugins. Windows update could pull the rug out from under that application, potentially rendering all or parts of the application non-functional.

The suggested solution for this issue is to configure the deferred removal policy keys for .NET. However, this shifts the responsibility to the customer and any application deployed without the proper removal policy setting is not protected from a crash. Automatically overriding this setting for a single app seems like overreach.

A suggested workaround is to lock all .NET files when the application starts, see: #60144 (comment)

What has not been considered so far is, to run an application and plugins against a dedicated shared .NET runtime by setting DOTNET_ROOT for the application (see: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-environment-variables#dotnet_root-dotnet_rootx86-dotnet_root_x86-dotnet_root_x64). The responsibility to keep the dedicated .NET runtime up to date moves to the vendor since Windows Update presumably applies updates to the global .NET installation only. The advantage is, that the globally shared .NET installation can update without interfering with the application. The disadvantage is that there is an additional .NET installation on the machine just for the application and plugins.

Would such a "DOTNET_ROOT" approach be feasible? Do the advantages outweigh the disadvantages? Any opinions appreciated.

[deuxdoom]

Yes, a privately deployed runtime is a reasonable option for this. The detail I'd be careful about is how the service starts: DOTNET_ROOT and its architecture-specific variants are used by generated apphosts. Setting them doesn't redirect a globally installed dotnet.exe that you explicitly launch.

For a framework-dependent DLL, you can instead make the launcher use the private host directly:

& 'C:\Vendor\dotnet\dotnet.exe' --list-runtimes
& 'C:\Vendor\dotnet\dotnet.exe' 'C:\Vendor\App\MyService.dll'

If you launch the apphost (MyService.exe), set the appropriate root in that service process's environment, and check the higher-priority architecture-specific variable too. For an x64 apphost, DOTNET_ROOT_X64 takes precedence over DOTNET_ROOT. The private installation still needs the framework/version required by the application's runtime configuration.

For your long-running service, I'd deploy runtime updates into a new directory, switch the launcher during a controlled restart, and keep the old directory until processes using it have stopped. Updating or pruning the private runtime underneath the running process could recreate the lifetime problem you're trying to avoid.

Plugins loaded into that process still need to be compatible with its runtime; this doesn't select a separate runtime for each plugin or isolate native DLLs from Windows changes. A self-contained deployment is another supported option if sharing a private runtime isn't important.

The tradeoff you describe is real: you gain control over runtime replacement, and your deployment process takes responsibility for servicing it.

Host environment variables · Manual installation · Deployment options

Prepared with AI assistance (OpenAI Codex, GPT-6 family), with the hosting details checked against the linked documentation.