sdk: Failure to publish WASM when project source path contains blank spaces - Post-upgrade VS 2022 to 17.2.4

A status update on this - we have an approved fix for servicing that we will merge one the September releases go out, so the final fix for this will be in the October releases of the .NET SDK.

I’ve updated my VS2022 Preview yesterday, and my (production) VS 2022 is failing to publish with this same error on SDK 6.0.400.

The global.json file forcing the 6.0.300 version solved the problem also.

I’m just taking a note for the possibility of the bug is back on the 6.0.400.

We’re sorry about this regression, and yes, we do expect to fix this in the next release (302).

Here’s the relevant PR: #26204

Unfortunately there wasn’t time to get this fix into the next build (302 / July), so it should be in the 303 / August release.

+1 same problem really a big bad waste of time… nasty problem!

Fixed mine by downgrading from 301 to 300 SDK… 301 has security patch so that is not a long term solution MS need to fix that at the next release.

For people in my situation here what i have done. Instruction above wasn’t clear especially for people who are not used to play with dotnet sdks… i think most of us rely on VS IDE to install/update .netx.x and move on to develop…

i didn’t have sdk 300 installed…

1. https://dotnet.microsoft.com/en-us/download/dotnet/6.0
2. Download and Install .NET 6.0.5 which will install sdk 300
3. Tools => NuGet Package Manager => Package Manager Console
4. type “dotnet new globaljson --force --sdk-version 6.0.300”
5. Build => Clean and Delete Bin/Obj
6. Restart Visual Studio
7. Publish it should work, it did for me anyway

Ok. I confirm that dotnet publish fails on path with spaces on 6.0.301 and does not fail on 6.0.300. Also the same project copied to path without spaces publishes fine on 6.0.301 as well. The project was created by dotnet new blazorwasm.

Steps:

mkdir "tmp with spaces"
cd "tmp with spaces"
mkdir blazortest
cd blazortest
dotnet new globaljson --sdk-version 6.0.301
dotnet new blazorwasm
dotnet publish

How did you force please ?

You can add global.json file with

{
  "sdk": {
    "version": "6.0.300"
  }
}

see https://docs.microsoft.com/en-us/dotnet/core/tools/global-json

Confirming that setting /p:BlazorEnableCompression=false fixes the issue during build. So its a problem during the compression stage.

On a side note: using /p:SelfContained=false overrides the BlazorEnableCompression setting.

Thanks folks - we believe this was inadvertently introduced with an update to System.CommandLine that changed the default processing of response files. The binlog above was very helpful in tracking this down @craigbrown, so thank you for that!

sample-bad-response-file.txt

Heres what’s been generated in the current bad state, I’m talking with the System.CommandLine team and figuring out how we want to resolve this. Will report back with options and how we intend to go forward.

Part of my personal confusion here is that this generated response file has something that I’d expect to be incorrect: the very first line seems to use space-delimited tokens (which must be quoted correctly and the path to dotnet isn’t), and all the other lines are line-delimited (which can be logically quoted as ‘complete’ single tokens and so seem fine to me).

EDIT: this isn’t the actual response file, it’s the final command line as given to msbuild, post response file processing. This explains the ambiguity of the first line. I’ve updated it to be correct. The overall response file is still not great because of the spaces in the paths, but we can work with that.

@baronfel here’s one from a minimal reproducible example I set up.

My issue is very slightly different - the whitespace is not in the project path but in the path to dotnet.exe. I assume it’s related though.

I also discovered that the issue only occurs when my Blazor WASM app’s csproj file contains the setting <PublishTrimmed>false</PublishTrimmed>. Maybe that helps narrow down the problem.

out.binlog.zip

I was able to implement the workaround @SantosVictorero suggested, but wondering when this will be fixed?

You can add global.json file with

{
  "sdk": {
    "version": "6.0.300"
  }
}

see https://docs.microsoft.com/en-us/dotnet/core/tools/global-json

That works ! Added global.json with version 6.0.203 in the solution folder, deleted all /bin and /obj folders in solution projects => I can now publish successfully !

It also happens in DevOps pipeline. I have the same using UseDotNet@2 task. I had to force it to use 6.0.106 to fix a broken build pipeline I cannot confirm if it’s because there of spaces in the project path, but there is indeed some spaces there. I just forced the build to use 6.0.106. Here is the devops log:

/usr/share/dotnet/sdk/6.0.301/Sdks/Microsoft.NET.Sdk.BlazorWebAssembly/targets/Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(614,5): error MSB6006: "/usr/share/dotnet" exited with code 1. [/home/vsts/work/1/s/._..<project path with some spaces....>/xxxxxx._csproj]
##[error]Error: The process '/usr/bin/dotnet' failed with exit code 1

Thanks a lot for the report @NonoSparc! However, that seems to be a Visual Studio bug, which should be reported to VS Dev Community, see https://developercommunity.visualstudio.com/report?space=8&entry=problem. Could you please open the issue there?

