Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Diagnostic log "Environment at start of build" should record whether long paths enabled #10151

Open
hickford opened this issue May 17, 2024 · 3 comments
Assignees
Labels
Feature Request Good First Issue Self-contained issues good for first-time contributors. Priority:2 Work that is important, but not critical for the release triaged

Comments

@hickford
Copy link
Contributor

hickford commented May 17, 2024

Summary

MSBuild's diagnostic logging -v:diagnostic should record whether long paths are enabled.

Background and Motivation

msbuild.exe supports long paths on Windows since 16.0 https://github.com/dotnet/msbuild/releases/tag/v16.0.461.62831

MSBuild.exe now supports long paths on Windows

However Windows users have to additionally opt in by setting a registry key/ https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior. ... The registry key Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled (Type: REG_DWORD) must exist and be set to 1

Proposed Feature

MSBuild's diagnostic logging -v:diagnostic includes an "environment at start of build section". This should record whether long paths are enabled in Windows.

Alternative Designs

No response

@AR-May
Copy link
Member

AR-May commented May 21, 2024

Team triage: This is absolutely a great idea. @hickford are you interested in contributing to MSBuild and picking this issue up?

@AR-May AR-May added the Priority:2 Work that is important, but not critical for the release label May 21, 2024
@hickford
Copy link
Contributor Author

I don't have the expertise.

@rainersigwald
Copy link
Member

@hickford no problem--a great idea is helpful all on its own!

@YuliiaKovalova YuliiaKovalova added the Good First Issue Self-contained issues good for first-time contributors. label Jun 3, 2024
@JanProvaznik JanProvaznik self-assigned this Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Good First Issue Self-contained issues good for first-time contributors. Priority:2 Work that is important, but not critical for the release triaged
Projects
None yet
Development

No branches or pull requests

5 participants