Build specification of installer hides already spec. destination

I have an installer build specification with the following problem with the "source files" dialog:
I select the exe build spec to be installed into a certain dest. dir (e.g. under program files). After doing so i close the dialog with ok. The next time i open the dialog this information seems to be gone, in the dest. view no folder has subfolders or other files below it. But if i repeat my steps from the first time, trying to install the exe into the same dir under program files, i get this error message:"The following files already exist in the destination directory:...". But i can't see them!
Any ideas?
This is Labview 2009 on Vista.
Holger

Perhaps they were written (somehow) as hidden files.
This way, if you browse to that location, you will not see them.
But if you try to save something with the same name, the computer will know the files are there.
Cory K

Similar Messages

How do I include a dll in a build specification and/or installer?

I have a custom "wrapper" dll built with VC++ that I need to include in a LabVIEW Build Specification and/or LabVIEW Installer. It needs to be installed in the C:\Windows\System32 folder.

Good morning!
You can set your support files to install
in a separate directory than your executable. In the build
specifications for your EXE, select the Destinations category and change
the path for the Support Directory to C\WINDOWS\System32 as shown
below.
Then go the Source File Settings category and set your dll to install in the Support Directory, as shown below.
Let me know if this works!
Take care!
Tanya V
National Instruments
LabVIEW Platform Product Support Engineer

Scrambled destination view in installer build specifications LV8.5

I don't think this build specifications bug has been mentioned yet. I am using LV8.5 Pro under Win XP.
When configuring a new installer build specs, under Source Files, I select my application item in the Project View and click on the arrow button to add it to the Destination View. The latter then faithfully reproduces the application files hierarchy, for example:
Application Directory
    Manuals Directory
       Manual.pdf
    Application.exe
    Application.ini
    Startup.exe
    Startup.ini
However, after I close and reopen the installer properties, the Destination View hierarchy appears scrambled, for example:
Application Directory
    Manuals Directory
       Startup.ini
    Application.exe
    Application.ini
    Manual.pdf
Supporting files get moved around the directory tree, some disapper, and others actually appear in duplicate. The outcome is exactly the same every time I repeat this process, but there is no apparent pattern to it.
Now, when I actually build the installer and later use it, the application gets installed properly, with correct files hierarchy. What doesn't work are the shortcuts. For instance, in the above example, if I create a shortcut to Manual.pdf, it will actually point to Startup.exe. And if I need a shortcut to Startup.exe, I cannot create it because the target is not part of the Destination View.
Thoughts?

Dear Zador,
Bug number 4CM921LJ titled "Shortcuts Added in Installers Are Not Created Properly" is a LabVIEW 8.5 Known Issue. More information on the bug can be found in Knowledge Base 4EGEL6HY: Wrong or Incorrectly Disabled File Names Displayed in LabVIEW
8.5 Installer Builder. If you need an alternative to the workaround presented in the Knowledge
Base, you can create separate folders for each file you need to have a
shortcut created for instead of putting them all in one.
This issue has been fixed in LabVIEW 8.5.1. Please post back bug 4CM921LJ does not describe your problem.

Build specification Destination Does Not Preserve Hierarchy

I have a destination configured in my build specification (application) so that I can include required LabVIEW and non-LabVIEW files in my builds. This destination is configured as a directory with "Preserve disk hierarchy" checked. Under "Source File Settings", I have one of the folders in my project configured to use the aforementioned destination.
There are two issues that occur when I build my application. The first is that it ignores empty folders entirely. The second is that I have one folder that contains files (this folder is a child of the folder that is listed in the build spec) and when I build, it completely ignores the child hierarchical step. I.e. It omits the child folder completely and put's the child folder's contents in the parent/top-most folder. E.g.:
Source:
source/ParentFolder/ChildFolder/file1.ext
source/ParentFolder/ChildFolder/file2.ext
Build Result:
builds/ParentFolder/file1.ext
builds/ParentFolder/file2.ext
If I put a dummy file (or another child folder with a dummy file) in "ParentFolder", it will then actually preserve the hierarchy of the files (empty folders are still ignored though). Note that the ParentFolder is "Always Included" under the build spec's "Source Files".
I need to be able to preserve the hierarchy without having to use a dummy file (this would be extremely confusing and could get deleted easily by future developers) or having to remove this hierarchical step in the folder structure (this code was inherited).
I'm using LabVIEW 2013 SP1.