Sorry my english.

The problem is with the Maximum Path Length Limitation. To solve this problem You just need change the project path to a small path like C:\MyProject, and that it 😃

I hope this help to every one…

The only workaround is working in a path that doesn’t contain spaces, unfortunately.

@SantosVictorero you’ll have to install 6.0.300 manually and then use a global.json file to ‘pin’ to that version specifically in order to workaround this bug. Echoing @dsplaisted above, 6.0.303 in August will contain the fix for this and at that point you could remove your global.json.

We’re sorry about this regression, and yes, we do expect to fix this in the next release (302).

Here’s the relevant PR: https://github.com/dotnet/sdk/pull/26204

@cook32 to force it in DevOps. Added this to the top of tasks in my YAML

    - task: UseDotNet@2
      inputs:
        packageType: 'sdk'
        version: '6.0.106'

cc @dsplaisted

Should this be moved to runtime repo or somewhere else?

Same issue

Windows 11 Pro 21H2 OS Build 22000.675

Visual Studio Enterprise 2022 64-bit version 17.2.3

dotnet --list-sdks 3.1.420 [C:\Program Files\dotnet\sdk] 5.0.407 [C:\Program Files\dotnet\sdk] 5.0.408 [C:\Program Files\dotnet\sdk] 6.0.101 [C:\Program Files\dotnet\sdk] 6.0.203 [C:\Program Files\dotnet\sdk] 6.0.300 [C:\Program Files\dotnet\sdk] 6.0.301 [C:\Program Files\dotnet\sdk]

…

The problem is with the Maximum Path Length Limitation. To solve this problem You just need change the project path to a small path like C:\MyProject, and that it 😃

… The length of the path can be an issue, but the real problem is when you have blank spaces within: "C:\Dev\My Project" is enough to cause the bug!

Probably you can use version 6.0.203 as a work around too: https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/sdk-6.0.203-windows-x64-installer.

Is there a workaround that we can use in the meantime? The latest version of VS removed 6.0.300 and I cannot manually install it due to having a newer version installed. I tried updating the global.json file to use 6.0.303 but that did not work.

Any suggestions would be appreciated.

Today I installed Visual Studio update 17.2.6 which deleted the DotNet SDK version 6.0.300.

I removed my global.json with 6.0.300 and tested with 302 but as mentioned before, the error is still there:

I tried to install 6.0.300 again and I got the following error: [6990:45CC][2022-07-13T12:34:41]e000: Error 0x80070666: Cannot install a product when a newer version is installed.

Should I remove the 6.0.302 SDK to reinstall 6.0.300 or is another workaround?

We’re having the same problem in Azure DevOps Pipelines since yesterday, using v6.0.301 of the SDK. The publish fails on the exact same step (Compressing Blazor WebAssembly publish artifacts). As a result our pipeline now fails to run. It was working in v6.0.300.

We don’t have any whitespace in our project’s path name, but in Azure DevOps Pipelines the dotnet tool is run from C:\Program Files\dotnet\dotnet.exe which does have a space. Running the pipeline with more verbose output shows many lines like this:

Unrecognized command or argument 'Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\6.0.6\runtimes\browser-wasm\lib\net6.0\Microsoft.CSharp.dll'.
Unrecognized command or argument 'Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\6.0.6\runtimes\browser-wasm\lib\net6.0\Microsoft.VisualBasic.Core.dll'.
Unrecognized command or argument 'Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\6.0.6\runtimes\browser-wasm\lib\net6.0\Microsoft.VisualBasic.dll'.
Unrecognized command or argument 'Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\6.0.6\runtimes\browser-wasm\lib\net6.0\Microsoft.Win32.Primitives.dll'.
Unrecognized command or argument 'Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\6.0.6\runtimes\browser-wasm\lib\net6.0\Microsoft.Win32.Registry.dll'.
Unrecognized command or argument 'Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\6.0.6\runtimes\browser-wasm\lib\net6.0\mscorlib.dll'.
Unrecognized command or argument 'Files\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.browser-wasm\6.0.6\runtimes\browser-wasm\lib\net6.0\netstandard.dll'.
...

which does suggest it’s the space in Program Files which is causing the issue.

Same problem since upgrade of Visual Studio 2022 from 17.2.3 to 17.2.4 yesterday. Lots of wasted hours trying to publish a Blazor app to Azure. Tried global.json in the solution folder but caused .NET5 projects to fail to load.

Eventually fixed by removing 6.0.301 from “C:\Program Files\dotnet\sdk” and copying in 6.0.202 from a backup.

EDIT: Also works with 6.0.300 which I downloaded from the 6.0.5 section here: https://dotnet.microsoft.com/en-us/download/dotnet/6.0

Thanks a lot for the report @NonoSparc! However, that seems to be a Visual Studio bug, which should be reported to VS Dev Community, see https://developercommunity.visualstudio.com/report?space=8&entry=problem. Could you please open the issue there?