By Chris Cilino
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.
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
NI Application Builder
VI Package Manager Pro
Other dependencies are listed in the Instructions per zip file.
As of 1.4.0-58 the UML looks like:
Build UI Demo.mp4
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.
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
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.
Is it possible to programmatically call "Move on Disk..." function that is available in the Project Explorer?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?
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,
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