Dynamo fails to initialize with FileNotFoundException after an in-place .NET 8 runtime patch, and the resulting dialog cannot be dismissed, which blocks saving the model

[pahanitsch]

Dynamo Version

Dynamo Core 3.x.x, Dynamo Revit 3.x.x

Revit Version

Revit 2025.x

Operating System

Windows 11 x64, domain joined workstation. .NET runtime patches are deployed by an endpoint management agent that downloads the official Microsoft bundle installers and runs them silently.

What did you do?

1. The user started Revit 2025 at about 07:00 and worked in a model.
2. At 08:25 the management agent silently installed windowsdesktop-runtime-8.0.30-win-x64.exe while Revit was running. The installer put 8.0.30 in place and removed the previous version. On this machine no files of 8.0.29 were locked, so the directory C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.29\ was deleted immediately and no reboot was pending.
3. At about 09:00, in the same Revit session, the user clicked Dynamo Player.

What did you expect to see?

Either Dynamo starting normally, or one dismissible message stating that the .NET runtime changed under the running process and Revit has to be restarted. Above all, the model still has to be saveable.

What did you see instead?

A modal error dialog:

System.IO.FileNotFoundException: Could not load file or assembly
'System.Xml.XPath.XDocument, Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'. Das System kann die angegebene Datei nicht finden.
File name: 'System.Xml.XPath.XDocument, Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'
at Dynamo.Engine.LibraryCustomization.GetNamespaceCategory(String namespaceName)
at Dynamo.Engine.FunctionDescriptor.GetRootCategory()
at Dynamo.Engine.FunctionDescriptor.get_Category()
at Dynamo.Search.SearchElements.ZeroTouchSearchElement..ctor(FunctionDescriptor functionDescriptor)
at Dynamo.Models.DynamoModel.AddZeroTouchNodeToSearch(FunctionGroup funcGroup, Document iDoc)
at Dynamo.Models.DynamoModel.AddZeroTouchNodesToSearch(IEnumerable`1 functionGroups)
at Dynamo.Models.DynamoModel.InitializeNodeLibrary()
at Dynamo.Models.DynamoModel..ctor(IStartConfiguration config)
at Dynamo.Applications.Models.RevitDynamoModel..ctor(IRevitStartConfiguration configuration)
at Dynamo.Applications.Models.RevitDynamoModel.Start(IRevitStartConfiguration configuration)
at Dynamo.Applications.DynamoRevit.InitializeCoreModel(DynamoRevitCommandData commandData)
at Dynamo.Applications.DynamoRevit.LoadDynamoWithoutSplashScreen()
at Dynamo.Applications.DynamoRevit.ExecuteCommand(DynamoRevitCommandData commandData)

The dialog reappears every time it is confirmed. It also fires again when Revit is closed, which means Save and Save As are unreachable. The user had to terminate Revit from Task Manager and lost the work done since the last save.

Stacktrace/logs

Event log from the affected machine:

25.08.2026 08:25:54 Microsoft ASP.NET Core 8.0.30 Shared Framework (x64) -- Installation completed successfully
25.08.2026 08:26:00 Microsoft .NET Runtime - 8.0.30 (x64) -- Installation completed successfully
25.08.2026 08:26:02 Microsoft Windows Desktop Runtime - 8.0.30 (x64) -- Installation completed successfully
25.08.2026 08:26:04 Microsoft Windows Desktop Runtime - 8.0.29 (x64) -- Removal completed successfully
25.08.2026 08:26:09 Microsoft .NET Runtime - 8.0.29 (x64) -- Removal completed successfully

Details

This issue was created with the help of Opus 5 and then reviewed by human, by me :)

System.Xml.XPath.XDocument is a facade assembly of the shared framework. In a normal Revit session nothing touches it. It is first requested when LibraryCustomization parses the ZeroTouch customization XML during InitializeNodeLibrary, which happens at the first Dynamo or Dynamo Player invocation and not earlier.

When the shared framework is patched in place, assemblies the process has already loaded stay resolvable, because the installer cannot delete files that are in use and defers them. Assemblies that were never touched are deleted together with the old version directory. The running process still probes the old versioned path and gets FileNotFoundException.

Microsoft has described this behaviour in dotnet/runtime#60144 and dotnet/runtime#119550. It is not specific to Revit, but Dynamo is unusually exposed to it because it is the largest consumer of rarely used framework assemblies inside a Revit session, and because it is typically started hours after the host process.

Why this looks random

On a second machine in the same office the identical patch ran on 24.08 while Revit was also open. There the removal of 8.0.29 reported Ein Neustart ist erforderlich, the files were locked and cleanup was deferred to the next reboot. The old directory survived and that machine was never affected.

So whether the failure happens depends on whether any process happened to hold a handle on the old runtime files at the moment of the patch. That is why this surfaces only every few weeks and looks impossible to reproduce, and it is also why users and support end up chasing unrelated causes like corrupted packages or third party add-in conflicts.

[pahanitsch]

Suggested fixes, in order of priority

1. Make the failure recoverable. Catch assembly load failures during InitializeCoreModel and InitializeNodeLibrary, show one dismissible message naming the cause and asking the user to restart Revit, and do not rethrow during Revit shutdown. Losing Dynamo for the rest of the session is acceptable. Losing the ability to save the model is not.
2. Load the required assemblies eagerly at add-in startup instead of at first command execution. This is not a new mechanism in this codebase. DynamoRevit REVIT-234667 Teach Dynamo Revit to load Steel Connections assemblies during splash screen loading #3166 (REVIT-234667) already teaches Dynamo for Revit to load the Steel Connections assemblies during splash screen loading, and Dynamo #16179 with the cherry pick #16223 (DYN-8807) adds a ResolveAssembly handler before PreloadLibraries. Extending the same preloading to the System.Xml.Linq facade set used by LibraryCustomization would pin those assemblies while Revit starts and remove this failure class entirely.