Search the Community

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

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

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

I need to read the installer version number (not the exe version number) programmatically. Is there any way? I have a bundled software which has multiple EXE's under one installer. Commonly I use the installer version number for reference and want to show it up to the user. Is there any way to get the installer's version number instead of executable's version number? --Ajay.

Hi, I posted this question in OOP forum, but may be the right place is here... Have you experienced that LV takes very long time to build executables when you use a certain number of classes? I have noticed that when my app uses many classes (e.g. 30 classes) LabVIEW IDE slows down ("busy pointer" appears very often during VI editing) and compiling executables takes more than half an hour. It's not due to my machine because larger projects are built in less time if they don't contain so many classes. Are there properties that can speed up the build?

Hello all, I am trying to integrate our LabVIEW build workflow into our CI Server. Currently we have several builds in LabVIEW projects that we can programmatically call in order to perform the build, conduct unit testing etc. using the IDE. I'm looking to integrate this into our build server using TeamCity. Every time we check in changes to one of the projects a build is triggered. Since building requires the IDE running, I am attempting to use the Command-line Runner in TeamCity to execute a batch file that launches the IDE with the builder VI as an argument. The build VI performs the builds, testing and then shuts-down LabVIEW. Running the batch file manually (as me) works a treat - LabVIEW starts up, the builds occur, unit test results are captured and then the IDE shuts-down. However I have run into a problem getting the batch file automatically called by TeamCity. The build agent runs as a windows service and it appears as if windows services do not have permissions ordinarily to start up GUI applications. I have tried several options such as configuring the log-on account for the service to run etc. Every time the build occurs, the log shows that the batch file has been run but LabVIEW does not start up. Unfortunately there is no command-line version of LabVIEW (pity) so it appears as if there is no obvious way to get this to work. Has any-one attempted this before? I know guys at JKI pull this off (using a different CI server) and I'm wondering whether this issue is familiar to anyone. Thanks for any and all help.

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

I wrote a very simple vi for a friend of mine. Simple as in: this vi has no sub-vi's and all functions are from the standard palette. I was going to build an executable for him to run it, but it turns out he has a Mac and I am running on Windows. Even though I own 3 licenses of LabVIEW it appears that I have to purchase a whole new multi-thousand dollar LabVIEW license for Mac to be able to build it. Given the nature of the project, you can see why this is not a good solution for the situation. I am asking for a favor, that if anyone has the Mac OS version of LabVIEW if they wouldn't mind doing me a favor and taking a few minutes to build this vi into a .app file. I would really appreciate it. Thanks. DyRASS.vi

Hi I have designed an application for my graduation project,now i need to built it but i don't have the key for that !! If any one have the application builder key,and he want to help me i will send him my (.VI) file,he build it and then he send me th (.exe) file I don't know if such demand is possible but i really need ur help !! So please help me thx

Hi folks, I have created an executable with LV 2011 and I have found an unexpected behaviour of my application: the VI's menu uses an unreadable font or charset. When I run the same VI from LabVIEW (i.e. the source code), I see the standard LabVIEW menu. Above you see the screenshot of panel executed from LabVIEW IDE, below you see the same VI executed in my .exe app. browsing submenus I see the strange font in every submenu. Instead, labels and captions on panel have standard font. In past, I have built other applications on the same machine, all worked fine. Have you any idea? are there special settings in build spec.? Claudio