Actually this has been discussed before -- a lot. The builder will not create an empty directory, and it only counts files as contents.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Building exe with installer

I am using Ni DAQmx and Labview 2009 professinal. I tried to build an exe and distribute it to my team. Initially they had issues
opening the file and instead opening the login screen it opened a main GUI screen with the errors as shown in output.jpg. I did some
search on this forum and I thought I will build the installer with LV runtime engine, DAQmx 8.5, MAX import ini file and send the msi
extension to my team. But on the process of building this I get the following error as shown in ni_install.jpg. When I select DAQmx
8.9.5 the build becomes unsuccesfull. Please need some help to resolve this.
Thanks
Attachments:
ni_install.jpg ‏99 KB
output.jpg ‏159 KB

My problem is building the installer before giving it to my team. When I right click "Build specification" and create installer I get
application properties.
Product info: Provided my installer destination and other info
Source Files: I provided my exe into destination view - program files folder
Additional installer: I choose DAQmx, labview runtime engine 2009, MAX
And I filled all the info on the property setting window. With all this it comes up looking for NiDAQmx and defaults to drive CD drive.
Should I use my DAQmx CD at this point and then build the installer. Is it ok to build the .exe and then create the installer.
Thanks

Build specification missing properties

I have created a build spec for my project but the tabs for Dialog Information, Shortcuts and Additional Installers are missing. See attached screen shot. How do I make them appear?
David
Solved!
Go to Solution.
Attachments:
My build spec.png ‏81 KB

You will create two specifications: (1) build the exe. (2) build an installer for the exe. One you have both in your project, you can do a "build all" when right-clicking the build specifications section header.
LabVIEW Champion . Do more with less code and in less time .

Dynamically configure build specification version number

I have several build specifications in the same project under the same version control and I base my version numbers in part on my revision number:
<Major>.<Minor>.<Revision>
Right now, I'm keeping the full number in a text file which is distributed with all build specifactions. However, I notice the build specification configuration diaglogue contains an option to execute a VI before the build. I'm wondering if a VI executed at this stage can somehow edit the version number within the build specification that called it, such that I don't have to manually change the version number in every build spec, every time I want to build one.
Are there any canned functions that let you edit build specification things like version numbers?

Hi Kgolden and A. Zaatari,
Maybe it's not a current feature (I have to believe a NI Engineer ) but it's possible to do it.
I made a VI that automatically creates Build and Installer specifications and also changes their configuration (like name, path, and version number).
So, here is how:
- all this information are stored in the project file My_Project.lvproj
- My_Project.lvproj is actually a !!! XML file !!!
- Make a small VI that search in the XML for the following lines/properties:
      (1) App_fileVersion.build
      (2) App_fileVersion.major
      (3) App_fileVersion.minor
      (4) App_fileVersion.patch
For the App_fileVersion.build it should look like :<Property Name="App_fileVersion.build" Type="Int">115</Property>. Search for the pattern and change the value 115. Do the same for all four of them.
Pay attention!! After you change this value you have to restart (close and than open) the Project in order to apply changes. This can also be done automatically by using LabView Application invoke and property node: Invoke Node: Project/Close + App/Open.LV Document/Path. Be carefull that you should do this from a VI that is not added to the project.
Regards,
Paul

Pre Build EXE and Installer Set Version

