Fix Control.Dispose crash when dependent UserControl fails to load due to missing assembly

[LeafShi1]

Fixes #13835

Root Cause

When a control (e.g., MainObject) references another control (ExternalObject) from a separate assembly (ExternalAsm), and that assembly is missing at runtime, the constructor of MainObject fails. However, the .NET runtime still attempts to call Dispose() on the partially constructed control. Inside Control.Dispose, accessing ContextMenuStrip triggers a NullReferenceException because Properties is not initialized.

Proposed changes

• Added a defensive null check around ContextMenuStrip access in Control.Dispose()
• Replaced direct property access with Properties?.TryGetValue(...) to ensure safe event unsubscription

Customer Impact

• This change ensures that Control.Dispose() can safely execute even when the control was never fully constructed.

Regression?

• Yes

Risk

• Minimal

Screenshots

Before

Run the attached project net10Issue.zip using .NET 10 framework, crash with Exception thrown: 'System.NullReferenceException' in System.Windows.Forms.dll

BeforeChanges.mp4

After

App exits successfully.

AfterChanges.mp4

Test methodology

• Manually

Test environment(s)

• .net 10.0.0-rc.1.25420.121

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull Request Overview

This PR fixes a NullReferenceException crash that occurs when Control.Dispose() is called on a partially constructed control that failed to load due to a missing assembly dependency. The fix adds defensive null checks to prevent accessing uninitialized properties during disposal.

• Adds null-safe property access in Control.Dispose() method
• Replaces direct ContextMenuStrip property access with safe Properties?.TryGetValue() pattern
• Ensures disposal can complete successfully even for incompletely constructed controls

[codecov]

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.14106%. Comparing base (6bce8b5) to head (bfdb352).
⚠️ Report is 23 commits behind head on main.

Additional details and impacted files

@@                 Coverage Diff                 @@
##                main      #13840         +/-   ##
===================================================
+ Coverage   77.10742%   77.14106%   +0.03363%     
===================================================
  Files           3273        3273                 
  Lines         644925      644925                 
  Branches       47692       47693          +1     
===================================================
+ Hits          497285      497502        +217     
+ Misses        143967      143745        -222     
- Partials        3673        3678          +5     

Flag	Coverage Δ
Debug	77.14106% <0.00000%> (+0.03363%)	⬆️
integration	19.05722% <0.00000%> (+0.06652%)	⬆️
production	52.00310% <0.00000%> (+0.07537%)	⬆️
test	97.41248% <ø> (ø)
unit	49.34284% <0.00000%> (+0.00313%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ricardobossan]

All LGTM. I explored writing a unit test that would reproduce the difference with and without this change, but I couldn’t find a reliable way to simulate the exact scenario. This fix mainly strengthens null-safety, so I think manual verification is sufficient. The change looks low-risk to merge.

[Epica3055]

looks good👍

[KlausLoeffelmann]

It looks good to me.

Do we have telemetry, how often this happened, or was it a customer report?

[LeafShi1]

Do we have telemetry, how often this happened, or was it a customer report?

Yes, it's customer-reported, and this is the only feedback we've received so far.

[LeafShi1]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0 (link to workflow run)