LV RTE cannot open project files that have .lvlib references in Dependencies

[MacNorth]

I'm writing a LabVIEW DLL to inspect LabVIEW project files, and I've noticed that if a project has a .lvlib reference in its Dependencies, then the Run-Time Engine contradicts itself about whether or not it can find the project file:

• Project.Open returns error 7 (file not found)
• Project.GetFileLVVersion is successful

Here are snippets from my G and C code that exercise this behavior:

   int openStatus = StatusSuccess;
   char* projectVersion = createStringWithLength(VersionStringLength);

   printf("Analyzing %s\n", pathString);
   OpenProject(pathString, &openStatus, projectVersion, VersionStringLength);
   printf("  Project written in LabVIEW %s\n", projectVersion);

   if (openStatus == StatusSuccess)
   {
      printf("  Opened project file.\n");
   }
   else
   {
      printf("Error: Could not find project file, or file was not a project file (error code %i).\n", openStatus);
   }

However, when running in the development environment, both methods succeed.

Is this a bug, and if so, is it fixed in LabVIEW 2014?

---

Here is how you can reproduce it:

Prerequisites:

1. LabVIEW 2013 SP1 32-bit
2. ConEmu for a good console -- https://code.google.com/p/conemu-maximus5/wiki/Downloads
3. minGW for compiling a program to use the LabVIEW DLL -- http://sourceforge.net/projects/mingw/files

.lvlib reference in Dependencies breaks Project.Open in LV RTE

1. Unzip the attachment into a temporary directory (eg c:\xtra\temp)
2. Open "OpenProject.lvproj" in LabVIEW.
3. Build "Open Project Library".
4. Using ConEmu with a bash prompt, navigate to the temporary directory.
5. Type make

