One way to corrupt a library

[Tim_S]

I've been working with NI Tech Support. We've got this figured out to where it's time to share the fun we've been having. Hope this keeps someone from a bit of hair pulling.

OS: WinXP

LabVIEW: 8.6.1, but I was able to reproduce it in 2009

I have a library containing all of the code, menus, icons, interface VIs and documentation for an executable X. There are two build specifications: one to create the executable and put some of the files in appropriate directories, and one to distribute a portion of the source code. The first build specification (executable) has no issues. The second build specification reports a successful build. This is not the case as opening the library at the destination directory gives me a dialog box informing me the library is corrupt. The source directory does not have a corrupt library.

See this knowledgebase article for information on corrupted libraries and projects. The article did not show us anything missing in the source and distributed library files (Beyond Compare was useful for this).

We were able to track the corruption down to the documentation. The documentation consists of multiple Word-generated html pages. Each page has a subdirectory with the images, colorschememapping.xml, filelist.xml, and themedata.xml for that html page. The duplicate names in the subdirectories cause the library to become corrupted when the source code is distributed.

Things to note:

1. There are no error message preventing adding duplicate names (at least with xml and image files).

2. The executable build does put all of the documentation files into the correct location, so this is only in relation to source distributions.

Having the documentation included in the library was nice as the executable build placed it in the correct location in the build directory for the installer and the documentation is revisioned with the source code. I've taken the documentation out of the project for the time being; this prevents the corrupted library. The documentation will still be revisioned with the source, however it will require some manual copying to get it to the build directory until we can determine a permanent fix.

Tim

[PaulG.]

I'm integrating Mercurial and re-organizing reuse libraries along with documentation as we speak.

I just finished cleaning up an 8-month-old mess. My code is in shambles. I don't need another headache.

You have my gratitude.

[David Wisti]

(Beyond Compare was useful for this).

I use Beyond Compare everyday, very useful software.

[Tim_S]

I'm integrating Mercurial and re-organizing reuse libraries along with documentation as we speak.

I just finished cleaning up an 8-month-old mess. My code is in shambles. I don't need another headache.

You have my gratitude.

Not a problem. We (Tech Support and I) are still trying to get to a root cause. A coworker sugested moving from hml to xps files this morning (creates a single file); I'm going to look at those as Word can also save xps format.

[Tim_S]

A small update...

Tech support has determined that LV 2009SP1 fixes this issue. I've updated LV 2009 with patch 3 applied. I am still able to recreate this issue on my PC. I'm not sure what's going on but 2009SP1 users may not see this.

Tim