So this topic comes up relatively often so I thought I'd make a new thread showing an example of how to make it work. The problem is developers want a way to set the version of builds programmatically. Luckily NI added some VIs for doing this. Too bad you can't invoke them from the Pre-Build action of a build, because that information is read before the pre-build. Here is an idea exchange discussing it.
But I figured I could come with some kind of work around and I have two, and neither is perfect. Attached is a simple project. It contains a VI that runs reading the EXE version that it is running from once it is in an EXE. The project has three build specifications, an EXE, and two installers. The developer can set the Major, Minor, and Fix of the EXE, but the build version is set programmatically in the Pre-Build action. The version of the installers will also be set to the version of the EXE.
Attempt to build the EXE and a dialog will appear asking to enter the build version that should be used. This could be determined some other way but this was the easiest for the demo. If the EXE, and the Installers are already the correct version, where the build is the same as the one specified, and the installers are the same version as the EXE, then the build goes on like normal. But if the build you enter is not the same as the current, it will abort the current build, change the versions, and then tell the operator to attempt to build again. This time no prompt is seen and the build will work like normal with the version you set earlier.
The downside to this method is you have to tell the developer to build again, I figured I could do that programmatically so I tried. There is a constant on the BD of Prebuild Action VI.vi, and if it is set to True it will try to invoke a new build on its own. The problem with this method is the build the user invoked is aborted and the user sees the error. But the second build might have worked fine, but there isn't any feedback.
In any case this is a sorta working way of setting EXE and Installer build versions from a pre-build VI.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.
Attachments:
Test EXE Version.zip ‏80 KB

Bob_Schor wrote:
I took your idea and "simplified" it a little
Some may want the simplified version I understand. But for me I wanted a more robust VI, one that would work if a project had multiple build specifications of applications, or multiple installers. Some developers may have two applications one that is normal, and another with debugging turned on and I wanted the versioning to work consistently there by grabbing the newest version and using it. And in all my cases, if there is an installer it should be the same version as the EXE.
As for the getting around the error I think if I had enought time I could dig into the NI VIs to get rid of the error and show the progress of the new build. The whole build process is a bunch of VIs, that augment the right click menus in the project so the source is there it is just taking time to understand it.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

How can I configure a Build Specification to install for current user only

Is there any way I can configure an installer build specification to install my application to the current user's folder? This does not seem possible at first glance due to the limited "destinations" available.
Ideally I'd want the application to be placed in "C:\Users\[USERNAME]\AppData", or some equivilent where it'd be protected from being run by other users without administrative access.
Has anyone been able to do this? Thanks!
CLA, CCVID, Certified Instructor

There is a destination called [Personal] that goes to the user's MyDocuments folder. Whether program files should be mixed with a documents folder could be debated.
I see the [Public App Data] choice, but I don't see a [User App Data] option.
Another possibility would be to allow it to go to Public App Data, but after the installation, run a VI that then moves the program folder to the User's Application Data directory. However, that probably means updating shortcuts as well. And I don't know whether that VI would essentially step on itself in trying to do that move.
Maybe another choice would be to allow it to install to the program file directory, but use CACLS to prevent users from accessing that directory except for explicit permissions to the one or more users you want to allow to execute it. An advantage is it would allow one user to install a program for another user to use. The disadvantage is the person doing the installing would almost certainly have to be an administrator.
A disadvantage of the method you desire is that a user has to be the person logged in and install it for themselves (assuming that group policies allow non-admin users to install their own programs). Another disadvantage is if you want to have more than one permitted user, it would need to be installed multiple times, one for each.
Perhaps you could install security at the front end of your applicaiton. Anyone can run it, but the application determines if the currently logged in user is permitted to run it when comparing against some sort of encrypted file that lists valid users. If the user is permitted, the program moves onto normal operation. If not on the list, the program tells them so and never advances onto normal operation.
Perhaps someone else can determine if there is a path tagged within the installer builder that goes to the User App Data that I am missing.

Use of "Open FPGA VI Reference" function --- Build Specification vs VI vs Bitfile

When using the "Open FPGA VI Reference" function in a LV2012 cRIO application, there are 3 options: Build Specification, VI, or Bitfile. What would be the reasons for selecting one over the others? Does it affect the resulting startup.rtexe when the cRIO application is built? I searched through the help and in these forums, but I don't see criteria for selecting one over the others; maybe I missed it.

