docfx: The SDK 'Microsoft.NET.Sdk' specified could not be found.

Operating System: Windows DocFX Version Used: 2.42.2 Template used: statictoc with custom [Though not relevant as the error happens before templates come into play Steps to Reproduce:

Rundocfx in an automated build on APPVEYOR or GitHub Actions with only VS2019
Full APPVEYOR LOGS With Verbose DocFX output
1. The logs include dump of env vars, path var details, VS instance and MSbuild location and version. (None of which seems out of the ordinary in comparison to local builds that work…)

Expected Behavior: Should work same as it does locally the actual code files build and produce testatble binaries that pass all tests. Actual Behavior: Code builds fine, but DOCFX blows up with ‘The SDK ‘Microsoft.NET.Sdk’ specified could not be found.’ This is 100% repro on both GH Actions and AppVeyor, making it impossible to do automated build and update of docs.

Worse is that it logs “warnings” and doesn’t actually consider the issue to be a fail - even though it is a total fail for generating docs based on current source.

To leverage C#8 and SDK3 the Global.JSON was recently updated to

{
    "sdk": {
        "version": "3.1.100",
        "rollForward": "latestMajor"
    },
    "msbuild-sdks": {
        "Microsoft.Build.NoTargets": "1.0.53",
        "Microsoft.Build.CentralPackageVersions": "2.0.36"
    }
}

This is when DOCFX started to fall over, Somehow it’s internal MSBUILD is used in a way that it can’t correctly find the SDK.

This would appear to be related to multiple other issues closed as no repro, however this is a 100% repro case. [#5144, #4880, #4471] all of which were closed without a real resolution.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 7
Comments: 23 (11 by maintainers)

Most upvoted comments

I am still experiencing this issue on 2.59 as well as on 2.58. Getting:

[22-02-15 12:45:23.832]Warning:[MetadataCommand.ExtractMetadata](C:/EUVIC/acproject/backend-workflows/AboveCloud/src/AboveCloud.Workflows.Contracts/AboveCloud.Workflows.Contracts.csproj)Workspace failed with: [Failure] Msbuild failed when processing the file 'C:\EUVIC\acproject\backend-workflows\AboveCloud\src\AboveCloud.Workflows.Contracts\AboveCloud.Workflows.Contracts.csproj' with message: The SDK 'Microsoft.NET.Sdk' specified could not be found.  C:\EUVIC\acproject\backend-workflows\AboveCloud\src\AboveCloud.Workflows.Contracts\AboveCloud.Workflows.Contracts.csproj

Target framework of this project is net5.0 and my global.json is

{
  "projects": [ "src", "tools" ],
  "sdk": {
    "version": "5.0.404"
  }
}

My installed sdks:

3.1.201 [C:\Program Files\dotnet\sdk]
5.0.404 [C:\Program Files\dotnet\sdk]

Can we have it reopened or should I create separate thread?

FLAMESpl on Feb 15, 2022

Nuget is directly populated by the Github releases. That’s what I use.

From: Patrice Calvé @.> Sent: Friday, June 11, 2021 12:31 To: dotnet/docfx @.> Cc: jamiehankins @.>; Comment @.> Subject: Re: [dotnet/docfx] The SDK ‘Microsoft.NET.Sdk’ specified could not be found. (#5554)

Perfect !!! That did it. Chocolatey is still at 2.57.2 so I copied the latest release 2.58 from githubhttps://github.com/dotnet/docfx/releases/tag/v2.58 over the bits in my local choco path and it worked.

I noticed that the DocFx extension in Azure DevOps pipelines don’t use chocolatey but uses NuGet to fetch the latest nuget.exe install docfx.console

In the future, should I be using nuget’s docfx.console package or chocolatey’s docfx package ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/dotnet/docfx/issues/5554#issuecomment-859795409, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACVPN3JZFWYRUPN2RAMZYV3TSJQANANCNFSM4KZGMQNQ.

jamiehankins on Jun 11, 2021

Sadly, this issue remains. I have a different project that was updated to targeting netstandard2.1 and net5.0, an I continue to get this error. I’ve tried all manner of variations on the Global.json, but nothing works. This is yet another bug in docfx that’s not getting any attention or fix. Seems like docfx has gone dead from my view. The promised V3 has been in a development state ofr nearly 2 years now and we aren’t seeing much in the way of traction or resolution to the issues in the current release. I’ve lost count of the number of workarounds I’ve had to make for docfx bugs - and the one I found previously for this doesn’t work anymore in this case.

smaillet on Jan 19, 2021