docfx: After Visual Studio update - docfx does not work anymore :-(
Operating System: Windows 11 Pro
DocFX Version Used: docfx 2.59.1.0
Template used: statictoc
Steps to Reproduce:
Latest VS update (today) Microsoft Visual Studio Community 2022 (64-bit) - Version 17.2.6
docfx:
Build succeeded with warning.
[22-07-13 12:35:02.625]Warning:MetadataCommand.ExtractMetadataWorkspace failed with: [Failure] Msbuild failed when processing the file ‘C:\Users\cohle\Desktop\RationalNumerics\System.Numerics.Rational\System.Numerics.Rational.csproj’ with message: Methode nicht gefunden: “System.ReadOnlySpan1<Char> Microsoft.IO.Path.GetFileName(System.ReadOnlySpan1<Char>)”.
[22-07-13 12:35:02.628]Warning:[MetadataCommand.ExtractMetadata]Project ‘C:\Users\cohle\Desktop\RationalNumerics\System.Numerics.Rational\System.Numerics.Rational.csproj’ does not contain any documents.
[22-07-13 12:35:02.629]Warning:[MetadataCommand.ExtractMetadata]No metadata is generated for System.Numerics.Rational.
3 Warning(s)
0 Error(s)
For project - URL: https://github.com/c-ohle/RationalNumerics
Any quick workaround?
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 3
- Comments: 46 (2 by maintainers)
Commits related to this issue
- Temporarly disable DocFx build on Windows See https://github.com/dotnet/docfx/issues/8097 See #119 — committed to mawosoft/Mawosoft.Extensions.BenchmarkDotNet by mawosoft 2 years ago
- Upgrade to BenchmarkDotNet 0.13.2 (#118) * Upgrade to BenchmarkDotNet 0.13.2 - Bump BDN dependency to 0.13.2 and remove transitive pinning for System.Management. - Bump SDK version to 6.0.400 in gl... — committed to mawosoft/Mawosoft.Extensions.BenchmarkDotNet by mawosoft 2 years ago
- appveyor.yml: temporarily revert VS image to resolve DocFx issue [https://github.com/dotnet/docfx/issues/8097] — committed to Sholtee/primitives by Sholtee 2 years ago
- appveyor.yml: temporarily revert VS image to resolve DocFx issue [https://github.com/dotnet/docfx/issues/8097] — committed to Sholtee/proxygen by Sholtee 2 years ago
- appveyor.yml: temporarily revert VS image to resolve DocFx issue [https://github.com/dotnet/docfx/issues/8097] — committed to Sholtee/ormlite.extensions by Sholtee 2 years ago
- appveyor.yml: temporarily revert VS image to resolve DocFx issue [https://github.com/dotnet/docfx/issues/8097] — committed to Sholtee/injector by Sholtee 2 years ago
- Revert visual studio version Fix for https://github.com/dotnet/docfx/issues/8097 — committed to bonsai-rx/docs by glopesdev 2 years ago
- Fix DocFX not rendering the API We face the issue from https://github.com/dotnet/docfx/issues/8097. We fix it with [this hacky fix]. [this hacky fix]: https://github.com/dotnet/docfx/issues/8097#iss... — committed to aas-core-works/aas-core3.0rc02-csharp by mristin 2 years ago
- Fix DocFX not rendering the API We face the issue from https://github.com/dotnet/docfx/issues/8097. We fix it with [this hacky fix]. [this hacky fix]: https://github.com/dotnet/docfx/issues/8097#iss... — committed to aas-core-works/aas-core3.0rc02-csharp by mristin 2 years ago
- Fix DocFX not rendering the API We face the issue from https://github.com/dotnet/docfx/issues/8097. We fix it with [this hacky fix]. [this hacky fix]: https://github.com/dotnet/docfx/issues/8097#iss... — committed to aas-core-works/aas-core3.0rc02-csharp by mristin 2 years ago
- Fix DocFX not rendering the API We face the issue from https://github.com/dotnet/docfx/issues/8097. We fix it by downgrading to windows-2019 image in the CI, since that image contains VisualStudio 20... — committed to aas-core-works/aas-core3.0rc02-csharp by mristin 2 years ago
- Fix DocFX not rendering the API (#63) We face the issue from https://github.com/dotnet/docfx/issues/8097. We fix it by downgrading to windows-2019 image in the CI, since that image contains VisualS... — committed to aas-core-works/aas-core3.0rc02-csharp by mristin 2 years ago
FWIW, while this work around works, it runs MUCH slower.
I don’t think this issue should be closed until VS fixes the underlying issue that broke it!
Here’s the root issue: https://github.com/dotnet/msbuild/issues/7832
The workaround of using the
.dllfiles instead of the.csprojfiles gives a worse user experience for me than just holding our build server’s version of Visual Studio Build Tools back at 17.2, which is obviously not a viable long-term solution, so I also would appreciate keeping an issue open for this.For example, using
.csprojfiles, it correctly identifies structs as structs (after finding a better workaround for #8120, anyway), but when using the.dllfiles, it seems to call them classes that just so happen to inherit fromValueType. I haven’t gone further than that to see if there’s anything else that the.dllversion gets “wrong” that the.csprojversion gets “right”.@superyyrrzz ,
In https://github.com/dotnet/docfx/pull/8135, it was asserted this is fixed in VS2022 17.3.1 (not preview)
I can reproduce the issue on
This issue should not be closed.
I think he root-cause is this MSBuild bug: https://github.com/dotnet/msbuild/issues/7832
This fix works fine Thanks you! That saved me 😅
Our changes: here
Hope microsoft still fixes it tho.
@vers-one thanks for the other method, didn’t test tho because the first one is easier for me
This workaround proposed by jskeet works even with
windows-latestfor me.@asklar After updating my
docfx.consolereference to 2.59.4, I can confirm that the issue is completely resolved for me.With GitHub’s CI images, I only had the problem with
windows-latest, the DocFx builds run fine for me onubuntu-latestandmacos-latest.docfx.console 2.59.3in a NoTargets project.Successful CI run with docfx build on Windows disabled: https://github.com/mawosoft/Mawosoft.Extensions.BenchmarkDotNet/actions/runs/2944501729
This issue has caused my GH Action to error out, but only on one of my projects. Is there a work around other than “ship the dll” because I dont want my documentation workflow to have to borrow actions from my release.
FYI, we have the same exception, that started appearing with 17.3 Preview 3 in Uno, possibly in our Source Generators, for users that had LangVersion forced at 8.0 in their project: https://github.com/unoplatform/uno/issues/9297
Great, it works, (After delete the cache of course 😃 )
Having the same issues with other tooling (not docfx). I suspect that it is something that changed in MSBuild (I do have preview installed, but it also happens to the stable versions).
Maybe the SDK version that shipped last Patch Tuesday?
Morning, it seems to be a Microsoft issue. I debugged docfx (unchanged). As you can see, it crashes in Microsoft.Build and has nothing to do with docfx or wrong pathes. Maybe it would help to upgrade the packages, but I know, the dependencies, new conflicts etc. Maybe it’s because I also have the latest VS2022 preview installed for .NET7 development. But before this was never a problem together with docfx, it started after the last official VS2022 community update. I’ll do some more debugging, if I find a solution I will let you know.