Jump to content

Recommended Posts

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.

Link to post
Share on other sites

I'm not quite sure what you're asking, so I'll answer the question I think you are asking, because I know the answer to that question.

In the past I've used Inno Setup to make software installers. Part of the installer has the ability to have standard installs, custom, minimal, and settings for what to do based on the users selection, as well as installation directory and what to do during an uninstall. I've used this in the past to install several NI components at once. Lets say I had LabVIEW Run-Time engine, the TDMS for Excel Add on, and maybe any number of other NI installers, in my build. Then each of these can be a checkbox during the install, which will simply run the setup.exe for each component, with what ever silent switches that are needed. I've also used ISTool which is a piece of software that helps make Inno Setup installers.

I don't believe there is much for UI customization, I've always used the plain one.

One thing I would be interested in is how JKI does it for VIPM. I'm guessing what they do is very customized and probably not something worth sharing.

Edited by hooovahh
Link to post
Share on other sites

What JKI does with VIPM, is making an executable, zipping the executable up.

Store that zip as a string inside a VI. Then use the installer VI to extract the zip-stream.

(you notice I cut some corners in this process, and this is all just guesswork [citation needed]).

Ton

Link to post
Share on other sites
In the past I've used Inno Setup to make software installers...I've also used ISTool which is a piece of software that helps make Inno Setup installers.

Strongly agree - I use these when I find the NI installer lacking, or need to bundle several NI and nonNI installers together. Inno Setup is super powerful, and free (although I strongly suggest you make a donation if you find it useful to support continued development a support of future installer/OS versions).

Link to post
Share on other sites

What JKI does with VIPM, is making an executable, zipping the executable up.

Store that zip as a string inside a VI. Then use the installer VI to extract the zip-stream.

Ton

That's one way of doing it. If I was going to make my own installer, I would build an EXE with LabVIEW 7.1 or older, so that the runtime engine can be included. I would put my real EXE (built with modern LabVIEW) in a subfolder along with any support files (possibly the required runtime engine as well). Then zip all that and convert it to an EXE that runs my 7.1 EXE after getting extracted to a temp folder. That way there is only one EXE to the user, that they run, extracts and runs a LabVIEW EXE and runs without any runtime engines installed, and from there can install my application or other components.

Of course coding in 7.1 isn't impossible, but there are some functions that are taken for granted that I may have to code my self which were not available then. Also I'll essentially be including two run time engines. The 7.1 runtime engine was around 12MB zipped up so it won't add alot of space but still is extra code that won't be used after the install.

I've never done this approach, because it is re-inventing the wheel and supporting a tool seems like a pain, for very little added benefit.

  • Like 1
Link to post
Share on other sites

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.

They use the MSI API which is basically the official low level API to the Microsoft Installer technology. It's a super complex system based on a relational database system to manage all the packages, versioning, dependencies and what else that a packaging management system needs to maintain. There are probably higher level MSI interfaces based on .Net and ActiveX but the core API is a pure DLL based interface in MSI.DLL but I doubt would be useful to try to interface with the Call Library Node directly. NI uses a DLL interface that was probably developed by the LabWindows CVI group to support creating installers from applications developed in it.

I have read some time ago a comment by a former member of the MSI developer group, who admitted that choosing for a relational database system for this, was probably more than a little bit of overkill but that once that decision had been made there was really no way of going back and changing much anymore.

The whole MSI technology used is therefore really Windows provided, and the application builder just uses a higher level API that allows the minimum amount of customization to this functionality that is required by the NI application builder. It could of course provide more flexibility but the cost of such a solution is simply enormous, the knowledge to use these options rather high, and therefore unlikely to be used by most.

I believe that the OpenG Builder did interface to an undocumented VI to plug into the application builder part of the MSI component and LabVIEW 8.0 changed the entire Application Builder so that the OpenG Builder broke. However at the same time NI documented part of the application builder VI interface so that it was possible to access those methods outside of the project interface.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By David_L
      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
    • By Gan Uesli Starling
      We have a gage supplied by a company that shipped it with a *.exe application targeted for LVRTE 2009. I need to retarget it for 2017, but don't have the source code. The supplier had said they'd gladly supply me with a copy of the *.LV source, but they have looked and cannot find their own copy in-house.
      History of Need: Our global corporate mother ship's IT department, in their infinite wisdom, is mandating an upgrade from Win7 to Win10. That with yet even further constraints. They enforce a list of "approved versions" of "approved applications". And for LVRTE, they are insisting upon 2017, with 2009 being a red light.
      So, then, my query. Is converting an app without the source for a higher LVRTE doable at all? File is attached.
      If it is doable, instructions on how?
      Concentricity-Gage.exe
    • By Dawid
      I'm trying to execute LPR.exe command to print some labels on a printer. However as its normal, problems occur. I could not find answer on any topic conneced with "sytem exec". I already tried all described methods (I think so). That's why I'm asking very kindly for any help.
      When trying to execute or call the LPR.exe from System exec VI, I'm receiving error:
      "'C:\Windows\System32\lpr.exe' is not recognized as an internal or external command, operable program or batch file."
      Generally I would like to call function: "lpr -S 192.168.1.5 -P lp C:\test\do_druku.txt" which works from command window without any problem.
       

      print.vi

    • By Huqs
      Hello Labview Users, 
      I happen to have thousands of csv data file that I work with. The only way I recognize them is putting their characteristics in the file name. Which brings the problem of making the names too long and Microsoft doesn't like to accept long name. So I wanted to build a database for all my files. I am in the preliminary stage of building it ( I have attached the file and some of you may have seen it before). 
      What I want to do is, have all my files in the database with random names and list them based on their characteristics. I want to do that in my application in the place of 'file' box. So that I can click on the file and run it (double-click on the file in application to make them work in active file). based on the parameters listed on the database I want to filter them to find any specific file. How the interface of database should look like is shown blow (Image) . 
      It doesn't have to be a real database, just a directory application. I am trying to make it without the database toolkit.  If anyone can help me out and guide me out or guide me in the right direction then that would be great. Thanks. 

      Multicolumn list box v1.5.vi
    • By PatCarbo
      Hi!
      I am looking for a Senior Software Developer to work on our LabVIEW based sensors and applications.
      I am also looking for Senior Software Developer(s) available for contracts (somewhat local to London) .
      Please note that this is about product development in LabVIEW (as opposed to test development).
      More info here: https://silixa.com/about-us/careers/
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.