This is on latest main:
VisualFSharp.sln:
Determining projects to restore...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(130,5): error : Invalid restore input. Invalid target framework 'unsupported'. Input files: C:\Users\phcart\.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj. [C:\Users
\phcart\.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj]
Build FAILED.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(130,5): error : Invalid restore input. Invalid target framework 'unsupported'. Input files: C:\Users\phcart\.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj. [C:\Users
\phcart\.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.28
Build failed.
cc @brettfo @KevinRansom
Oh I remember now, you are using a dogfood vs command window. It works with the rtm command window.
No, I'm just using the windows terminal
Update - it now just throws an NRE if I use the VS command prompt to build. Something is horribly wrong right now, it is impossible to build this repo.
Same issue for me when building netfx, builds fine for netcore though.
i.e.
.\Build.cmd -noVisualStudio -testCoreClr - ci -bl -c Release -msbuildEngine dotnet
works for me.
And the weird thing is that it builds just fine in CI.
What branch are you guys using? I'm on main and only one commit behind, which builds fine from the commandprompt (I have failing tests, but it builds). The next commit was the "yeet mono folder" commit, maybe that wreaked havoc?
@KevinRansom mentioned he was on latest and not having issues. So it's another one of those lovely problems.
I'm on main + latest tooling on windows, and have it failing unless building with command above.
I will spend the day figuring out why it fails for you guys. I think it's due to an arcade update. That's the usual reason anyway.
@vzarytovskii / @cartermp , I am pretty confident this is a bug in the nuget package shipped with the dogfood VS preview build.
I can reproduce the build failure by building with the dogfood vs command shell. If i replace the nuget vsix in that build with the files shipped with 16.7.2 then our build works fine.
Our build has a dependency on the msbuild installed with VS, which is disapointing, but I suppose inevitable.
The thing is I don't have a simple repro, and I can't describe the bug to the nuget folks. But we should hook up with them and make sure they investigate.
Kevin
I'm on main + latest tooling on windows, and have it failing unless building with command above.
I just updated everything and using build.cmd works, as does building/debugging in VS RTM for VisualFSharp.sln.
Nonetheless, I find @KevinRansom's remark about the MSBuild version of NuGet interesting, since we've been discussion and investigating why certain tests fail on my system. I just found out that NuGet from PM works, but the NuGet used in #r "nuget: ..." doesn't, the latter _also_ using the MSBuild NuGet task: Nuget.Build.Tasks.dll.
This is probably not directly related (I would figure you'd see different errors), but I reported the issues with NuGet here: https://github.com/NuGet/NuGetGallery/issues/8176, which seem to require Windows + VS + NetFX to fail, and this failure is highly dependent on which update of VS you've installed (VS installer resets the TLS/SSL settings to TLS 1.3, which fails with NuGet).
On my system, this is version 5.7.0.7.
Forget that, it doesn't repro, once I fixed the nuget stuff, it just works.
Eh, @dsyme, that "it doesn't repro" was about my own prev. comment, the issue by @cartermp I assume is still very much unresolved? Sorry for confusing matters.
I'm not using the dogfood VS command shell though. Perhaps it's just more global msbuild crap making this a nightmare. Note that if I built using the 16.7.2 command shell to force that MSBuild to be used, I got an NRE during build and could still not build the repo. I will re-open this until that is confirmed to also not be a problem.
More by luck (if you can call it that) than anything else I've been able to repro this, and to workaround this:
build.cmd: errorbuild.cmd: successLooking more closely at the error it appears to me that some env variable is supposed to be set and causes something else to default to unsupported. Apparently this is a variable that's set when you open a Developer Command prompt and absent otherwise.
I got an NRE during build and could still not build the repo.
That doesn't happen for me, I assume you did a git clean -xdf after the failed builds?
This is the error I see from a normal command prompt, which appears to be the same as for @cartermp:
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:02:29.49
VisualFSharp.sln:
Determining projects to restore...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(128,5): error : Invalid restore input. Invalid target framework 'unsupported'. Input files: C:\Users\Abel\.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj. [C:\Users\Abel\.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj]
Build FAILED.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(128,5): error : Invalid restore input. Invalid target framework 'unsupported'. Input files: C:\Users\Abel\.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj. [C:\Users\Abel\.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj]
0 Warning(s)
1 Error(s)
@abelbraaksma , what vs do you have installed?
Lol, it's a preview ... I am pretty sure this is a bug in the lates preview release of nuget.
@KevinRansom: The Developer Command Prompt was:
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.7.2
** Copyright (c) 2020 Microsoft Corporation
**********************************************************************
Let me try the Preview command prompt as well
Ok, preview command prompt was:
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.8.0-pre.2.0
** Copyright (c) 2020 Microsoft Corporation
**********************************************************************
and fails like the "normal" non-dev command prompt with the same errors as @cartermp has.
Check out the error you posted, you will see it was a preview build.:
````
Build FAILED.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(128,5): error : Invalid restore input. Invalid target framework 'unsupported'. Input files: C:\Users\Abel.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj. [C:\Users\Abel.nuget\packages\microsoft.dotnet.arcade.sdk\5.0.0-beta.20407.3\tools\Tools.proj]
````
this is a bug in the lates preview release of nuget.
That would explain a lot.
you will see it was a preview build.:
I did notice the 5.0.0 in there and the arcade.sdk, but since I opened a "normal" command prompt I figured this was set by the build script. I wasn't aware the preview installation screws with my "normal" settings.
So we now have:
(which backs your assumption that something broke in NuGet in Preview)
@abelbraaksma, it doesn't they install side by side. I have a preview and an rtm installed all of the time, and switch between them by running the specific command prompt.
I don't know why your rtm command prompt, selected the preview msbuild unless something amended your path.
I don't know why your rtm command prompt, selected the preview msbuild unless something amended your path
No, that's not what I mean: the build.cmd worked fine with the normal windows command prompt (without clicking the Developer Command Prompt installed by VS). Just cmd.exe. But now it doesn't work anymore, at least not on my system.
It now _only_ works in a "Developer Command Prompt" for RTM.
Here, this is what I meant, notice the title bar. This used to work until a few days ago:

I think what's going on here is yet another case of _not actually side by side installs_, but this time for MSBuild and/or NuGet. Merely installing this newer component on your machine breaks building this repo _except_ for when you use the 16.7.2 developer command prompt.
I did notice that just running dotnet.exe from any command prompt shows 5.0, which doesn't seem right in terms of side by side installs...
dotnetsdk has an idiosyncratic side by side story. It auto-updates, so you are always using the latest sdk, however, there is a global.json file, if you want to pin to a specific version of the dotnet sdk.
Kevin
Here is the issue about this in the nuget home repo: https://github.com/NuGet/Home/issues/9967
As per https://github.com/NuGet/Home/issues/9967#issuecomment-684107221 this was an arcade issue and we're updating, so I'll close this