Search the Community

I maintain several machines in our factory, all running various versions of LabVIEW executables. One of the many versions I have installed on my machine is LabVIEW 2018 v18.0.1f4 (32-bit). It's been 'many moons' ago, but I remember updating my 2018 runtime to SP1 f5, but I haven't had to build an installer in 2018 since then. I ran into a situation yesterday where I needed to create an installer in 2018 and left "Automatically select recommended installers" checked, which auto-selects the 2018 SP1 f5 RTE. When I select "OK" in "Additional Installers", the "Select Source" dialog appears with a single entry, which is a 2018 application that I had built and installed on my local machine. Clicking on "OK" prompts for a media path as expected, but I don't have (or can find) and installer for 2018 SP1 f5. Even pointing it to the installer it's referencing (that I created) gives me an error message stating that the "...media you have provided is a different version of the requested media" (which it isn't). I ended up giving up on creating an installer in 2018 and recompiled everything in a later version of LabVIEW since I needed to get an update deployed immediately. However, I am curious whether anyone has any insight into this. I can't be the only one to have seen it.

Hallo, I have done some manteinance to an application compiled with LabVIEW 2012. That app has an installer, so my users can upgrade it easily. I usually install the application on the same machine where I develop with LabVIEW and after I try the installation procedure on a clean machine to see if issues arise. Today have seen that on the development PC, the executable runs fine. Instead on the clean machine, the following message appears after that the application has loaded the panel. Have you seen this message in past? I have found some posts here: other users have found the same issues, with older versions of LabVIEW. forums.ni.com/t5/LabVIEW/VI-has-an-error-of-type-2208-42308-302208/td-p/1540496 I have upgraded the DAQmx drivers on the clean machine , but the issue remains. Any idea?

Hey all, (Cross-post from ni.com forums) We have a LabVIEW application, which has a LabVIEW-based Installer. This LabVIEW installer is called from within another Inno installer (since our main Inno installer pulls together multiple components, most of them not LabVIEW). Whenever this Inno installer ends, it always asks the user to restart their PC, even if the LabVIEW installer was cancelled. I narrowed it down, and it's reproducible with only the LabVIEW installer, so it's definitely LabVIEW installer's fault. According to Inno's help documentation, "if a program executed in the [Run] section queues files to be replaced on the next reboot (by calling MoveFileEx or by modifying wininit.ini), Setup will detect this and prompt the user to restart the computer at the end of installation." However, as stated above, this dialog is triggered even if the LabVIEW installer was cancelled and wrote no files. Now, the above linked documentation refers to a flag I can put in my installer script to ignore this restart dialog, but it's a global flag, and I would like my other installers to still make use of this handy restart dialog if necessary. Unfortunately it seems LabVIEW installers trigger this even if not actually necessary. Has anyone seen this before? Any ideas how to make my LabVIEW installer NOT muck around with the MoveFileEx or wininit.ini stuff if/when it's not actually needed? Attached is a LabVIEW project and Inno Installer script which easily reproduces the problem. To reproduce: Extract the attached .zip Open test.iss in Inno Setup and click the "Run" button Alternately, just run the built installer under "\Output\test_inno_installer_9.99.0.0.exe" Click Next on 'Select Components' dialog Click Install on 'Ready to Install' dialog When LabVIEW installer pops up click Cancel, then yes (you're sure) See the Restart dialog Thanks! David_L InnoLabVIEWBug.zip

I am sure that a lot of you already knew what the "add property" button does in the installer build specification, but I am so happy about this discovery and I couldn't find anything online that I decided to share my excitement with my friends in LAVA. The application I am building works with a third party software that requires my installer to add things to the %appdata% folder, in Windows 8 this translates to C:Users<username>AppDataRoaming The default destinations available in the installer build specification in LabVIEW includes the [Public App Data] but in Windows 8 that points to C:ProgramData The help says that clicking on the Add property button under the Destination View lets you add a new MSI property to the Destination View tree. You can find a list of MSI properties here: http://msdn.microsoft.com/en-us/library/aa370905.aspx#component_location_properties and in particular there is one called AppDataFolder http://msdn.microsoft.com/en-us/library/aa367565(v=vs.85).aspx Well, adding the new property AppDataFolder was enough to set the destination for my ThirdPartyApp and the installer now successfully installs files in %appdata% folder. I hope this helps others in search of this information. Regards, Fab

I have dutifully been creating new Executable Versions each time I make any changes to my application and then creating New Installers with this new executable. For the Installer I did not click on the "Generate" button to change the Upgrade Code in the Version Information category - the Installer does this automatically. ie. each new Installer had a new Upgrade Code. Now each time I have run the NEW Installer version it automatically uninstalls the old version and installs the new version - all very nice and simple But today I needed to go BACK a version so I ran the previous installer expecting it to automatically do the same thing, but it won't let me. My questions are: 1) Firstly can this be done, or can you only upgrade to newer versions? 2) What is the "Generate" button for if the NI Installer generates a new Upgrade Code anyway? 3) How can I get the NI Installer to upgrade and downgrade and application? Chris

Hello everyone, I recently installed LabVIEW 2013 on my development machine to get rid of some issues in my current project. However the project is originally build in LabVIEW 2011, so I had to save all VIs for the new version (no issues ) I'm still able to build the application executable with no problems too! Now I want to provide an installer for the customer to upgrade the Runtime engine and some additional stuff that has been changed for LabVIEW 2013. And there lies my problem, as I'm currently unable to build an installer. The configuration dialog shows 'error generating preview' for any executable in the project: Naturally I tried to generate the preview in the executable, but there seems to be no issue: Creating new specifications did not solve the problem and even creating a whole new project file and including the startup VI to it + creating new specifications did not solve the problem... I made a new project with a single VI for testing if the application builder is not working in general, but thats not the case, as I was able to create an application + installer with no issues. So I'm quite sure there is something wrong in my project that causes this behaviour, but I've currently no clue what that could possibly be. I read somewhere (in the NI forums I guess) that there could be issues if you have files in your project that are build in an older version (as one of the dll files), so I upgraded it... with no success... Now does anybody had an issue like that in the past / currently and is there anything I could do or check to regain the ability to provide a proper installer? What could possibly cause the installer dialog to fail generate a preview where the application dialog is successfull? Any ideas are welcome

Hello, all! I am new to the forum. I've been working on and off in LabVIEW development. One of my projects requires that I build a VI to download information from a PLC. The information is laid out in an excel file, where a macro is programmatically ran to convert the info for a more user-friendly look and read. When I packaged the VI into an executable and an installer, it's all smooth sailing. However, when I tested out the installer on multiple computers (with no LV or LV-RTE), a few took 5-to-10 minutes to finish installation. Others got stuck early in the install process...commonly when the process is installing "Microsoft Run Time Engine". On one computer, the installation process was cancelled and restarted multiple times without success. Then, the next morning (after a reboot), the installation worked without issue. On another computer, I did the whole "install-cancel-restart install" process. After three times, I checked the task manager and noticed there were equally as many msiexec.exe files still running even after the installations had all been cancelled and closed. I ended all of the msiexec.exe processes, ran the installation again, and it ran smoothly from 0 to 100%. Although it's great that I got the installer to go through smoothly after ending the msiexec process, this cannot do as the solution to get through a full installation. Has anyone ever run into this issue?

Is there an easy way to get the destination directory the user selects during custom executable installation? There are probably some ways to get it using a post installation application, but it seems like a cludge. Ideally what I'd like to do is create a registry entry during installation that records the installation directory.

Just for the sake of my own curiosity, I was wondering if anyone knew what is "wrapped" in the NI builder in order to create installers? Is the .NET Installer class being used to create installers, or something else? I was also wondering if there is something like the OpenG MSI Installer Builder that can be used with newer versions of LabVIEW? It seems it can't be used after LV7.1. I really like the idea of being able to customize my installers to look a little less plain during installation. If not, I wouldn't mind throwing my own together if someone could point me in the right direction. Or, even if one does exist, I wouldn't mind writing my own for the sake of learning. Thanks.