DYN-10661: never return a null templates directory

[jasonstratton]

Purpose

Fixes DYN-10661.

PathManager.templatesDirectory has no initializer. Its only assignment is inside UpdatePreferenceItemPath, which returns early without assigning when PathHelper.CreateFolderIfNotExist rejects the location — an unwritable %ProgramData%, an unavailable network share, or an invalid path. A single failed call during startup therefore leaves PathManager.TemplatesDirectory null for the rest of the session.

Two consequences:

1. The reported crash (3.6.2). That null flowed into path.Contains(Model.PathManager.TemplatesDirectory) in DynamoViewModel.InternalSaveAs, so String.Contains threw ArgumentNullException (Value cannot be null. (Parameter 'value')) and Save / Save As / Ctrl+S all failed. Users could only save by closing the file and answering Yes to the save prompt — that route goes through SaveAs(Guid, path), which never calls InternalSaveAs.
2. Still live on master. DYN-: Dyn 10540 template folder tree read only in dynamo #17190 replaced that call with the null-guarded IsPathInTemplateDirectoryTree, which stopped the exception but left the null in place. So the template-folder write-protection added by that PR silently does nothing for affected users, and SetDefaultInitialDirectory quietly throws into its blanket catch and falls back to Desktop.

This PR fixes the cause rather than the symptom: templatesDirectory is seeded with defaultTemplatesDirectory when common directories are built, so the property always reports a usable path and a rejected preference falls back instead of nulling out. The rejection is also logged — that silent failure is why this went unnoticed for two and a half years.

Regression introduced in: #14871 (2024-01-27, "Open Dynamo Template as new workspace") introduced the unguarded Contains call. #17190 (2026-06-23, DYN-10540) incidentally suppressed the exception but not the null.

Fix targets: master only. RC4.2.0_master already contains #17190, so the ArgumentNullException is not reachable there and no cherry-pick is required.

Declarations

Check these if you believe they are true

• Is documented according to the standards
• The level of testing this PR includes is appropriate
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.

Release Notes

Fixed an issue where Dynamo could fail to save a graph, or silently stop protecting the templates folder from being overwritten, when the configured template location was unavailable.

Reviewers

Roberto T (most recent owner of PathManager)

Testing notes — the ArgumentNullException itself is not reproducible on master (the IsPathInTemplateDirectoryTree guard prevents it), so the new tests target the underlying null instead. PathManagerTests fails on master before this change and passes after:

• WhenPathManagerIsConstructedThenTemplatesDirectoryIsNotNull
• WhenTemplateLocationCannotBeCreatedThenTemplatesDirectoryFallsBackToDefault — simulates a rejected location by squatting the target path with a file, the same IOException branch a locked-down %ProgramData% or dead share takes

TemplateSavePathCheckDoesNotThrowWhenTemplateDirectoryIsUnknown locks in the guard so the 3.6.2 crash cannot return via a new caller.

To verify by hand: point <TemplateFilePath> in DynamoSettings.xml at an extensionless file (e.g. C:\Temp\blockedTemplates), restart, then attempt Save As into the templates folder. Before this change the save is allowed; after it the save is blocked and the fallback is recorded in dynamoLog.

FYIs

Aabishkar KC (reporter), Neal Burnham

[github-actions]

See the ticket for this pull request: https://jira.autodesk.com/browse/DYN-10661

[Copilot]

Pull request overview

This PR fixes a long-standing PathManager.TemplatesDirectory nullability issue by ensuring it always has a usable default value, even when a user-configured templates location cannot be created (e.g., locked-down %ProgramData%, invalid path, unavailable network share). This stabilizes downstream template-path checks used during Save/Save As and restores template-folder write protection behavior.

Changes:

• Seed PathManager.templatesDirectory to DefaultTemplatesDirectory during common directory initialization so it never remains null.
• Log a fallback message when applying the preferred templates path fails during preference-location initialization.
• Add regression tests covering (1) non-null TemplatesDirectory on construction, (2) fallback behavior when the preferred location is unusable, and (3) template-path checks treating unknown template directories as “not in template tree”.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
test/DynamoCoreWpf3Tests/WorkspaceSaving.cs	Adds a regression test ensuring template-path checks don’t throw when the templates directory input is null/empty.
test/DynamoCoreTests/Configuration/PathManagerTests.cs	Adds unit tests to ensure TemplatesDirectory is never null and remains usable when a preferred location is rejected.
src/DynamoCore/Models/DynamoModel.cs	Logs when a configured templates location cannot be used and a fallback remains in effect.
src/DynamoCore/Configuration/PathManager.cs	Seeds templatesDirectory from defaultTemplatesDirectory during common directory construction.

[jasonstratton]

Good catch - fixed in fd921c7. The assertion now compares against pathManager.DefaultTemplatesDirectory rather than just checking for a non-empty value, so the test verifies the behavior its name claims.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud