docfx: MSBuild errors when generating metadata for SDK based net461 project and VS 2017 15.6
DocFX Version Used: 2.32.0
Template used: default with an additional custom css file
Steps to Reproduce:
- Checkout the repro project
The project usesnet461as target framework. - Have at least Visual Studio 2017 15.6 installed (same issue with 15.6 Preview 7.0)
- Run
powershell ./build.ps1 BuildDocFxMetadataat the solution root
Expected Behavior:
Generate no warnings.
Actual Behavior:
Unclear MSBuild warnings are present in the output:
> C:\Users\Georg\.nuget\packages\docfx.console\2.32.0\tools\docfx.exe metadata "D:\Visual Studio Projects\Nuke.WebDeploy\docfx.json" --logLevel Verbose
[18-03-06 04:54:21.659]Verbose:Config file "D:\Visual Studio Projects\Nuke.WebDeploy\docfx.json" is used.
[18-03-06 04:54:21.697]Info:[ExtractMetadata]Using msbuild E:\Visual Studio 2017\MSBuild\15.0\Bin as inner compiler.
[18-03-06 04:54:21.782]Info:[ExtractMetadata]Loading projects...
[18-03-06 04:54:21.782]Verbose:[ExtractMetadata](D:/Visual Studio Projects/Nuke.WebDeploy/src/Nuke.WebDeploy/Nuke.WebDeploy.csproj)Loading project...
[18-03-06 04:54:22.792]Warning:[ExtractMetadata](D:/Visual Studio Projects/Nuke.WebDeploy/src/Nuke.WebDeploy/Nuke.WebDeploy.csproj)Workspace failed with: [Failure] Msbuild failed when processing the file 'D:\Visual Studio Projects\Nuke.WebDeploy\src\Nuke.WebDeploy\Nuke.WebDeploy.csproj' with message: MSB0001: Internal MSBuild Error: Missing resource ''
[18-03-06 04:54:22.903]Verbose:[ExtractMetadata](D:/Visual Studio Projects/Nuke.WebDeploy/src/Nuke.WebDeploy/Nuke.WebDeploy.csproj)Project D:\Visual Studio Projects\Nuke.WebDeploy\src\Nuke.WebDeploy\Nuke.WebDeploy.csproj loaded.
[18-03-06 04:54:22.903]Warning:[ExtractMetadata]Project 'D:\Visual Studio Projects\Nuke.WebDeploy\src\Nuke.WebDeploy\Nuke.WebDeploy.csproj' does not contain any documents.
[18-03-06 04:54:22.903]Info:[ExtractMetadata]Generating metadata for each project...
[18-03-06 04:54:23.263]Verbose:[ExtractMetadata]Successfully generated metadata D:/Visual Studio Projects/Nuke.WebDeploy/src/Nuke.WebDeploy/obj/xdoc/cache/obj for Nuke.WebDeploy
[18-03-06 04:54:23.274]Verbose:[ExtractMetadata]Completed MergeMetadata in 1,9675 milliseconds.
[18-03-06 04:54:23.274]Verbose:[ExtractMetadata]Completed MergeReference in 0,7387 milliseconds.
[18-03-06 04:54:23.274]Warning:[ExtractMetadata]No metadata is generated for Nuke.WebDeploy.
[18-03-06 04:54:23.274]Info:Completed in 1598,5294 milliseconds
Build succeeded with warning.
[18-03-06 04:54:23.290]Warning:[ExtractMetadata](D:/Visual Studio Projects/Nuke.WebDeploy/src/Nuke.WebDeploy/Nuke.WebDeploy.csproj)Workspace failed with: [Failure] Msbuild failed when processing the file 'D:\Visual Studio Projects\Nuke.WebDeploy\src\Nuke.WebDeploy\Nuke.WebDeploy.csproj' with message: MSB0001: Internal MSBuild Error: Missing resource ''
[18-03-06 04:54:23.290]Warning:[ExtractMetadata]Project 'D:\Visual Studio Projects\Nuke.WebDeploy\src\Nuke.WebDeploy\Nuke.WebDeploy.csproj' does not contain any documents.
[18-03-06 04:54:23.290]Warning:[ExtractMetadata]No metadata is generated for Nuke.WebDeploy.
3 Warning(s)
0 Error(s)
The interesting bit is:
MSB0001: Internal MSBuild Error: Missing resource ''
That doesn’t say a lot about what is wrong and I was unable to find any cause for it.
Additional information
The metadata seems to be generated correctly, it puts files in the /api folder and the documentation looks correct: https://docs.dangl-it.com/Projects/Nuke.WebDeploy/1.0.1-beta0003/index.html
docfx.json specifies metadata.src.properties.TargetFramework as net461.
Manually invoking MSBuild.exe <path-to-csproj> compiles the app just fine, as does dotnet build with SDK 2.1.4 as well as the latest preview 2.1.300-preview1-008174.
The same happens for netstandard and netcoreapp projects, but here I can mitigate it by setting the MSBUILD_EXE_PATH to the one from the dotnet SDK:
// So it uses a fixed, known version of MsBuild to generate the metadata. Otherwise,
// updates of dotnet or Visual Studio could introduce incompatibilities and generation failures
var dotnetPath = Path.GetDirectoryName(ToolPathResolver.GetPathExecutable("dotnet.exe"));
var msBuildPath = Path.Combine(dotnetPath, "sdk", DocFxDotNetSdkVersion, "MSBuild.dll");
SetVariable("MSBUILD_EXE_PATH", msBuildPath);
The error does not happen on my build server, on which I have Visual Studio 2017 15.5.2 It logs that it uses MSBuild from the Visual Studio installation:
Info:[ExtractMetadata]Using msbuild C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin as inner compiler.
I noticed the same error already yesterday evening on another machine in another project after updating Visual Studio 2017 to 15.6.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 15 (7 by maintainers)
Commits related to this issue
- Temporary fix for docfx - Update to latest docfx; this doesn't solve the problem, but means we can assume that if the directory is there, the user has already run *this* version of the script. - ... — committed to jskeet/google-cloud-dotnet by jskeet 6 years ago
- Temporary fix for docfx - Update to latest docfx; this doesn't solve the problem, but means we can assume that if the directory is there, the user has already run *this* version of the script. - ... — committed to jskeet/google-cloud-dotnet by jskeet 6 years ago
- Temporary fix for docfx - Update to latest docfx; this doesn't solve the problem, but means we can assume that if the directory is there, the user has already run *this* version of the script. - ... — committed to jskeet/google-cloud-dotnet by jskeet 6 years ago
- Temporary fix for docfx - Update to latest docfx; this doesn't solve the problem, but means we can assume that if the directory is there, the user has already run *this* version of the script. - ... — committed to jskeet/google-cloud-dotnet by jskeet 6 years ago
- Temporary fix for docfx - Update to latest docfx; this doesn't solve the problem, but means we can assume that if the directory is there, the user has already run *this* version of the script. - ... — committed to googleapis/google-cloud-dotnet by jskeet 6 years ago
- Avoid shipping conflicting MSBuild version The Microsoft.Build.Locator package handles finding MSBuild. It will find the installed version, avoiding problems like #2491 that result from mismatched MS... — committed to rainersigwald/docfx by rainersigwald 6 years ago
For me the metadata is not generated at all. Try deleting obj folder/cache to force it to regenerate metadata from scratch. I couldnt get it to work at all.
Same MSBuild related errors after updating to VS 15.6
To piggyback on the workaround, for those on Mac using a recent version of Mono, you’ll need to copy
/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/Microsoft.Build.dllThis is indeed Microsoft/msbuild#2997, which results from a mismatch between the Microsoft.Build.dll version and VS.
You can get the effects of #2494 without waiting for a docfx release by copying the VS-delivered MSBuild assemblies into the docfx folder next to docfx.exe, overwriting what’s there. That worked for me against VS 15.6.1.
Having to update the MSBuild reference isn’t ideal and shouldn’t be required; that’s what MSBuildLocator is for. But it looks like Locator + Roslyn MSBuildWorkspace may not be a very happy pairing yet. We’ll need to track down and fix that, @andygerlicher.