Save As... Duplicate lvproj file doesn't work correctly with lvlibs/lvclasses

[Rob_Calhoun]

I am trying to save a copy of a project with all dependencies so that I can sent a subset of our code to NI technical support for another issue. I have been unable to do this successfully and have isolated this to limitations of "Save As..." --> "Duplicate .lvproj file and contents (Include all dependencies)" when handling lvlibs and lvclasses. I am wondering if I am doing something wrong or if there is a workaround. 

I am using LabView 8.6.1 under Windows. A sample project displaying this issue is attached. To repro the problem I am having,

1. Open library.lvproj. This is simple project with one library (SimpleLibrary.lvlib) and two VIs that are member of that library. (Add.vi and Subtract.vi).
2. File -> Save As... -> Duplicate .lvproj file and contents (Include all dependencies)
3. Pick a new location in your filesystem somewhere.
4. The save starts, then LabView puts up a dialog box "Cannot save library 'SimpleLibrary.lvlib'. Another library in memory is already loaded from that path." (Note that this is not true; the library is loaded from the original project path; nothing has as of yet been saved to the new project path.)
5. LabView it gives you a file dialog in the target location. If you click OK (opting to save it to the new location in the same relative path as in the original project), it returns to the "Cannot save library" dialog box. If you create a new folder (i.e. "New Folder") in the target and descend into the target, then the save is allowed, but when you re-open the project it looks for the library at the old location (relative to the new copy of the project), and it opens it as conflicted. The conflicts must be resolved manually. 

The manual move-and-unconflict process is tolerable with a simple project containing one library, but it is impractical in a large project with dozens of lvlibs and classes.

Can anyone suggest a workaround for this behavior so that a project can be exported with all of its dependencies and without path corruption? 

Thanks,

Rob 

Message Edited by Rob Calhoun on 08-24-2009 03:10 PM

[Rob_Calhoun]

This is possibly a known LabView 8.6.1 issue that has been corrected in LabView 2009. (See LabView 2009 bug fixes ). CAR 124214 is listed as "Save As»Duplicate Contents with Dependencies error with LabVIEW 8.6 project", and I have found that the Save As... feature does work correctly in LV 2009. (I'm still interested in a LV 8.6.1 workaround, since my underlying problem is an inability to open a LV 8.6.1 project in LV 2009 and exporting a copy with dependencies is the first step to isolating that.)

[Ben]

Try save for previous and choose the same version.

I believe it was Christian who first pointed that trick out.

Ben

[OliviaC]

Hi Rob,

For that particular CAR, the recommended work around is the following:

(1) Save the .lib file as a different name
(2) Browse to the .lib file in Windows Explorer and rename it back to the original name
(3) Open up the duplicated project and it should work as expected

Let me know if that helps!

[Rob_Calhoun]

I loved Ben's suggestion because it promised to be a low-effort workaround, but, alas, I get the same problem: "lvlib is already loaded from this path...".

I tried Olivia's workaround for CAR 124214. It worked great for the simple lvproj that is posted above. (Hooray!) It didn't work so well in my real project, that has about 30 lvlibs and lvclasses. About 3/4 of the way through the save, I got a compiler error and LabView crashed. (Boo!) I submitted the crash log on this, but it's hard to imagine how anyone in R&D could make any progress debugging this without the source code. (And I can't submit the source because I can't export a copy of it!)

 

Anyway, thank you very much Ben and Olivia for your suggestions. I have lvclasses embedded in lvlibs (primarily for organizational reasons) and since LabView tanked while saving one of those, perhaps the workaround doesn't work in this case. I may try again after removing the lvclasses from the lvlibs so that the hierarchy is flatter.

-Rob