docfx: Not working with .NET core .csproj files with Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props not found error

set VisualStudioVersion=15.0
set VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\

These two environment variables appear to resolve this issue - at least I get no more warnings in the output.

Hi @dealdiane , according to Microsoft/msbuild#1697 . there is a gap between msbuild tool and .NET core SDK build, so you have to install Visual Studio 2017 (not Build Tools but the full VS) on your build server as current workaround…

Based on your guys comments and a bit of digging around. I created a Power Shell script to get Visual Studio’s install path, use a specified .Net core SDK, and then set up environment variables before invoking docfx for a .Net Core solution.

powershell .\docfx.ps1 docfx.json --serve

# docfx.ps1
$docfxVersion = "2.24.0"
$VisualStudioVersion = "15.0";
$DotnetSDKVersion = "2.0.0";

# Get dotnet paths
$MSBuildExtensionsPath = "C:\Program Files\dotnet\sdk\" + $DotnetSDKVersion;
$MSBuildSDKsPath = $MSBuildExtensionsPath + "\SDKs";

# Get Visual Studio install path
$VSINSTALLDIR =  $(Get-ItemProperty "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7").$VisualStudioVersion;

# Add Visual Studio environment variables
$env:VisualStudioVersion = $VisualStudioVersion;
$env:VSINSTALLDIR = $VSINSTALLDIR;

# Add dotnet environment variables
$env:MSBuildExtensionsPath = $MSBuildExtensionsPath;
$env:MSBuildSDKsPath = $MSBuildSDKsPath;

# Build our docs
& .\docfx.console.$docfxVersion\tools\docfx @args

It’s a little hacky, but it works.

Edit: This has been tested on AppVeyor and works really well. Here is my build script that’s invoked from appveyor.yml:

build_script:
 - ps: ./docs/build.ps1 -Deploy

https://github.com/NZSmartie/CoAP.Net/blob/docs/docs/build.ps1

Could we get a summary of the appropriate hack to be using here? I’ve followed a couple of tips above, but they aren’t actually working (as others have already replied).

Unless I’m missing something, this is a pretty fundamental scenario that isn’t working. I’m not trying to do anything unusual, I just have a bog standard netstandard2.0 library that I added to a blank “docfx init” project…

@rschili Is it an option for you to point docfx at your compiled binaries? To avoid touching any environment variables as above I settled with that solution - as part of the build, I get docfx to generate metadata for the debug binaries in bin. A bit more concise than looking at source files.

So, there is a pretty good understanding now, what the issue is, but there is no good workaround, yet. Just like @jskeet I cannot put dll.config files into Program Files on a build machine, I do not have access to that folder. Visual Studio is also not installed on those machines, just the NET Core SDK.

Currently I am avoiding the issue by not including the csproj as metadata, but all *.cs files instead. Which is a very limited solution.

Is there an idea of how a non-workaround solution would look like?

Hi @alanedwardes, if it is netcore project, workaround https://github.com/dotnet/docfx/issues/1752#issuecomment-308909959 should work, no need to install VS.

Hi, has there been any progress on this issue? I’d like to avoid having to install Visual Studio on the build slave.

Hi @jskeet I doubt the issue is related to https://docs.microsoft.com/en-us/visualstudio/msbuild/what-s-new-in-msbuild-15-0 that toolsversion is no longer in registry key. Try the following workaround

1. set MSBUILD_EXE_PATH=C:\Program Files\dotnet\sdk\2.0.0\MSBuild.dll
2. Copy attached txt to the same folder as MSBuild.dll and rename it to MSBuild.dll.config, this is the msbuild.exe.config file I copied from a machine with VS2017 installed in which defines msbuildToolsets MSBuild.dll.config.txt

It works in my clean machine with only netcore 2.0 installed, please have a try

I should note that I don’t have any problem with the new *.csproj file format if I have VS2017 installed on the same machine. It only appears to be a problem when on a machine with just the .NET Core tools installed.