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

[NonoSparc]

Since upgrade of Visual Studio 2022 from 17.2.3 to 17.2.4 on june 15th, I cannot publish any Blazor Web Application project anymore.

This goes for new and existing projects. Even a simple publish to folder fails with error message:

C:\Program Files\dotnet\sdk\6.0.301\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(614,5): Error MSB6006: "dotnet.exe" exited with code 1.

After hours of frustating attempts, I found that it was related to the location of my projects. Parent path to my dev folder contained blank spaces!

Changing VS MSBuild output verbosity, I found that the error was related to Blazor WebAssembly publish artifacts compression task:

...
Compressing Blazor WebAssembly publish artifacts. This may take a while...
Creating directory "obj\Release\net6.0\compress\".
C:\Program Files\dotnet\dotnet.exe "C:\Program Files\dotnet\sdk\6.0.301\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\..\tools\net6.0\Microsoft.NET.Sdk.BlazorWebAssembly.Tool.dll" brotli
-s
C:\Dev\With Space\BlazorAppSol\BlazorApp\Client\bin\Release\net6.0\wwwroot\_framework\blazor.webassembly.js
-o
C:\Dev\With Space\BlazorAppSol\BlazorApp\Client\obj\Release\net6.0\compress\N6++qccl.br
...
Unrecognized command or argument 'Space\BlazorAppSol\BlazorApp\Client\bin\Release\net6.0\wwwroot\_framework\blazor.webassembly.js'.
...
C:\Program Files\dotnet\sdk\6.0.301\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(614,5): Error MSB6006: "dotnet.exe" exited with code 1.

The above output was produced by creating a new Blazor Web Assembly project under a root folder with path 'C:\Dev\With Space' and publishing it to relative folder 'bin\Release\net6.0\publish'.

Is this a known issue?

Configuration:
Windows 10 Enterprise 21H2 Build 19044.1766
Visual Studio Enterprise 2022 64-bit version 17.2.4
Blazor WebAssembly App project with .NET 6 and ASP.NET Core host

[cook32]

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]

[CarnaViire]

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?

[jocecaro]

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?

[CarnaViire]

Can you reproduce it locally from CLI @jocecaro ?

[cook32]

How did you force please ?

[CarnaViire]

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

[CarnaViire]

cc @dsplaisted

Should this be moved to runtime repo or somewhere else?

[cook32]

dotnet publish

C:\temp\tmp with spaces\blazortest>dotnet publish
Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

Determining projects to restore...
All projects are up-to-date for restore.
blazortest -> C:\temp\tmp with spaces\blazortest\bin\Debug\net6.0\blazortest.dll
blazortest (Blazor output) -> C:\temp\tmp with spaces\blazortest\bin\Debug\net6.0\wwwroot
Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: http
s://aka.ms/dotnet-illink
Compressing Blazor WebAssembly publish artifacts. This may take a while...
C:\Program Files\dotnet\sdk\6.0.301\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembl
y.6_0.targets(614,5): error MSB6006: "C:\Program Files\dotnet" exited with code 1. [C:\temp\tmp with spaces\blazortest
blazortest.csproj]

[jocecaro]

@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'

[NonoSparc]

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 !

[Zagreth]

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

[wkellar]

Same problem here since upgrade of Visual Studio 2022 from 17.2.3 to 17.2.4 yesterday. Removing White space in file path fixed it.

[craigbrown]

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.

[mozesj]

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

This was helpful I kept getting error "Microsoft.NET.Sdk.Blazor WebAssembly.6_0.targets(614,5): error MSB6006". I can confirm once I removed spaces (my directory to mydirectory) on the build environment, the blazor build was successful.

[baronfel]

Hey folks, can anyone impacted please upload a binlog with details? This really help us speed up the process of identifying where the issue with space handling is being introduced, so we can route it to the correct team for triage and resolution.

[cook32]

Here you will find binlog generated with a test project which failed to publish. Hope it will help.
BlazorApp1_Debug_AnyCPU_DesignTimeBuild_2022-06-17T17_33_36.1049566+02_00.zip

[craigbrown]

@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

[baronfel]

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.

[SantosVictorero]

Definitely the problem is with Task BrotliCompress; I created two test projects, one with not spaces and one with spaces.

Here is the binlog file of the one with spaces:

BlazorAppWithSpaces_Release_AnyCPU_Build_2022-06-17T20_23_21.3052265-04_00.zip

[mkArtakMSFT]

@baronfel given the email from @javiercn on this topic, this is not caused by ASP.NET Core. Can you please update the area-path? Thanks!

[baronfel]

Done, thanks for the reminder!

[vijayrkn]

@baronfel - Based on the previous comments, this doesn't look like an issue in the websdk targets. What would be the best label for this?

[rizwanahmed23]

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 !

global.json file wont work if its inside the path/folder which has space issue so keep it in top most possible folder.

[LeonSpors]

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 !

global.json file wont work if its inside the path/folder which has space issue so keep it in top most possible folder.

The solution is to copy the folder and rename it. Just for the sake of publishing.

[Sc0tTyXL]

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.

[hshimshon]

+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

[dsplaisted]

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

[dsplaisted]

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.

[SantosVictorero]

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?

[baronfel]

@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.

[SantosVictorero]

Thanks @baronfel, it works like a charm, again! 👍

Download and manually install .NET:
https://docs.microsoft.com/en-us/dotnet/core/install/windows?tabs=net60#download-and-manually-install

[baronfel]

I'm going to close this one in favor of #26026, which it is a duplicate of.

[HClausing]

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.

[baronfel]

I've reopened the original issue due to this.

[EricB-ASI]

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.

[baronfel]

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

[SantosVictorero]

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.

[EricB-ASI]

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

[PanamaHeur]

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...

[NonoSparc]

...

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!

[baronfel]

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.