Application Builder refuses to remove an included file!?!

[Justin Goeres]

I am on WindowsXP Pro.

It appears that once an "Always Included" file has been added to an EXE Build Specification in LabVIEW 8.5, it is impossible to remove that file from the Build Spec later on. This, you will note, makes it impossible to edit your EXE Build Specifications.

To illustrate, the following image shows a simple project with an INI file included (the project file is attached below). Open the EXE Build Spec, and note that the file supportfile.ini has been manually included in the build. Remove the file from the build, then click OK.

http://forums.lavag.org/index.php?act=attach&type=post&id=6838

Now go back to the Project Window and open the Build Spec again. Note that supportfile.ini is still included..

http://forums.lavag.org/index.php?act=attach&type=post&id=6839

The file is not referenced anywhere in the project. In this particular case, the Main.vi is actually blank, and supportfile.ini is an empty file.

Note that you can still keep adding files to your Build Spec with impunity. It's like a Black Hole .

Can anyone else confirm this? Does anyone have a suggested workaround?

Example Project File:http://forums.lavag.org/index.php?act=attach&type=post&id=6837

[Jim Kring]

In the "Build Specifications" section of your project file, try changing this:

<Property Name="Source[0].itemID" Type="Str">{09BB8071-8023-44FD-80C1-5C2EA6D03A94}</Property><Property Name="Source[0].type" Type="Str">Container</Property><Property Name="Source[1].destinationIndex" Type="Int">0</Property><Property Name="Source[1].itemID" Type="Ref">/My Computer/Main.vi</Property><Property Name="Source[1].sourceInclusion" Type="Str">TopLevel</Property><Property Name="Source[1].type" Type="Str">VI</Property><Property Name="Source[2].destinationIndex" Type="Int">0</Property><Property Name="Source[2].itemID" Type="Ref">/My Computer/supportfile.ini</Property><Property Name="Source[2].sourceInclusion" Type="Str">Include</Property><Property Name="SourceCount" Type="Int">3</Property>

To this:

<Property Name="Source[0].itemID" Type="Str">{09BB8071-8023-44FD-80C1-5C2EA6D03A94}</Property><Property Name="Source[0].type" Type="Str">Container</Property><Property Name="Source[1].destinationIndex" Type="Int">0</Property><Property Name="Source[1].itemID" Type="Ref">/My Computer/Main.vi</Property><Property Name="Source[1].sourceInclusion" Type="Str">TopLevel</Property><Property Name="Source[1].type" Type="Str">VI</Property><Property Name="SourceCount" Type="Int">2</Property>

Note that you have to decrement the "SourceCount" value (from 3 to 2, in this case), in addition to removing the "Source[2]" items.

[Justin Goeres]

BAH! Jim posted over me while I was tweaking my self-reply! Oh well, I'll leave mine here because I have a screenshot

I was able to get LabVIEW to remove the support file from the project by editing the XML of the .lvproj file. It's not that tricky an edit, so it may be a solution for other people, as well.

Open the .lvproj file (in this case, Build Spec File Removal Bug.lvproj) in Notepad. Find the section of the XML for your build spec (e.g. <Item Name="My Application" Type="EXE">). In that section, find the lines that correspond to the file you want to remove (highlighted in yellow below). Delete those lines and save the file. When you open the Build Spec in LabVIEW the next time around, your file will have been removed from the build.

http://forums.lavag.org/index.php?act=attach&type=post&id=6840

There is an item in the XML for the Build Spec which keeps a count of the total number of source files in the build. It seems that it is not necessary to update this value, nor is it necessary to edit the index numbers of the remaining files. I tested this workaround with two different support files in the build, and was able to manually remove either one (or both) by this method without any problems.

[Yair]

By the way, for those working with XML, I would suggest checking out XML Notepad (from Microsoft, I think). It makes dealing with certain aspects of XML very easy, although I wouldn't be surprised if there were more powerful XML viewers\editors around.

[Justin Goeres]

QUOTE(yen @ Sep 3 2007, 12:16 PM)

By the way, for those working with XML, I would suggest checking out XML Notepad (from Microsoft, I think). It makes dealing with certain aspects of XML very easy, although I wouldn't be surprised if there were more powerful XML viewers\editors around.

Here's a link to http://www.microsoft.com/downloads/details.aspx?familyid=72d6aa49-787d-4118-ba5f-4f30fe913628&displaylang=en' target="_blank">Microsoft's XML Notepad 2007 download page.

[Jim Kring]

QUOTE(yen @ Sep 3 2007, 12:16 PM)

By the way, for those working with XML, I would suggest checking out XML Notepad (from Microsoft, I think). It makes dealing with certain aspects of XML very easy, although I wouldn't be surprised if there were more powerful XML viewers\editors around.

I've been using MS XML Notepad for a while now and love it!

QUOTE(Justin Goeres @ Sep 3 2007, 09:55 AM)

BAH! Jim posted over me while I was tweaking my self-reply! Oh well, I'll leave mine here because I have a screenshot

Hehe. Sorry

[Justin Goeres]

This issue has been confirmed with NI. I'm awaiting a CAR on it.

[gmart]

One thing you could do is remove the problem file from the project. When you load the build specification again, it will not be present. This is not ideal, but it should get you going without having to manually edit the project file. Also, it seems the problem only affects non-VI files. If you have the same setup with a VI, you will not get the same behavior.

[Justin Goeres]

QUOTE(gmart @ Sep 4 2007, 08:08 AM)

One thing you could do is remove the problem file from the project. When you load the build specification again, it will not be present. This is not ideal, but it should get you going without having to manually edit the project file. Also, it seems the problem only affects non-VI files. If you have the same setup with a VI, you will not get the same behavior.

That won't work, however, if the file in question is in an auto-populating project folder -- you can't remove it individually from the project. That's the situation in my case (not the test case I posted), but in other cases your workaround would work.

You're right about the file types -- it does not happen with VI files.