[Vsintegration] Show project references of SDK style projects in the Dependencies node

[hpetriffer]

The Projects node under Dependencies stayed empty when a solution with SDK style X# projects was opened. It only showed up after adding a project reference through the dialog, and was gone again after the next reload.

Root cause

No ProjectReferenceNode was created at all:

1. XSharpSdkProjectNode.Clean() strips the Project (guid) and Name metadata from every ProjectReference item before saving, so a saved .xsproj correctly only contains <ProjectReference Include="..\Foo\Foo.xsproj" />.
2. XSharpReferenceContainerNode.CreateProjectReferenceNode() resolved guid and name for the SDK case — and then dropped both on the floor. Nothing was written to the project element.
3. The ProjectReferenceNode(ProjectNode, ProjectElement) constructor deliberately skips the "invent a random guid" fallback for SDK projects, and then called new Guid(guidString) on an empty string inside a try/finally with no catch → FormatException.
4. ReferenceContainerNode.CreateReferenceNode() swallows that exception (a Debug.WriteLine only when a debugger is attached) and returns null.
5. The Projects folder is created lazily, on the first XSharpProjectReferenceNode that is added — so the whole folder was missing, not just the reference.

Adding a reference interactively goes through the other constructor, which parses the guid out of the bstrProjRef string, which is why that path worked.

FixReferences(), the mechanism meant to complete these references once the solution has finished loading, had nothing left to iterate over. It was broken on its own as well: when the referenced project was found (refnode != null) it never assigned refnodeGuid, so it always reported failure.

Changes

• XSharpReferenceContainerNode — the SDK branch now stores the resolved guid and name on the in-memory project element, and resolves foreign / not-yet-loaded projects via ProjectInfo / GetProjectGuid, the same way FixReferences() does. Clean() still keeps them out of the saved project file. Node creation is wrapped in try/catch + Logger.Exception, consistent with the sibling Create*Node methods, so a failure can never silently drop a reference again.
• ProjectReferenceNode — tolerate a missing or malformed guid: the node is created with Guid.Empty and without a build dependency instead of throwing, so it always appears in the hierarchy. Added UpdateReferencedProjectGuid() to attach the guid and the build dependency later and redraw the icon.
• XSharpProjectNode.FixReferences() — use refnode.ProjectIDGuid when the referenced project is one of ours; resolve per node instead of skipping the remaining nodes after the first failure; push the resolved guid into the node; log what stayed unresolved.
• ProjectNode.BuildDependencies — do not register a ProjectInfo with an empty guid. It is cached by url and would block the later resolution of the real guid.
• XSharpShellEvents — also complete incomplete references on OnAfterBackgroundSolutionLoadComplete. With deferred solution load not all projects exist yet when OnAfterOpenSolution fires.

Notes for reviewers

• Behaviour for legacy (non-SDK) projects is unchanged: an empty guid still gets the random-guid fallback. The only difference there is that a malformed guid no longer throws away the node.
• The in-memory Project/Name metadata does not reach the project file: ProjectNode.Save() calls BeforeSave() → XSharpSdkProjectNode.Clean(), which removes it, and Save() restores it afterwards via RestoreProperties(). Reload() clears the dirty flag in its finally, so writing the metadata during ProcessReferences() does not leave the project dirty.
• ProjectPackage2022 builds clean. The VS2019 variant (ProjectPackage.csproj) does not build in my working tree, but that is pre-existing and unrelated — NuGet restore for net472 plus missing Community.VisualStudio.Toolkit types in Support.csproj/Logger.cs, files this PR does not touch.
• Not verified in the running IDE yet: worth a check that Dependencies → Projects is populated on load and that project build order is still correct.

🤖 Generated with Claude Code