Jump to content

Recommended Posts

So, here is the problem:

I want to access the build version of my EXE with a post build action VI. My goal is to modify the welcome message in the installer build spec to include the build version. If that fails, I want to at least generate a file that can be included with the installer to label the build version. Ideally, I would like to place the build in a folder that incorporates the version in the name. Not sure yet how to accomplish this in an automated way, but the first thing to tackle is getting the version of the EXE.

I have come up with three ways to do this:

1. use project properties to extract this information (so far, a major PITA)

2. extract the information from the project file using XML tools. (also a PITA, just in a different way)

3. after the EXE is generated, use .net calls to read out the version information.

My question is, has anyone already solved this? Do you have a stable and elegant solution you can share? If not, do you have any other suggestions on how to do this?

For the NI guys, why is this so hard? Shouldn't this info be easy to access? Why should it be hard to make an installer that tells the use what version they are about to install?

Does anyone else have their own custom build system that does automated builds to new folders every night/week/etc? How do you do it?

thanks for any help or ideas.

-John

  • Like 1
Link to post
Share on other sites

I don't use the NI build version, however,

This is what I did on my last project:

as a post build for the exe I create a file called <executablename>.exe.info

this file is encrypted with the following contents:

1. build date

2. build version

3. build author (I programatically retrieve the windows login info)

4. 32 bit CRC of the file (my companies proprietary algorithm)

5. Sha-1 hash

6. String (for all the stuff I forgot)

In the exe I decrypt the file (its just a hard coded password) and return those items. I find that the build date is far more useful than the build version, and it constantly gets out of sync anyway if you have multiple people making builds from a source repo. Additionally the exe is able to check that it has the correct version file as it can run a SHA-1 on itself since it was generated after the build.

If the encrypted file doesn't exist, the executable simply returns (unreleased.) This is good while I test on production equipment so that operators don't accidently use something I left on a tester.

Edited by Jon Kokott
Link to post
Share on other sites

Thanks for the ideas. I like the idea of the EXE verification. But, I am trying really hard to stick with native LV build specs and the installer. I just think we should have this kind of feature. Not sure I will be able to pull it off however. Can you modify the installer portion of the build spec from the post build action VI and have the change take effect before the installer build runs (when doing a build all)?

Link to post
Share on other sites

I regularly put version numbers in splash screens etc, especially for things like nightly test builds where it is imperitive the tester know exactly which version they are running.

There is a vi in vi.lib that will natively return the version of an executable, there is no need to bust out the .NET. Sorry, no LabVIEW on my phone so I can't comment where it is or what it's called.

The problem of course is it requires an exe, so you can't get the number until you've built. For now I just wrap the call, and when debugging my version call returns a dummy string "IDE Version".

I agree it should be way easier to get this info so one could statically link that info into a VI.

Link to post
Share on other sites

In the past I've used .NET and the VI mje describes.

I also using scripting to update a VI pre-build with the info programmatically.

I generally use the latter approach for tools but it would work in an exe, it's just I have re-use code for the exe.

I have posted a LabVIEW Project API and a build script on LAVA (sorry no link on mobile too) that you could look at as an example.

Link to post
Share on other sites

....There is a vi in vi.lib that will natively return the version of an executable, there is no need to bust out the .NET. Sorry, no LabVIEW on my phone so I can't comment where it is or what it's called...

The problem of course is it requires an exe, so you can't get the number until you've built.

I think you're thinking of vi.lib\platform\fileVersionInfo.llb\FileVersionInfo.vi

If so look at: https://decibel.ni.com/content/docs/DOC-3733

Edited by Val Brown
Link to post
Share on other sites
Ultimately you're really not gaining anything over .NET other than you don't need to deal with it directly.

On the contrary, you completely remove a .NET dependency. This uses native Win32 API calls, so it's almost certainly faster too.

  • Like 1
Link to post
Share on other sites

Ok, so I think I have this working. At least the part of dynamically updating the installer message to reflect the version of the EXE we just built and are packaging. I also am updating the installer target folder to reflect the EXE version. This way you get a new folder every time you build the installer. So, no more clobbering the previous build output. Now I need to rename the EXE target folder based on the version. This will be harder since I will need to point the installer to the new folder each time. For now, this seems to work well. Let me know what you think.

Project Version Demo.zip

-John

  • Like 1
Link to post
Share on other sites

Thanks. I will post an update once I get the other features added. My long term goal is an automated build system that is script driven and will let you do nightly builds, beta builds, release builds, including pushing them out to network drives for distribution. Now if only I could so silent installs on targets I would really have something!

Link to post
Share on other sites
  • 1 year later...
