LabVIEW
Build failed with filename has blank or has invalid characters error
Solved!
This is an program that I have been maintaining for years. Nothing in this llb has changed in probably a decade, I can open the VI and I was able to successfully mass compile the llb containing it this morning.
But when I try to build the program I get this error:
The filename (C:\Program Files (x86)\National Instruments\LabVIEW 2025\instr.lib\rbllv201visa.llb\RBL SHORT On/Off.vi) entered is either blank or has invalid characters -- \ / : * ? < > | " <tab>
@RTSLVU wrote:
This is an program that I have been maintaining for years. Nothing in this llb has changed in probably a decade, I can open the VI and I was able to successfully mass compile the llb containing it this morning.
But when I try to build the program I get this error:
The filename (C:\Program Files (x86)\National Instruments\LabVIEW 2025\instr.lib\rbllv201visa.llb\RBL SHORT On/Off.vi) entered is either blank or has invalid characters -- \ / : * ? < > | " <tab>
doesn't "RBL SHORT On/Off.vi" contain an invalid character?
@billko wrote:
@RTSLVU wrote:
This is an program that I have been maintaining for years. Nothing in this llb has changed in probably a decade, I can open the VI and I was able to successfully mass compile the llb containing it this morning.
But when I try to build the program I get this error:
The filename (C:\Program Files (x86)\National Instruments\LabVIEW 2025\instr.lib\rbllv201visa.llb\RBL SHORT On/Off.vi) entered is either blank or has invalid characters -- \ / : * ? < > | " <tab>
doesn't "RBL SHORT On/Off.vi" contain an invalid character?
Oh (expletive), you're right... I wonder why it took a decade for LabVIEW to notice?
LLBs never had as strong limitations about naming of the files inside. One reason is that they are single level, so the presence of any character in the name that may be used on any platform as path separator is not an issue. LabVIEW has always honored that and as you can see still seems to allow those names in your source LLB. The LLB manager should also allow it when transferring between LLBs but as soon as the VI has to be copied out of the LLB in any way, all those characters and a few more are forbidden since one of the supported platforms does not allow them. LabVIEW choses to disallow on all platforms any character that is used on any platform to avoid trouble when source code is transferred between platforms. That sort of naming conflicts is very difficult to resolve on the platform that disallows a particular character.
I can only suspect that the Build Tool changed something in the path logic that disallows this name now for maybe somewhat zealous reasons or that your memory is a bit vague about what exactly worked in the past. You are also not very specific about the exact type of build you are talking about. Source Distribution Builds may actually still work as the source and target is a LLB. Executable builds should have failed for a long time since LabVIEW does not create LLBs for executables anymore but instead creates a hidden hierarchy on disk of all the compiled files in an executable and then packs everything up into a disguised ZIP file that is then added to the executable stub. And the forward slash in a ZIP file is specifically a reserved character in file names since it is THE path separator inside a ZIP when the paths of file streams are stored in the internal directory structure.
So maybe the Executable Builder did in the past create LLBs inside that ZIP for source LLBs and for some reason changed to copy them to a directory instead, which naturally disallows these forbidden characters. Or it did so since 8.0 already and you remember something not quite right.
Considering that LLBs are declared legacy technology since about 6.0 (released in 2000, when Windows 3.1 support was discontinued, which was the only reason LLBs really were ever invented), it is not so surprising that things involving them are starting to break. It's very imaginable that someone decided recently that LLB support code has to be slashed completely from at least the runtime version of LabVIEW. And they would have of course changed the Application Builder accordingly to not use that anymore in a build of an executable, but that little detail may have gotten unmentioned in the release notes.
I remember running into a similar issue when LV pushed for abondoning LLBs and converting them to libs/folders (When i started working with LV in 8.2). Suddenly names were illegal and i ran into some unforseen issues ...
@RTSLVU wrote:
TBH: I never understood the benefit of llb and lvlib files.
At least for LLBs, you don't seem to have worked in LabVIEW 3 and 4 on Windows. 😀
Windows 3.1 was simply a graphical shell above DOS. And DOS had a 8+3 filename limitation. Imagine your LabVIEW VIs having to be called MDConfM1.vi, MDConfM2.vi, MDConfM3.vi and so on, because you can't use more than 8 character for the filename. That's simply not really workable. So they had to invent something and their solution was a simple archive format, since trying to implement a whole ZIP infrastructure was at that time considered a major project in its own.
As to lvlibs, I suppose that was an easy byproduct of implementing lvclasses. There is an advantage to having a namespacing for a group of VIs and defining which VIs are public and which are private and inaccessible to an outside user. Yes you can go lvclass for that and get even more possibilities, but lvclass was back then something many LabVIEW users looked at rather suspiciously, since OOP was seen as that complex, overengineered and unnecessary dinosaur that made C for instance almost incomprehensible for an experienced C programmer.