Hello Chris,
Apologies in advance for a long reply.
The reference method won't change the functionality of your rtexe.exe. They all end up dropping a bitstream, based on a bitfile, onto the cRIO's FPGA.
To a degree, the method used to reference the FPGA code is a matter of taste, but there are situations where one method is better suited than the others.
Reference by VI:
Setting the configuration options to open reference by VI is helpful during development when you are making changes to an FPGA VI often and building/testing using the same spec. When this option is used, a bitfile is selected based on the default build specification for the project. A project may have only one default build specification. You can make any build the default by checking the option under the Source Files category in the build properties. The default build is indicated in the project explorer by the green box around the builds icon.
Reference by Bitfile:
This option references a bitfile directly. Through the configuration window, you can select one specific bitfile to open a reference to (this is not dynamic and does not change unless you physically go make a change to that path). If you're using this method, it helps to give your bitfiles more meaningful names than the ones that are automatically generated by LabVIEW. When you run subsequent compilations off of the same build specification and do not change the bitfile nname or path in the build configuration, the old bitfile is overwritten and replaced with the new one. When you are using this option, it is critical that you keep up with which bitfile is the one you want to be using. There is an option now that will help alleviate any problems referencing by bitfile through the Open FPGA VI Reference function. There is a new VI called Open Dynamic Bitfile Reference. It is typically used when you want to chose a specific bitfile to load depending on something in your host code (a configuration option etc) - but it allows you to dynamically reference a bitfile on the block diagram by path.
Referency by Build Specification:
This option is good for when you want to always use a bitfile that is associated with/compiled with the same build configuration. Say you have two options for top level FPGA VIs in your project (each with its own build spec). Both of these VIs have the same interface (read/write controls, DMA) but they run different algorithms or something. This is nice because you can easily switch your host application between them by picking the build spec associated with the FPGA VI you want to use. In this type of sutation, referencing by VI is no good because you can only have on default build spec.
cheers.
Matthew H.
Applications Engineer
National Instruments

Instrument Control Build Specifications

Dear Sir:
      I am trying to build a working *.exe instrument control program. This is a simple program which only queries my test instrument with a *IDN? command.
      The program fails to call my instrument driver and the program also runs on boot up when (running under normal conditions) it should wait for me to input the GPIB address of my test instrument.
      Let's begin with the failure of Labview to communicate with the instrument driver.   This is some background information.
       When I run the program as simple *.VI in the Labview environment, the program runs perfectly.    No issues.
       When I use Agilent Connection Expert or MAX to communicate to the test instrument, communication is established and there are no issues - I receive a reply, connectivity is established.
        After I build the *.VI into a *.EXE program, this is where the program's issues arise.
       The *.EXE program fails to initialize correctly and fails to establish connectivity with my test instrument.
        Here are some issues that I have noticed about the program running in *.EXE mode
1) The program runs on "boot up" when you click on the *.EXE program.   In *.VI mode, the program does not run on boot but waits for the user to input the GPIB address of the test instrument - program run is designed to be enabled by the user.
      I do not believe this is the source of the problem but only an incidental consequence of the problem.   If I stop the program and input the GPIB address, I receive a message about not being able to communicate to the driver.
2) Once the *.EXE program runs, there is a condition whereby the operating system cannot close the program and WINDOWS itself cannot shut down itself unless I manually close all the programs associated with the *.EXE program in the WINDOWS operating environment.
3) If the labview program and *.EXE program are closed but the operating system is still running, Agilent Connection Expert and MAX can no longer communicate with the test instrument.   They no longer see the test instrument.
It is obvious that the *.EXE program is making a change which is causing the operating system to "hang" on shutdown and is also preventing the other programs from operating as they should.
I believe the source of my problem may be how I programmed my build specifications.     In reply, can you please tell me what are the minimum requirements for the build specification so that my test instrument can reply to a simple *IDN? query?   What files are normally required for a successful build?
Other information as to the source of my issues are welcome as well.
Thank you.
Solved!
Go to Solution.

Thanks for you advice.
I think this problem is a lot easier than you might think.   I just started using Labview and the *.VI is super simple. I am away from my development computer right now so I can't post it.
The information I need to know right now are the typical files that are needed to be added in the build.
I found this quote that I found on a webpage to be interesting, (although I am not building an installer):
" Do I need to include NI-488.2 2.7.3 module if I use only basic GPIB Write.vi and GPIB Read.vis in my project?
Yes, if you are making an installer ..."
This is a link to the webpage:
http://forums.ni.com/t5/LabVIEW/Uninstalling-LabVIEW-after-an-application-EXE-build/td-p/1553310
My program involves only simple reads and writes using NI-488.2 calls to a test instrument.   A simple list of files specified with filename extensions to get me started would be appreciated.