Ok, so I think I have this working. At least the part of dynamically updating the installer message to reflect the version of the EXE we just built and are packaging. I also am updating the installer target folder to reflect the EXE version. This way you get a new folder every time you build the installer. So, no more clobbering the previous build output. Now I need to rename the EXE target folder based on the version. This will be harder since I will need to point the installer to the new folder each time. For now, this seems to work well. Let me know what you think.

attachicon.gifProject Version Demo.zip

-John

This is a very useful ability and will hopefully be very useful for creating my installers that have less items to update for each version.

 

Word of caution:  I tried integrating this into an existing project where there are multiple exe's in the project and it took the version of the first exe in my project (which was not the one that I was building).  I haven't looked into how to resolve this issue yet but thanks for the headstart! 

Link to post
Share on other sites
That's the one! Of course the VI just makes a call to a bunch of system DLLs, so I don't think it would work on Linux/Mac/Etc. Ultimately you're really not gaining anything over .NET other than you don't need to deal with it directly.

attachicon.gifversion.png

The snippet above probably doesn't require the file/directory info primitive, but I've always used it as such and not found with any trouble. I'd love to play with some scripting or use j's code to have version info in the IDE, but that's so low on the priority list since ultimately the application is always distributed in built form.

 

It does look like the OSX version of LV2012 doesn't have anything equivalent to 

"vi.libplatformfileVersionInfo.llbFileVersionInfo.vi" . Still though, I can see my app's version number under when I "Get Info" on it with Finder. There has got to be a way to get to it-- anyone any ideas? 

Link to post
Share on other sites
  • 10 months later...

Ideally, I would like to place the build in a folder that incorporates the version in the name.

 

Check the LabVIEW 2013 Upgrade Notes:

 

Creating Directory Versions in Build Specifications
In LabVIEW 2012 and earlier, if you create a build specification, LabVIEW does not include the build
version number in the directory path on disk. In LabVIEW 2013, you can use tags in the build destination
path so LabVIEW automatically includes the build version in the directory path. You can include the
[VersionNumber] tag in the Destination path field on the Destinations page or the Destination
directory field on the Information page of the build specification properties dialog box.

 

Installer builder has the same functionality but uses the tag [ProductVersion].

  • Like 1
Link to post
Share on other sites
@Stobber. Direct modifications of the tags is not recommended and not supported. There is no documentation for those tags.

 

This attitude frustrates me endlessly.

