Installing new SDK with updated Runtime may break running application with older Runtime - switch to load all System-DLL on start?

[JuergenAuer]

Hi,

I had a crazy, self-produced problem with the last Runtime.

Configuration: Old service, created 2008 with NET.Remoting, later updated to WCF, now running as NET.8 minimal API IIS InProcess-hosted. Connected from Sql-Server via NET.4.8-Assembly with System.Net.HttpWebRequest, but the client isn't problem-relevant.

Own code uses some external dll, Mailkit/Mimekit, SSH.NET, System.IO.Compression.ZipFile.

Mailkit is immediately used after restart, sends a notification mail. So the Mailkit.dll is loaded.

ZipFile is rare used, may be only one time per month.

--

2025-07-08: Added the NET.8.0.412 SDK with the new 8.0.18 runtime. No restart of the service. Service runs with 8.0.17.

2025-07-18: Executing of the code that uses ZipFile crashed. File not found. The C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\8.0.17 directory was deleted, instead, a 8.0.18 directory exists.

Restarting the application fixed the problem. Ok, in theory, problem solved.

--

But: It's a general problem. Sometimes a restart / reboot isn't immediately (after SDK-Update) possible. Installing the new runtime 20:30, patching the whole server 01:50 with a reboot. If ZipFile is used the first time between, it would crash.

So idea / question: Is there something like a switch / command line option / config file option, that tells the application: Find and load all dependend DLL immediately after a restart. The delay would not be a problem. Result: All dlls are copied, the 8.0.17 directory isn't longer required. A newer version can delete that directory without affecting running services.

Additional benefit: If a dll is missing / can't be loaded, the application would crash / no start possible. A crash would only affect the test system, so that's not a problem.

Workaround: The old directory not immediately deleted, only in combination with the next reboot. May be there is a standard installation switch to delay the deletion.

PS: Deleting the old directory in general is a good idea. Nobody needs a list of older, never again used patches 8.0.1/8.0.2 etc., if 8.0.18 is installed and used.

[walid-khalafi]

This sounds like it could be related to file handle or directory caching at the OS level after the SDK upgrade. In some cases, ZipFile operations can fail if the working directory or temp path is locked or not refreshed properly.
A few things you could try:

• Explicitly set the extraction/creation path to a known, existing directory (e.g., Path.GetTempPath() or a freshly created folder) before calling ZipFile methods.
• Ensure all streams are properly disposed before the next operation — lingering file handles can cause “directory not found” errors.
• Check if the DOTNET_CLI_HOME or temp directory environment variables changed after the SDK update.
• If reproducible, try running the same code on .NET 8.0.100 to confirm if it’s a regression in 8.0.1xx.
  If you can share a minimal repro, I’d be happy to test it against multiple SDK versions to narrow down whether this is a runtime, SDK, or environment-specific issue.

[JuergenAuer]

Hi @walid-khalafi

• Explicitly set the extraction/creation path to a known, existing directory (e.g., Path.GetTempPath() or a freshly created folder) before calling ZipFile methods.

sorry, my description was incomplete. The exact error:

System.IO.FileNotFoundException: File name: 'System.IO.Compression.ZipFile, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

The Assembly / System-dll could not be loaded, not a local problem when executing a method located in ZipFile.

• f reproducible, try running the same code on .NET 8.0.100 to confirm if it’s a regression in 8.0.1xx.
  If you can share a minimal repro, I’d be happy to test it against multiple SDK versions to narrow down whether this is a runtime, SDK, or environment-specific issue.

It's not possible to reproduce that error. That would require to deinstall the SDK and install it again. That's a productive server.

It's more something like a "logical problem": Installing 8.0.18 when a IIS hosted 8.0.17 is running. The installation deletes the 8.0.17 directory (that was visible), so the reason of the problem is found. But installing the new SDK with the 8.0.19 on my local machine both directories (8.0.18 and 8.0.19) are present (may be will disappear after the next reboot).

If I have to patch a server, there is an option of a delayed reboot (max. 7 days). So the setup says: The machine should work normally. But if the IIS hasn't loaded one specific dll and if that dll will be used the first time after deleting the source directory, it will crash.

I have services that run under dotnet.exe. These services must be stopped to install the new SDK. But it's amazing (and very helpful), that the SDK-installation doesn't require a shutdown of the IIS. So a service running under the older version should work normally until the next reboot. That's one reason I use IIS-hosted Minimal Api code as a service - the service is restartet after reboots, I can use shadowcopy.