[New Feature] Support for Windows Long Paths

[Christina_R]

LabVIEW 2025 Q3 adds support for Windows long paths.

[Idea submitted by NI Discussion Forums member JonathanLindsey.]

[andre.buurman@carya]

Can you add a link to the idea or explain what this solves? We sometimes run into application builds that run to an end without erroring out but without creating the final executable file. The build output is the executable folder that isn't wrapped into the exe file.

[crossrulz]

Remove File Path Length Limitation 

[wiebe@CARYA]

---

@crossrulz wrote:

Remove File Path Length Limitation 

---

I still wander what the scope of this feature\fix is.

The idea talks about how this should (maybe) already work and\or how it depends on setting in LabVIEW and\or the OS...

Is the build exe bug supposed to be fixed? I guess we'll try in the near future...

[Thumper]

We've implemented long path support for LabVIEW 2025 Q3 primarily by updating LabVIEW's core file library to support long paths.  Our implementation does not require policy or registry changes.  These are the kinds of workflows we're enabling:

• Loading / editing / saving LabVIEW files (such as VIs, .ctls, .lvlib, and .lvproj) at long paths
• File I/O APIs (e.g. create, write, copy, rename, delete, etc.) operating upon files at long paths
• Build specifications exporting build output into long path destinations

LabVIEW apps will typically not need to take any special action to uptake long path support.  LabVIEW developers should simply use path controls / constants / wires (as they would normally) to construct long paths and to pass them into diagram nodes.

Note that NI Toolkits, Modules, and Drivers may remain constrained by traditional path limitations on Windows.  Also, for LabVIEW apps which interact with external software components, those external components may or may not support long paths.