Edited by Stobber
  • Like 1
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 Chris Cilino
      Overview
      In order to quickly and efficiently prepare source for distribution, a build system was necessary to abstract away the conversion of source into the different types of deliverables (VIPackages, Executables, dlls, ect) as well as abstract away the build order of our software hierarchy.
      Many have undertaken to solve this problem. I don't claim to have created a silver bullet. But I do hope that the system I've put together (and am releasing as open source) will act as a starting point for you to extend and customize to meet your needs. I've endeavored to employ good software development principles including separation of concerns, and the SMoRES principles.
       
      I'll be the first to volunteer that it isn't perfect and as always, our best software is constantly a work in progress. However, I believe the build system is at a stage to be at least moderately helpful to a handful of people in our community. 
       
      Description
       
      The Application's UI
      The UI is designed to guide someone through the build process, allowing them to select what components or exports they would like to build, if and how they would like to be notified about the build, auto submission options, and source code control. I've attached a small video titled "Build UI Demo.mp4" below.
      UML and APIs
      All UML and API documentation are included in the Word document per released zip file
       
       
      Software Requirements
      LabVIEW 2017
      NI Application Builder
      VI Package Manager Pro
      Other dependencies are listed in the Instructions per zip file.
       
      UML Overview
      As of 1.4.0-58 the UML looks like:

       
      Build UI Demo.mp4
       
      Release Notes
      1.4.0-123 (Component Builder 1.4.0-123.zip)
      Added new NI Package Manager API Added new NI Package Manager BuildSpec Utils  Added procedure and documentation for the component template and its anatomy  
      1.4.0-113 (Component Builder 1.4.0-113.zip)
      Added documentation for the SCC API  
      1.4.0-111 (Component Builder 1.4.0-111.zip)
       
      1.4.0-99 (Component Builder 1.4.0-99.zip)
      Added a few new P4 API functions allowing the creation of a session if a user is already logged it.  Added Log in and log out tests to the test suite.  Adding new function to tag all p4 paths in a label with the label. Resolving the input path to a p4 depot path Adding quotes around p4 paths.
         
      1.4.0-91 (Component Builder 1.4.0-91.zip)
      The refactor of the LabVIEW SCC API is complete and the build process is linked to the new install location. The LabVIEW SCC API can now be used independently of the Component Build process.  I've included a test suite for the P4 implementation of the SCC API. It assumes that you have checked in the two files in the "Build Instructions\LabVIEW SCC API\Test Suite\Tests\Test Dir" into perforce.  
      1.4.0-85 (Component Builder 1.4.0-85.zip)
      This is a major refactor in the SCC API. I've modeled the p4 label with a new api. This release is primarily as an intermediary release. I intend on breaking SCC out of the component builder into its own separate component in the next release. 1.4.0-81 (Component Builder 1.4.0-81.zip)
      Created a "proxy" api for VI Package manager interactions. Sometimes the VI Package manager api would hang. So I now call by reference and will kill and restart VIPM if it doesn't respond in time.   
      1.4.0-75 (Component Builder 1.4.0-75.zip )
      Fixed reference counting for executable builds.   
      1.4.0-73 (Component Builder 1.4.0-73.zip)
      In the case where a user has specifically unchecked "auto increment", the build process will auto increment the build. Builds must be auto incremented.  I've released a new build of the container that has a minor bug fix. Added file utility tools to aid with using "net use" to move and copy files across the network.  
       
      1.4.0-59 (Component Builder 1.4.0-59.zip)
      Minor spelling error in component template: "componet". Added documentation for the Custom Install Step Launcher. Added build instructions for Custom Install Step Launcher.  
      1.4.0-58 (Component_Builder_1.4.0-58.zip)
      Added the ability to export NI-Source Distributions, NI-Executables, NI-Insatllers, and NSIS Installers Released a template component that exports an NI Package and VI Package including step by step instructions Released "Custom Install Step Launcher" to execute VIs as pre install, post install and post install all actions for NI Packages. Released comprehensive documentation included in the zip file. Component_Builder_5_31_2018.zip
      Component_Builder_10_11_2018.zip
    • By ensegre
      This is a DSC module question: has anybody here experience with building standalone executables which include shared variables bound to DSC modbus i/o servers? I have an issue with deployment, possibly related to licensing. I posted on the dark side, but haven't got feedback yet.
      https://forums.ni.com/t5/LabVIEW/shared-variable-bound-to-Modbus-i-o-not-working-in-deployed/td-p/3809801
      TIA, Enrico
    • By etgohomeok
      Hello, this is not strictly VI Scripting related but I believe it's a pretty similar topic, so I hope this fits in with the discussion on this board.
      I am attempting to write a script that parses through the contents of a very large LabVIEW project (thousands of files) recursively and selectively moves/renames some of the files. The basics of this are fairly simple, however I have thus far been unable to come up with a way of moving files on disk that handles all relinking and dependencies without any issues.
      At a high-level, my question is whether or not the "Move on Disk..." option in the right-click menu of the project explorer "Files" view is accessible programmatically somehow, using invoke nodes. The option I'm talking about, for clarification, is this one:

      Using this option in the project explorer seems to be able to move all types of files in the project (VIs, libraries, classes, etc.) and handle all relinking properly without any conflicts popping up. However, there doesn't seem to be an equivalent "Move on Disk" method int he invoke node for project items. I have had some success with some of the "super secret" nodes for VIs:

      However this only works for VIs and there is no equivalent function for library (.lvlib) and class (.lvclass) files. I've tried various combinations of saving and relinking functions that are available, however I always end up with conflicts when I load the project after running my script.
      If the "Move on Disk..." function is not accessible programmatically, does anyone know of another way to programmatically move/rename library and class files on disk without causing conflicts?
      Thanks,
      Ethan
    • By P.Carpentier
      Hi Everyone,
      Most of the time I am able to find solutions to my issues just by reading this forum but I wasn't that lucky this time.
      So, i got an issue when i'm trying to install my build.
      I got the following message: "This distribution is built with an older version of winMIF that is not compatible with .NET 4.6.2 upgrade to 17.0"
      When googling this error message or even "winMIF" i can't find anything that match my request
      I tried to uninstall the .NET framework and then reinstall the 4.0 (and 3.5) and I got the same issue. (Exactly the same error even if it's .NET 4.0 or 3.5 ...)

      The computer used to build is a Win7Pro with Labview 16.
      The target computer is a WES7 (but I got the same issue on my dev computer ...)

      In advance thank you, 

      Piet
    • By HelenaDomo
      Hi all,

      We are a group of students from the University of Cambridge who are developing a new data connectivity system for researchers like us, its up at https://rinocloud.com

      It currently integrates with LabVIEW, Matlab and Python. The plugin will point your data directly at our secure storage where you can automatically add metadata results for easy and fast retrieval. We’re also rolling out plotting features for presenting the data, collaboration features for project teams and an integrated lab book.

      We are looking for new users, researchers like us, to help us to get feedback from our product.  You’ll be able to directly influence the product development so that you get a data system that is useful for you.

      Know more at https://rinocloud.com 
      https://twitter.com/Rinocloud
       
      Thanks, 
      Helena
×
×
  • Create New...

Important Information

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