DYN-10248: Fix crash when opening the Python Migration Assistant on an IronPython2 node

[zeusongit]

Purpose

When the active Python engine is IronPython2, Python.Runtime version 2.5.2 (pythonnet 2.x) can be loaded at runtime instead of pythonnet 3.x. The Migration Assistant's ScriptMigrator.MigrateCode uses PyModule — a type introduced in pythonnet 3.x — as a local variable in a using statement. When the JIT compiles that method against the 2.x assembly, the CLR throws a TypeLoadException because PyModule does not exist. PythonMigrationAssistantViewModel only caught PythonException, so the TypeLoadException propagated uncaught and crashed the application.

Key changes:

• Added catch (TypeLoadException) in PythonMigrationAssistantViewModel constructor alongside the existing catch (PythonException) — both now show the diff viewer in State.Error instead of crashing.
• Added optional Func<string, string> codeConverter = null parameter to the constructor so the migration function is injectable for testing. Production callers are unaffected (parameter defaults to ScriptMigrator.MigrateCode).
• Added regression test WhenMigrationThrowsTypeLoadExceptionViewModelShowsErrorState in DynamoPythonTests that injects a delegate throwing TypeLoadException and asserts the ViewModel ends up in State.Error.

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 a crash when clicking the Python Migration Assistant button on an IronPython2 node when pythonnet 2.x is loaded at runtime.

Reviewers

(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)

(FILL ME IN, optional) Any additional notes to reviewers or testers.

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

[github-actions]

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

[Copilot]

Pull request overview

Fixes a crash in Dynamo’s Python Migration Assistant when an incompatible Python.Runtime (pythonnet 2.x) is loaded at runtime (e.g., while IronPython2 is active), by handling TypeLoadException (and related assembly-mismatch exceptions) and ensuring the UI shows an error state instead of letting the exception terminate the app.

Changes:

• Catch TypeLoadException (plus a few other assembly mismatch exceptions) during migration and set the diff viewer to State.Error rather than crashing.
• Add an optional injectable Func<string, string> migration delegate to enable unit testing without relying on pythonnet runtime behavior.
• Add regression tests validating the ViewModel ends in State.Error when migration throws.

Reviewed changes

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

File	Description
src/PythonMigrationViewExtension/MigrationAssistant/PythonMigrationAssistantViewModel.cs	Adds injectable migration delegate and expands exception handling to prevent crash and show error state.
test/Libraries/DynamoPythonTests/PythonMigrationAssistantViewModelTests.cs	Adds regression tests ensuring migration exceptions are handled and reflected as State.Error.

[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

[zeusongit]

Failing test is known flaky

[aparajit-pratap]

When the active Python engine is IronPython2, Python.Runtime version 2.5.2 (pythonnet 2.x) can be loaded at runtime instead of pythonnet 3.x.

Is this expected? Does this always happen? If so, does it mean that IronPython2 cannot be migrated to PythonNet3?

[zeusongit]

When the active Python engine is IronPython2, Python.Runtime version 2.5.2 (pythonnet 2.x) can be loaded at runtime instead of pythonnet 3.x.

Is this expected? Does this always happen? If so, does it mean that IronPython2 cannot be migrated to PythonNet3?

yes, ScriptMigrator.MigrateCode can't run the migration tool (it requires pythonnet 3.x APIs: PythonEngine.Initialize, Py.GIL, PyModule). The fix here just prevents the crash and shows an error state, but the user still can't migrate in that scenario.

[zeusongit]

When the active Python engine is IronPython2, Python.Runtime version 2.5.2 (pythonnet 2.x) can be loaded at runtime instead of pythonnet 3.x.

Is this expected? Does this always happen? If so, does it mean that IronPython2 cannot be migrated to PythonNet3?

yes, ScriptMigrator.MigrateCode can't run the migration tool (it requires pythonnet 3.x APIs: PythonEngine.Initialize, Py.GIL, PyModule). The fix here just prevents the crash and shows an error state, but the user still can't migrate in that scenario.

It also depends on when DynamoIronPython2.7 is installed and its Python.Runtime.dll wins the race at load time. If PythonNet3Engine's v3.x DLL gets into the AppDomain first, ScriptMigrator works fine regardless of which engine is selected on the node.

[jasonstratton]

Aparajit already asked my one question about the API change
So, LGTM