Add longPathAware declaration to app.manifest for C# project templates

[Marv51]

Since Windows 10 1607, developers can declare a flag in their app.manifest to remove the MAX_PATH limitation. This enables support for file paths longer than 260 characters.

Modern versions of .NET support this well and most .NET libraries also support this as well due to their cross-platform design. Other platforms do not impose the same limitation.

For new C# applications in 2025 and beyond, the recommended default value for longPathAware should be true. This PR enables that setting in the C# project templates.

This change does not force WinAppSDK apps to be longPathAware. If incompatibilities arise, developers can remove the line, or set the value to false explicitly.

I have not updated the C++ templates in this PR.

---

A microsoft employee must use /azp run to validate using the pipelines below.

WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.

For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.

[mominshaikhdevs]

• force using longPathAware for all reunion apps #875.

• Stuck at archive extracting - Long extraction path winget-cli#5466.

• Windows device path and long-path meta issue. rust-lang/cargo#9770.

[sylveon]

This is a dangerous default

Developers won't specifically be testing their apps with long paths if it's the default, so they'll think everything is fine, and then one native library they may be indirectly using does char file[MAX_PATH] and it blows up on either a customer's computer or as a potential security vulnerability (stack overflows are ripe for abuse).

Long paths are something that should only be enabled after full validation that your app works as expected with them.

[Marv51]

Maybe a milder version of this PR would be to set this explicitly to false with a comment? What are the opinions on that?

<!-- Set to true to allow paths longer than 260 characters. May cause issues with some third-party components. --> <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">false</longPathAware>

[sylveon]

I would be fine with that, but just comment it out instead of an explicit false.
E.g.

<!-- Uncomment to allow paths longer than 260 characters. May cause issues with some third-party components. --> <!-- <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware> -->

[riverar]

Note: This change does nothing until this feature is turned on machine-wide. This is off by default. (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem!LongPathsEnabled=0x1)

I agree with others here, however. This change may confuse newcomers with crashes/undefined behavior after bringing in libraries that don't properly support long paths.

[riverar]

App compat impact here is too great

[mominshaikhdevs]

EDIT:

I dont believe any APIs(CreateProcess*W, Create*Thread, Exit*, Open*, Get*, Set*, TerminateProcess and so on) under the processthreadsapi.h supports longPathAware, unless the issue is fixed in newer Windows builds, just like they fixed the following issue in newer Windows builds:

• Packaged wasdk app can't even read correct registry value? #5199.

---

It has become a chicken and egg problem at this point.

I would be fine with that, but just comment it out instead of an explicit false. E.g.

<!-- Uncomment to allow paths longer than 260 characters. May cause issues with some third-party components. --> <!-- <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware> --> 

This is the way to go forward.

• use app manifest cppwinrt#882. (/Don't fail file open/writes silently cppwinrt#880 (comment).)

[riverar]

Including this feature upfront could create lots of confusion for developers who might expect it to work out of the box. (It won't work out of the box.) Developers with specialized use cases who genuinely need this functionality can figure this out through documentation or by consulting with subject matter experts.