Fix Visual Studio deadlock caused by restore target calls in BeforeResolveReferences

[Copilot]

This PR fixes a critical deadlock issue in Visual Studio when building React Native Windows C++ projects. The problem occurred when MSBuild targets called the Restore target during the BeforeResolveReferences phase of Visual Studio builds.

Problem

The BeforeResolveReferences target in both Microsoft.ReactNative.Common.targets and vnext/Directory.Build.targets was calling the NuGet Restore target when BuildingInsideVisualStudio was true. This caused several issues:

1. Deadlocks: The restore task accesses UI thread-bound components without proper Joint Task Factory (JTF) synchronization, leading to Visual Studio deadlocks
2. Contract violation: Restore and build have a contract where restore must complete before build starts - calling restore during build violates this contract
3. Performance issues: Network calls during restore on the UI thread cause delays and potential hangs

Solution

Removed the problematic BeforeResolveReferences targets that were calling MSBuild tasks with Targets="Restore". Visual Studio has its own built-in NuGet package restoration mechanisms that handle this properly without the deadlock risk.

The fix includes:

• Complete removal of BeforeResolveReferences targets from both affected files
• Added comprehensive comments explaining why the restore calls were problematic
• Preserved all other MSBuild functionality including validation targets and NuGet configuration

Files Changed

• vnext/PropertySheets/External/Microsoft.ReactNative.Common.targets
• vnext/Directory.Build.targets

Both files had identical problematic patterns that have been resolved.

Fixes #15108.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

Microsoft Reviewers: Open in CodeFlow

[JunielKatarn]

The "problematic" target served a purpose: allowing developers to fully build (and fetch C++ dependencies) from within Visual Studio.

If there is no way around dropping this target, documentation should also be updated including a workaround to restore dependencies outside the IDE.

[JunielKatarn]

Can you please confirm this actually happens and the target's removal is fully transparent to the user?

[vmoroz]

@JunielKatarn , lately I see the deadlock in my Visual Studio too often. It is a huge waste of time.
I wonder if we can restore Nuget packages as a part of "yarn build" step.
Currently we do a lot of other work in that phase such as copying code files around and doing the node_modules overrides.
Adding the Nuget restoration would be just another step.

[JunielKatarn]

@JunielKatarn , lately I see the deadlock in my Visual Studio too often. It is a huge waste of time. I wonder if we can restore Nuget packages as a part of "yarn build" step. Currently we do a lot of work other in that phase such as copying code files around and doing the node_modules overrides. Adding the Nuget restoration would be just another step.

What you suggest should be doable.
For now, you can run msbuild /t:Restore [/p:Platform=<target platform> /p:Configuration=<target configuration>] after the initial yarn call.

Regarding the deadlock, this PR should address that (making my suggestion above mandatory), but I don't own this work item and don't know its status.