[Repo Assist] Update Ionide.ProjInfo to 0.74.2, fix URI format exception

[github-actions]

🤖 This PR was created by Repo Assist, an automated AI assistant.

Closes #1054

What Changed

• Updated Ionide.ProjInfo 0.62.0 → 0.74.2 in Directory.Packages.props
• Removed Ionide.ProjInfo.Sln package — its functionality was merged into the main Ionide.ProjInfo package at v0.70.0; no separate package exists for v0.70.0+
• Migrated ProjectCracker.fs to the new WorkspaceLoader API:
  • Replaced the removed ProjectLoader.getProjectInfo call with WorkspaceLoader.Create(toolsPath, extraMsbuildProperties) + loader.LoadProjects([projectFile], customProperties, BinaryLogGeneration.Off)
  • Subscribe to loader.Notifications for WorkspaceProjectState.Failed to capture error messages
• Fixed InspectSln.tryParseSln pattern: changed Ok(_, slnData) → Ok slnData — the return type changed from Result(unit * SolutionData, exn) to Result(SolutionData, exn) in v0.74.x

Root Cause

The VisualTree.relativePathOf URI format exception (reported in #1054) was triggered by a code path in older Ionide.ProjInfo versions that handled file URIs. The v0.74.2 release fixes this upstream. This PR upgrades to that version and adapts the API calls accordingly.

Trade-offs

• The new WorkspaceLoader API loads the project and reports errors asynchronously via Notifications. Errors are captured in a ConcurrentQueue before being matched against the existing CrackErrors type — no behaviour change for callers.
• Ionide.ProjInfo.Sln provided solution-file parsing utilities; since these were merged into Ionide.ProjInfo itself, removing the separate package reference has no functional impact.

Test Status

✅ dotnet build FSharp.Formatting.sln --configuration Release — succeeded, 0 warnings, 0 errors
✅ dotnet test FSharp.Formatting.sln --configuration Release --no-build — 76 passed, 0 failed, 4 skipped
✅ dotnet fantomas src/fsdocs-tool/ProjectCracker.fs — file already correctly formatted (unchanged)

Generated by Repo Assist for issue #1054

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@afb00b92a9514fee9a14c583f059a03d05738f70

[Smaug123]

(Consider #1055 instead, which uses the helper function from proj-info. Or don't; I don't mind!)

[dsyme]

@Smaug123 Trying to understand why your onw required the MSBuild package reference and this one doesn't seem to need to

[dsyme]

/repo-assist Please take a close look at #1055 which uses the helper function from proj-info and see if you can fold that in. Also analyze if/why the MSBuild reference was necessary in that PR and if there's something missing from your PR or maybe it doesn't much matter either way. Report back here with a comment or update this PR if you're really sure.

[github-actions]

Commit pushed: 1a2fef2

Generated by Repo Assist

[github-actions]

🤖 This is an automated response from Repo Assist.

I've updated this PR to fold in PR #1055's approach. Here's the analysis:

Why PR #1055 needed the Microsoft.Build package reference

PR #1055 directly instantiates Microsoft.Build.Evaluation.ProjectCollection:

let projectCollection = new Microsoft.Build.Evaluation.ProjectCollection(dict extraMsbuildProperties)

Since ProjectCollection is a type from Microsoft.Build.dll, it needs an explicit compile-time reference. The IncludeAssets="compile" ExcludeAssets="runtime" PrivateAssets="all" attributes mean:

• IncludeAssets="compile" — the assembly is available at compile time (type checking)
• ExcludeAssets="runtime" — don't bundle it in the output; the .NET SDK already provides MSBuild assemblies at runtime
• PrivateAssets="all" — don't flow this dependency to consumers of this package

The previous WorkspaceLoader approach abstracted ProjectCollection away behind its API, so no direct Microsoft.Build reference was needed. But using ProjectLoader.loadProject + ProjectLoader.getLoadedProjectInfo (the lower-level helpers) brings ProjectCollection back into user code.

Was something missing from this PR?

Not functionally — the WorkspaceLoader approach worked correctly. But it was more complex (async notification subscription, error collection from a separate channel). The ProjectLoader helper functions are cleaner and more direct.

What I changed

Replaced the WorkspaceLoader.Create + Notifications.Subscribe + LoadProjects block with ProjectLoader.loadProject + ProjectLoader.getLoadedProjectInfo, matching PR #1055's approach. Also added the Microsoft.Build reference to fsdocs-tool.fsproj.

Build and tests: ✅ Build succeeded (0 errors), 76 passed / 0 failed / 4 skipped. Fantomas formatting check passed.

Note: there's a pre-existing NU1604 warning about Microsoft.Build's empty Version="" — this is the same pattern already used for the other Microsoft.Build.* packages in Directory.Packages.props and is harmless.

Generated by Repo Assist for issue #1056

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@afb00b92a9514fee9a14c583f059a03d05738f70

[TheAngryByrd]

I think we should log at info/debug and ignore if something isn't a standard project. So this could become Ok None, and fix up the filtering.

[TheAngryByrd]

Looks like we already have a "skipping" mechanism, so maybe just verify this doesn't stop processing other project.

[TheAngryByrd]

cracking projects...
  skipping project 'FSharp.CodeFormat.Tests.fsproj' because an error occurred while cracking it: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Build, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.

File name: 'Microsoft.Build, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at fsdocs.Crack.crackProjectFileAndIncludeTargetFrameworks[a](a _slnDir, IEnumerable`1 extraMsbuildProperties, String projectFile) in /home/runner/work/FSharp.Formatting/FSharp.Formatting/src/fsdocs-tool/ProjectCracker.fs:line 250
   at fsdocs.Crack.crackProjectFile[a](a slnDir, FSharpList`1 extraMsbuildProperties, String file) in /home/runner/work/FSharp.Formatting/FSharp.Formatting/src/fsdocs-tool/ProjectCracker.fs:line 411
   at fsdocs.Crack.projectInfos@509.Invoke(String p) in /home/runner/work/FSharp.Formatting/FSharp.Formatting/src/fsdocs-tool/ProjectCracker.fs:line 511
Project cracking failed and --strict is on, exiting
Exit code is not indicating as successful.

This might require a @baronfel response

[dsyme]

@TheAngryByrd From the analysis above it looks like it may be better for us to continue to use WorkspaceLoader and avoid the MSBuild dependency, what do you think?

[TheAngryByrd]

Yeah I agree, the WorkspaceLoader is the interface to use.