Labview project build specification

I created a LabVIEW8 project. WIthin it I have a few folders that organize my code. I'm trying to create a Build Specification (found at the bottom of the project view). I created a new Build Spec and began populating it. I can add information to all fields, except the Source Files category. When in the Source Files category I'm able to specify the Dynamic VIs and Support VIs in the bottom box by selecting Full OI - Top Level VI.vi. However, when I try to select any single file (Launcher.vi in this case) as the Startup VI, all my VI files become grayed out. I can't select any of them. I tried placing my launcher file in a new folder (apart from the majority of my code). It allows me to move the folder into the Startup VIs area, but when I say 'OK' or 'Build' at the bottom, it comes back telling me that it can't continue because I haven't selected a Startup VI. Any ideas?

Have you tried saving the project and trying again. I tried to create one on the fly and it wouldn't allow me to select it as a top level VI until I saved the project and the VIs in the project. Give that a try and let us know how it goes.
Tyler H.
National Instruments

RT Build Specifications: Component Definition Category is unresponsive

Hi,
I am using LabVIEW 2013 SP1 f2, with Real-Time 13.0.1
When I open the Properties page for a Real-Time Application build specification (to run on a cRIO-9075), and select the Component Definition category, I find that the following occurs:
- LabVIEW becomes unresponsive, and thinks for a while. It takes approximately 20-30 seconds or so to finally show the Component Defintion page.
- When I click on Create a component definition file (.cdf), nothing happens. As I write this, I see "Required software components", and then these are greyed out: "Software component description", and "Software version" - but there is nothing to select or change?
- If I click on another category, it takes in the order of 20 seconds to finally show this category.
- To close the build spec (by pressing OK), it also takes a long time (more than 60 seconds).
- Things are fine with the build spec if I never enter the Component Definition category.
Is anyone else experiencing this?
Any help would be appreciated.
Christopher Farmer
Certified LabVIEW Architect
Certified TestStand Developer
http://wiredinsoftware.com.au
Solved!
Go to Solution.

Hey Chris,
I believe the following patch is the fix that you are looking for.
LabVIEW Real-Time Module 2013 SP1 Application Builder Patch Details
http://digital.ni.com/public.nsf/allkb/D72B45C6905D327A86257CC800547992?OpenDocument
There's a link to download the patch at the bottom of that page.
Regards,
Ryan

Missing Build Specifications in LV8 Full Development package

After installing LV8 Full Development Version, the only Build Specification option available is "Source Distribution". The options "Application", "Installer", "Shared Library" and "Zip File" are missing. The correct serial number appears on the About screen so I assume I activated the package correctly.
How do I make those other build options available?

Buy the application builder - or upgrade to the professional version...
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Some build specifications change on different machines

Hi all,
I often need to move my LabVIEW projects from a machine to another one. In this cases, I copy all the contents of my project folder in the new machine.
My projects are built without errors, but some build specifications are not kept.
Build specifications that are not maintained are additional installer list (see attachment).
In the machine 1, I include only Math kernel Libraries and NI VC2008MCMS.
When I open the same project on the Machine 2, all the elements in NI LabVIEW Run-Time engine 2012 SP1 f3 list are checked. (see attachments)
Thank you
Attachments:
machine1.png ‏5 KB
machine2.png ‏5 KB

Hi AC_85,
have machine 1 and machine 2 the same installed software? Is it the same version? Maybe on the machine on which you copy your project some additional installer is not installed.
You could try to Duplicate the entire project (from project explorer File >> Save as >> Duplicate project >> Include all dependencies) before moving it from machine 1 to machine 2.
Hoping this will help you.
Best Regards.
Cla_CUP
NI ITALY

Build specification of installer hides already spec. destination

Similar Messages

Maybe you are looking for