Conversation
When a project doesn't place project.assets.json under <projDir>/obj/ (e.g. UseArtifactsOutput or projects like dotnet/fsharp with custom output layout), the fallback MSBuild --getProperty call may itself fail. Previously that failure was hard-coded to throw, making it impossible to use fsdocs on such repos. Following the maintainer suggestion from issue #592, change the fallback so that: - If MSBuild succeeds and reports an assets path that exists -> OK - If MSBuild succeeds but the assets file doesn't exist -> fail fast (project definitely not restored) - If MSBuild fails (e.g. old SDK, nonstandard project) -> warn and proceed, letting the cracking step produce the definitive error Closes #592 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
12 tasks
dsyme
approved these changes
Feb 26, 2026
nojaf
approved these changes
Feb 27, 2026
nojaf
deleted the
repo-assist/fix-issue-592-restore-check-c9128fafc71d4d70
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 This PR was created by Repo Assist, an automated AI assistant.
Fixes #592.
Root Cause
ensureProjectWasRestoredinProjectCracker.fschecks forproject.assets.jsonat the conventional(projDir)/obj/project.assets.jsonpath. If not found, it falls back todotnet msbuild --getProperty:ProjectAssetsFileto ask MSBuild for the real path. However, there were two bugs:try/withblock wrapped both the MSBuild call and the subsequentfailwithffor "not restored". So a "definitely not restored" error was caught and replaced with the less-informative "Failed to detect..." message.--getPropertysupport, or a non-standard project likedotnet/fsharpwith custom artifact output), it hard-failed instead of proceeding. This madefsdocsunusable on such projects, even if the project was actually restored.Fix
Restructure the detection to distinguish three cases:
This follows the maintainer's suggestion on the issue: "make that failure a warning and let it fail hard later".
Changes
src/fsdocs-tool/ProjectCracker.fs: refactorensureProjectWasRestoredto separate the "can't detect" case from the "definitely not restored" caseRELEASE_NOTES.md: add entry under### FixedTest Status
Build succeeded with
dotnet build src/fsdocs-tool/fsdocs-tool.fsproj --configuration Release(0 errors, 2 pre-existing vulnerability warnings unrelated to this change).This fix is behavioural and not easily covered by the existing unit-test suite (which doesn't test process-level restore detection). The change is safe: the only new behaviour is emitting a warning instead of throwing when MSBuild detection fails, so existing correctly-restored projects are unaffected.