.NET SDK installation fails when using winget

[dosolkowski-work]

I attempted to upgrade .NET SDK 6.0.410 to 6.0.411 using winget on the command line, but it failed:

$ winget upgrade Microsoft.DotNet.SDK.6
Found Microsoft .NET SDK 6.0 [Microsoft.DotNet.SDK.6] Version 6.0.411
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...
Installer failed with exit code: 87
Installer log is available at: C:\Users\user\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\WinGet-Microsoft.DotNet.SDK.6.6.0.411-2023-06-27-09-52-13.820.log
One of the installation parameters is invalid. The package installation log may have additional details.

However, when I downloaded the SDK installer directly from https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/sdk-6.0.411-windows-x64-installer and ran it, it succeeded. It seems like there may be some difference about winget that causes the installer to fail. I will try to attach the logs from the failed installation run: dotnet_sdk_install_logs.zip

I cannot replicate the scenario any further since I upgraded manually, but please let me know if there are any questions.

[joeloff]

The path for one of the log files is too long: 262 (max path is 260). Can you redirect WinGet to generate the log in different folder? The problem is that WinGet is adding a very long prefix to the log files, so you end up with this WinGet-Microsoft.DotNet.SDK.6.6.0.411-2023-06-27-09-52-13.820_010

Try passing --log to winget to work around this.

[joeloff]

cc @mthalman

[dosolkowski-work]

Looks like there's a winget issue which redirects some blame back to the dotnet SDK installer:

If the dotnet installer is going to add characters to the filename, it needs to use the appropriate prepends or APIs to enable longer filenames.

I don't want to insert myself into an internal debate between two Microsoft teams, so I offer no opinion as to which team is at fault, but I would encourage the teams to discuss.

[joeloff]

The standard log file format for the SDK would be something like Microsoft_.NET_SDK_6.0.202_(x64)_20230627230259 so something on the WinGet size is modifying it to a longer name. The problem becomes worse because by default, bundles assign the primary log file name to nested installs (to simplify capturing log files). There might be some options available to shorten names, but most of it is outside of our control as it's managed by the bundle engine and any fixes we make would not address issues in older versions.

[marcpopMSFT]

Old issue triage: Assuming this is no longer an issue as winget has been updated since then.

[dosolkowski-work]

I believe this was still happening recently, I just haven't encountered it because I no longer need the SDK installed separately. A contributing factor may be that I had an especially long folder name in C:\Users\ because it was suffixed with my AD Domain name, so around 30 characters. That has also changed so I'm not sure if I can even reproduce this personally, but maybe someone in Microsoft can?