Follow-up to #340: tighten workspace-to-complog support

[slang25]

Hi @jaredpar — this is a continuation of #340 (which I've been reviewing). The original PR landed the core of CompilerLogUtil.CreateFromWorkspace / CompilerLogBuilder.AddFromWorkspace; this builds on top of it with a few tweaks I think are worth folding in before merging.

What's in here

• Non-throwing variant. Adds TryCreateFromWorkspace returning CreateFromWorkspaceResult { Succeeded, CompilerCalls, Diagnostics }. The throwing CreateFromWorkspace is kept and now layers on top of it. AddFromWorkspace returns the synthesized CompilerCall (or null on failure) so callers can correlate diagnostics with projects.
• TargetFramework recovery. MSBuildWorkspace names multi-targeted projects AssemblyName(tfm), so we parse that first; falls back to the parent directory of OutputFilePath for default-layout SDK projects (best-effort — artifacts/ layouts give {config}_{tfm} and won't round-trip cleanly).
• Source-generated documents. project.GetSourceGeneratedDocumentsAsync results are now serialized as RawContentKind.GeneratedText and IncludesGeneratedText = true, so the reader uses the captured generator output rather than re-running generators against possibly-different analyzer versions.
• Project references via the Solution. Switched from CompilationReference to walking project.ProjectReferences and resolving through parentProject.Solution.GetProject(...). Prefers the dep's on-disk OutputFilePath (which matches the consumer's TFM) and only emits the in-memory Compilation when nothing is on disk.
• Crypto key file. When compilation.Options.CryptoKeyFile is set and resolves to a real file (relative to the project directory if not rooted), it gets captured as RawContentKind.CryptoKeyFile.
• Smaller polish. ChecksumAlgorithm taken from the first document's SourceText rather than hardcoded SHA-256; ParseOptions read from project.ParseOptions (the authoritative source) rather than from a syntax tree; .vbproj extension fallback for VB projects with no FilePath; cancellation propagated through TryCreateFromWorkspace; the analyzer-skip diagnostic now suggests reloading with BasicAnalyzerKind.OnDisk / None.
• Tests for round-trip, source-text preservation, project-reference handling, the file-path overload, on-disk analyzer references, generated-text round-trip, cancellation, and a regression lock that the stored args stay empty.

What I tried and backed out

I initially added a WorkspaceCommandLineSynthesizer that reconstructed a csc/vbc-style rsp from compilation.Options + project.MetadataReferences + analyzers (you can see it at b5161e0). The intent was to give complog rsp / replay / export something to work with for workspace-derived complogs.

I hadn't realised that the Roslyn workspace API genuinely doesn't surface emit-time inputs — embedded resources, Win32 manifest/icon/resource, source link, app.config, etc. live on Compilation.Emit() parameters and are supplied by the host (MSBuild), not on Project. So a synthesized rsp would always quietly drop those inputs and produce a binary that compiles but isn't faithful. That's worse than failing loudly, so I removed the synthesizer in 250bd2e and left the stored args empty — replay/rsp/export will fail visibly on workspace-derived complogs, which is the honest behaviour. There's a test that locks in the empty-args invariant.

If you'd rather take the original synthesizer-included version and document the partial fidelity instead, happy to revert that second commit.

Update: merged main in (clean, just a using clash) and pushed a few more fixes from another review pass over the branch:

• The emitted project-reference cache is now keyed by ProjectId rather than "{AssemblyName}.dll" — assembly names aren't unique across a workspace (each TargetFramework flavour of a multi-targeted project shares one), so the old key could hand one flavour's PE bytes to the other flavour's consumer. There's a regression test locking this in.
• The serialization core is now properly async (AddFromWorkspaceAsync awaits GetCompilationAsync/GetTextAsync instead of .GetAwaiter().GetResult()), with CreateFromWorkspaceAsync/TryCreateFromWorkspaceAsync exposed and the sync overloads kept as thin wrappers. If that's more public surface than you'd like, happy to trim to just one set — no strong opinion here from me.
• AddAssembly and the emitted-assembly path now share the zip entry write, ironing out some duplicated logic.
• The project-reference test no longer depends on the fixture's shape (it used to quietly skip when there were no P2P refs) — it now builds AdhocWorkspace projects directly, exercises the in-memory emit path, and asserts the consumer re-compiles without errors using only what's stored in the log.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 93.25843% with 30 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.74%. Comparing base (88e9f1b) to head (7dc5c9c).

Files with missing lines	Patch %	Lines
src/Basic.CompilerLog.Util/CompilerLogBuilder.cs	88.14%	10 Missing and 6 partials ⚠️
...ompilerLog.Util/WorkspaceCommandLineSynthesizer.cs	93.51%	2 Missing and 12 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #352      +/-   ##
==========================================
- Coverage   95.97%   95.74%   -0.24%     
==========================================
  Files          54       56       +2     
  Lines        6163     6601     +438     
  Branches      709      779      +70     
==========================================
+ Hits         5915     6320     +405     
- Misses        130      147      +17     
- Partials      118      134      +16     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[slang25]

@jaredpar what do you think to this feature btw? I'm using this branch at work, and so far it's working for my purposes.

[jaredpar]

On one hand I think this PR is on the right track if we're going to support creating from a Workspace. Found a few issues in the PR (see comments) but largely the code is going the right direction.

On the other hand, the lack of fidelity for Workspace is a concerning. You identified that we don't have Emit data and that means it won't be as accurate as a log created from a binary log. To take this we'd need to be onboard with that. Been thinking about that and I think i'm comfortable with it so long as we can get replay / export working. Yes they won't be as high fidelity but it should still be good enough for us to put into the workflows where we consume compiler logs today.

[jaredpar]

Sorry, also meant to say in my review thank you for the work and effort you've put into this so far 😄

[jaredpar]

Thanks for the contribution!