Build fails due to missing RoslynTools.MSBuild 16.0.0-alpha
See original GitHub issueI wasn’t sure whether this issue belongs here or in dotnet/arcade. Please feel free to move it.
Steps to reproduce: Clone repository, run build.cmd.
Results:
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview3-010436/dotnet-sdk-3.0.100-preview3-010436-win-x64.zip
dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview3-010436/dotnet-sdk-3.0.100-preview3-010436-win-x64.zip
dotnet-install: Adding to current process PATH: "C:\Users\user\source\repos\winforms\.dotnet\". Note: This change will not be visible if PowerShell was run as a child process.
dotnet-install: Installation finished
Downloading vswhere
Downloading RoslynTools.MSBuild 16.0.0-alpha
No package matching package identifier RoslynTools.MSBuild and version 16.0.0-alpha was found in the given feed.
Version 16.0.0-alpha of the package indeed does not appear to exist, but 16.0.0-rc1-alpha does.
Additionally, running build a second time results in a different error:
Exception calling "Start" with "0" argument(s): "The system cannot find the file specified"
System.Management.Automation.MethodInvocationException: Exception calling "Start" with "0" argument(s): "The system cannot find the file specified" ---> System.ComponentModel.Win32Exception: The system cannot find the file specified
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at CallSite.Target(Closure , CallSite , Object )
--- End of inner exception stack trace ---
at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at Exec-Process, C:\Users\user\source\repos\winforms\eng\common\tools.ps1: line 69
at MSBuild, C:\Users\user\source\repos\winforms\eng\common\tools.ps1: line 476
at InitializeToolset, C:\Users\user\source\repos\winforms\eng\common\tools.ps1: line 422
at Build, C:\Users\user\source\repos\winforms\eng\common\Build.ps1: line 76
at <ScriptBlock>, C:\Users\user\source\repos\winforms\eng\common\Build.ps1: line 125
at <ScriptBlock>, <No file>: line 1
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Build fails due to missing RoslynTools.MSBuild 16.0.0-alpha
The reason why the build is failing is that you are building on a machine that does not have VS2019 yet you require...
Read more >MSBuild fails due to missing files - that I actually want to ...
After test with Build Action: Content and Copy to output directory: Do not copy . This is also work fine with my local...
Read more >Projects fail to build in 15.8.0 due to errors from Microsoft. ...
I have several projects that are now failing to build in 15.8. Both were building in 15.7. These projects don't have any NuGet...
Read more >Build in Visual Studio runs fine, msbuild fails
We need to build a msix package (wapproj) with our DevOps pipeline. We only want to build for platform x64 on windows for...
Read more >Project will not build using MSBuild - Bamboo
I am currently trying to use MSBuild to build out a test project. For some reason it keeps giving me errors: Class name...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

thanks @ArrowCase I am actively working on a workaround for us here but this is an underlying Arcade issue
This should be solved by a workaround on our end as part of #647