System.IO.PathTooLongException

[Noah]

Hello,

I am running into the following path length error, it looks to be something within the cmake cache of visualgdb:

-- Generating done (1.9s)
-- Build files have been written to: D:/git/Ahi/AhiMainApp/build/VisualGDB/Debug
System.IO.PathTooLongException: Path too long: \..\..\../build/VisualGDB/Debug\.cmake/api/v1/reply\directory-modules.hal_nxp.mcux.mcux-sdk-ng.devices.RT.RT1064.MIMXRT1064.devices.RT.RT1064.MIMXRT1064.drivers.devices.RT.RT1050.MIMXRT1052.drivers.flexram-DEBUG-532024778a5771ea2c83.json ---> System.IO.DirectoryNotFoundException: Could not find a part of the path '\.visualgdb\VisualGDBCache\<strong>****</strong>-Debug-VisualGDB\CodeModelCache\directory-modules.hal_nxp.mcux.mcux-sdk-ng.devices.RT.RT1064.MIMXRT1064.devices.RT.RT1064.MIMXRT1064.drivers.devices.RT.RT1050.MIMXRT1052.drivers.flexram-DEBUG-532024778a5771ea2c83.json'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
at x11.d(String a, String b)
--- End of inner exception stack trace ---
at x11.j(Exception b, String[] a)
at x11.d(String a, String b)
at x11.l(String b, String a, w c)
at xh2.b_2(String a, String b)
at td.u(g b, Object a)

========== Project Configuration Summary ==========
<strong>*****</strong> configured in 00:13
========== Configuration: 1 Succeeded, 0 Failed, 0 Skipped ==========

Note that I have obscured some details, in bold. It looks like the json file name is the full CMake module include trace, which inevitably produces a huge file name.

This error seems to cause a ‘clean rebuild’ every time I build, presumably because the build system does not believe that the previous clean rebuild was successful, even though it is).

I have long-file-names enabled on my computer and no errors appear in the visualgdb diagnostics console. I am also using a ReFS dev drive.

 

Thank you for your help,

Noah

[Noah]

I also found that the file that it is looking for in the CodeModelCache,

directory-modules.hal_nxp.mcux.mcux-sdk-ng.devices.RT.RT1064.MIMXRT1064.devices.RT.RT1064.MIMXRT1064.drivers.devices.RT.RT1050.MIMXRT1052.drivers.flexram-DEBUG-532024778a5771ea2c83.json

does not seem to exist.

[Noah]

The file does exist in

<PathToBuildOutput>\VisualGDB\Debug\.cmake\api\v1\reply

[support]

Hi,

This is tricky. This particular error happens when VisualGDB tries to copy the CMake code model to its own cache directory. The original file path is likely just below the MAX_PATH limit, and the one in the VisualGDB’s cache directory is above.

The good fix for this would be to try convincing the CMake maintainers to put a length limit on the code model file names, so the problem wouldn’t happen in the first place.

Another option would be to enable the legacy server mode instead of the file mode via  Tools->Options->VisualGDB->CMake->API for querying CMake state.

We will take another look at the VisualGDB’s logic for reading the model files in about a week, and will see if we can add a better workaround.

[Noah]

Thanks for the response. Unfortunately, changing to server mode causes an intermittent failure shown in the attachment.

To your point about convincing CMake to make a change to their code model file naming scheme: I don’ t think that will get much traction because

1. My root CMakeLists file is as close to the root directory as possible. One could easily cause a path length over 260 characters by embedding my root source location deeper in the file system, which would cause this error regardless of the length of the code model cache file names. CMake’s solution to long path length errors on windows is to enable long file name support, and this works perfectly.
2. From your description, this seems to be a copy error within VisualGDB (or .NET) itself. If CMake were to change the way it names files, this would simply be a band-aid over a more severe problem. This band-aid also wouldn’t work for the scenario where a build is located deep in a file system.

Best,

Noah

Attachments:

You must be logged in to view attached files.

[support]

Hi,

It’s a good question what to consider a band-aid in this case. All VisualGDB does is copies the files created by CMake under a slightly longer path using the standard .Net copying API. One could argue that a proper fix would be to understand why the .Net framework doesn’t handle this properly, since many other tools, including Visual Studio itself, also heavily use .Net.

Either way, we have recently updated our CMake subsystem to support toolchains coming from vendor-specific VS Code extensions, and were also able to optimize away the extra copying of response files. Feel free to try this build: VisualGDB-6.1.3.5439.msi

[Noah]

Hello,

I will give that a try, thank you.

You mentioned the fix would be to understand why the .Net framework behaves the way it does, and I agree. Of course, I don’t know about how VisualGDB is built, so the following suggestion is a shot in the dark:

Depending on the version of .NET that visualgdb uses, long path awareness may need to be enabled using the application manifest:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
</application>

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#application-manifest-updates-to-declare-long-path-capability

CopyFileW is listed as one function that has a MAX_PATH restriction unless the above is in the application manifest.

Another possibility is that VisualGDB is running into this issue: https://developercommunity.visualstudio.com/t/long-path-support-in-netframework-472-and-windows/1057100

In which case, the solution is listed here: https://learn.microsoft.com/en-us/archive/blogs/jeremykuhne/net-4-6-2-and-long-paths-on-windows-10#configuring-asimple-long-path-net-console-app

 

Best,
Noah

[support]

Hi,

Well, googling up “.Net path length limitation” is not the real problem here. The problem is side effects in a system where we don’t control every part.

VisualGDB is an extension that gets loaded into at least 3 different .Net processes: Visual Studio GUI itself, background MSBuild worker, and MSTest runner. Globally changing the manifest for even one of them is almost guaranteed to trigger some unexpected behavior in some other plugin that is loaded into the same application.

So, what we do when it comes to workarounds, is look whether the fix is reducing or increasing the external complexity. Changing a global manifest (so every single MS assembly inside devenv will run under different global configuration than it was ever tested by MS) would be a huge no. Manually copying files under long paths might blow back if another extension (or VS component) tries to enumerate them, and doesn’t handle the paths accordingly. It’s tolerable if we were fixing a major bug (e.g. debugging completely broken for multiple projects), but not worth it for a cosmetic fix.

What we ended up doing (removing the extra copying step) actually reduced the external complexity (each project has now fewer files), so we wouldn’t expect it to break anything else that wasn’t broken already.

Hope this explains.

[Author]

Posts