$ make
patching file `builds/platdefines.h'
gcc -std=c99 -g OpenProject.c -o OpenProject.exe -lOpenProject -Lbuilds

6. Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'

$ OpenProject 'c:\xtra\temp\OpenProject.lvproj'
Analyzing c:\xtra\temp\OpenProject.lvproj
  Project written in LabVIEW 13.0
  Opened project file.

 7.  Notice that both invoke nodes execute correctly.

 8.  Type OpenProject 'c:\xtra\temp\OpenProjectWithLvlibDep.lvproj'

$ OpenProject 'c:\xtra\temp\OpenProjectWithLvlibDep.lvproj'
Analyzing c:\xtra\temp\OpenProjectWithLvlibDep.lvproj
  Project written in LabVIEW 13.0
Error: Could not find project file, or file was not a project file (error code 7).

 9.   Notice that the version node succeeded while the open one failed.

 10. Type diff OpenProject.lvproj OpenProjectWithLvlibDep.lvproj

$ diff -u OpenProject.lvproj OpenProjectWithLvlibDep.lvproj
--- OpenProject.lvproj  Tue Nov  4 11:28:28 2014
+++ OpenProjectWithLvlibDep.lvproj      Tue Nov  4 11:32:37 2014
@@ -13,7 +13,11 @@
       <Property Name="server.vi.propertiesEnabled" Type="Bool">true</Property>
       <Property Name="specify.custom.address" Type="Bool">false</Property>
       <Item Name="OpenProject.vi" Type="VI" URL="../OpenProject.vi"/>
-      <Item Name="Dependencies" Type="Dependencies"/>
+      <Item Name="Dependencies" Type="Dependencies">
+          <Item Name="vi.lib" Type="Folder">
+              <Item Name="NI_MABase.lvlib" Type="Library" URL="/&lt;vilib&gt;/measure/NI_MABase.lvlib"/>
+          </Item>
+      </Item>
       <Item Name="Build Specifications" Type="Build">
          <Item Name="Open Project Library" Type="DLL">
             <Property Name="App_copyErrors" Type="Bool">true</Property>

---

Here is another way to trigger this behavior, which also shows that LabVIEW only sometimes tidies the Dependencies item:

1. Open "OpenProject.lvproj" in LabVIEW.
2. Add a new VI to the project and place the "Application Directory" file path constant its block diagram.
3. Select "File » Save All (this Project)" and use the default name for the new VI.
4. Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
5. Notice there is an error again, as is expected.
6. Remove the "Application Directory" file path constant.
7. Select "File » Save All (this Project)"
8. Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
9. Notice the problem is gone, as is expected.
10. Re-add the "Application Directory" file path constant to the block diagram.
11. Select "File » Save All (this Project)"
12. Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
13. Notice there is no problem, which is surprising as there should be an error since the Dependencies item hasn't been tidied.
14. Close the new VI and remove it from the project.
15. Select "File » Save All (this Project)"
16. Open "OpenProject.lvproj" in a text editor.
17. Notice the Dependencies item has been tidied.
18. Re-add the VI back to the project.
19. Select "File » Save All (this Project)"
20. Type OpenProject 'c:\xtra\temp\OpenProject.lvproj'
21. Notice there is an error again, as is expected.

[NInjaneer_0]

Hello MacNorth, 

I can attempt to recreate this issue, although it may take some time. What operating system are you using? 

[MacNorth]

Hi Cameron, thanks for your response 🙂

I'm using Windows XP SP3.

[NInjaneer_0]

Hi MacNorth, 

I was able to recreate this bug by buliding an executable from your OpenProject.vi and attempting to open a new blank LabVIEW project. 

Software Used: 

LabVIEW 2014

Steps Taken: 

1. Build .exe from OpenProject.vi

2. Open New Project

3. Add a new vi with an "Application Directory" file path constant on the block diagram

4. File » Save All 

5. Run Application 

6. Input filepath of new project

7. Results = Error 7, Version 14

8. Remove "Application Directory" file path constant

9. File » Save All 

10. Results = No Error, Version 14

This appears to be a bug. However, before filing a Corrective Action Report I'll need to test the phenonmon with the LabVIEW RTE

[MacNorth]

---

NInjaneer_wow wrote:

I was able to recreate this bug by buliding an executable from your OpenProject.vi and attempting to open a new blank LabVIEW project. 

<snip>

This appears to be a bug. However, before filing a Corrective Action Report I'll need to test the phenonmon with the LabVIEW RTE.

---

Thanks for the update. I see the same behavior in LabVIEW 2013 when I build an executable from OpenProject.lvproj.

Please let me know what you learn.

[NInjaneer_0]

Hi MacNorth, 

The same behavior occurs in LabVIEW RTE: a new project with an Application Directory constant in a blank vi will return error 7 - file not found, but still return the correct version of LabVIEW in which the project was created. 

Thank you for your patience and, additionally, for making us aware of this bug. I will go ahead and file a Corrective Action report. 

[MacNorth]

---

NInjaneer_wow wrote:

The same behavior occurs in LabVIEW RTE: a new project with an Application Directory constant in a blank vi will return error 7 - file not found, but still return the correct version of LabVIEW in which the project was created. 

Thank you for your patience and, additionally, for making us aware of this bug. I will go ahead and file a Corrective Action report.  

---

Thanks for your diligence in exploring a bug in the darker corners of LabVIEW. What is the Corrective Action report ID so I can check for it in future LabVIEW releases?

[NInjaneer_0]

CAR 505322

Cheers, 

[MacNorth · Accepted solution]

---

NInjaneer_wow wrote:

The same behavior occurs in LabVIEW RTE: a new project with an Application Directory constant in a blank vi will return error 7 - file not found, but still return the correct version of LabVIEW in which the project was created. 

---

I've been experimenting with workarounds for this behavior, and I found one.

When I provide the LabVIEW path for libdir in my executable's ini file, the run-time is able to load and inspect the project file.

libdir="C:\Program Files\National Instruments\LabVIEW 2013"

While it's expected that a stand-alone executable may be placed on a system that doesn't have the LabVIEW IDE, it's still surprising to me that the Run-Time Engine cannot find LabVIEW's standard library without some explicit guidance. What other considerations contribute to that behavior?

References:

• LabVIEW configuration file/Paths -- http://labviewwiki.org/LabVIEW_configuration_file/Paths

[gabnaim]

I have had the exact same problem with LabView 2014 and adding the libdir helped. I was not using the RTE, however. I was trying to compile an exe for the AppBuilder, which does refer to several lvlib files in the vi.lib. 

Thank you for the solution, it really helped me! I was banging my head against it for a day.