Updating subVIs

[Greg Hupp]

I have an application in which I need to update several subVIs that are being used. Is there a way that I can update any VIs that use the subVIs can be recompiled at the command line (or other) so that the main VI is not broken? These VIs are not part of a main executable, so they are just substituted in place of the old ones. Care was taken to not change the position of the existing pins on the connector pane (although some were added on the new one) to prevent breaking anything using the subVI.

It is as simple as opening the main VI and resaving it...no modification required -> so it seems like this should be able to be done relatively easily.

[Mark Yedinak]

You can run a mass compile on the directories that contain the affected code. The mass compiler is available at "Tools->Advanced->Mass Compile". You will need to select the directories containing the top level VIs that you want to fix. If everything is under a single directory you will only need to select that one directory.

[Greg Hupp]

You can run a mass compile on the directories that contain the affected code. The mass compiler is available at "Tools->Advanced->Mass Compile". You will need to select the directories containing the top level VIs that you want to fix. If everything is under a single directory you will only need to select that one directory.

Thanks...yeah this is an option although I am trying to figure out a way to do it at install time (say update to existing installation...patch type thing). I really have no way of actually opening up LabView to recompile any VIs.

[Mark Yedinak]

How are your applications deployed? Are they built as stand-alone applications or are they actual VIs? If they are stand-alone applications you shouldn't have issues with new applications using updated versions of VIs. If you are distributing raw VIs and hoping to keep everything up to date the only option you have would be to recompile the VIs. You could potentially write an application that would go through your code and load, recompile and save the affected applications but this isn't an ideal solution. This application would need to have a list of the applications it needed to update and somehow report any failures it encountered. This would make the maintenance process fairly complex and subject to problems. The best solution is to build your applications are stand-alone executeables.

Also, are you using projects for your applications? If not you should really consider using them. They help to manage this process.

[Greg Hupp]

How are your applications deployed? Are they built as stand-alone applications or are they actual VIs? If they are stand-alone applications you shouldn't have issues with new applications using updated versions of VIs. If you are distributing raw VIs and hoping to keep everything up to date the only option you have would be to recompile the VIs. You could potentially write an application that would go through your code and load, recompile and save the affected applications but this isn't an ideal solution. This application would need to have a list of the applications it needed to update and somehow report any failures it encountered. This would make the maintenance process fairly complex and subject to problems. The best solution is to build your applications are stand-alone executeables.

Also, are you using projects for your applications? If not you should really consider using them. They help to manage this process.

Thanks....this is a very complex large app that is a plug-in based architecture. The main app is an executable and the plug-ins are just distributed VIs...this is kind of the answer that I expected, I just wanted to see if anyone had come across a better way to do this. And yes...I use projects...much easier to view all the pieces that are used!!

[Mark Yedinak]

Thanks....this is a very complex large app that is a plug-in based architecture. The main app is an executable and the plug-ins are just distributed VIs...this is kind of the answer that I expected, I just wanted to see if anyone had come across a better way to do this. And yes...I use projects...much easier to view all the pieces that are used!!

Does your installation package the various plugins? This may help if the installation were to update all the components. This does bring up an interesting issue though of how you can manage updates to the plugins. Have you considered using JKI's Package Manager?

[Greg Hupp]

Does your installation package the various plugins? This may help if the installation were to update all the components. This does bring up an interesting issue though of how you can manage updates to the plugins. Have you considered using JKI's Package Manager?

The installation used is a separate scriptable installer used due to the scope of the end application. I can update the components, but LV apparently doesn't always respond favorable to change one of the components. And yes...this is my current dilemma in trying to update the plugin VIs/controls etc. Am not very familiar with the JKI Package Manager and unsure at this point if I want to try and introduce another level of complexity to this system and deliverable. Do you have any experience with the Package Manager?

[Mark Yedinak]

The installation used is a separate scriptable installer used due to the scope of the end application. I can update the components, but LV apparently doesn't always respond favorable to change one of the components. And yes...this is my current dilemma in trying to update the plugin VIs/controls etc. Am not very familiar with the JKI Package Manager and unsure at this point if I want to try and introduce another level of complexity to this system and deliverable. Do you have any experience with the Package Manager?

I don't have experience with deploying packages, only using them. It may or may not solve your dilemma but thought it might be worth taking a look.

[Daklu]

Is there a way that I can update any VIs that use the subVIs can be recompiled at the command line (or other) so that the main VI is not broken?

Nope. The compiler and linker are part of the dev environment, not the run-time engine. If you don't have LV installed on the target computer you're out of luck.

The most obvious causes for needing to recompile the calling VIs would be, a) unintentionally modifying something in the main part of the application, or b) not properly decoupling the plugins from the main app, or c) changing the interface to the plugins. You already copped to c, but I'll bet you have some b in there too.

a) Did you change anything in the plugins that propogates up to the main app? Typedefs are a prime suspect here. Changing a typedef requires a recompile for every VI that uses it. I generally avoid exposing typedefs across code modules for exactly this reason.

b) You mentioned adding terminals to the connector pane, so you are probably calling your plugins by simply dropping them on the VIs in your main app. I've never tried replacing a vi that is statically linked to an executable, but it wouldn't surprise me at all if it doesn't work. To properly decouple your plugins you need to call them dynamically at runtime by feeding the path into the Open VI Reference and Call By Reference Node primitive nodes.

c) Again pointing to the altered connector pane, if you're using the Call By Reference Node primitive to make dynamic calls, you can't add conpane terminals without changing the conpane prototype wired into the Open VI Ref prim in the calling code. In other words, you've changed the interface to your plugin. (There are ways you can add terminals to a plugin, but your original source code has to be written to accomodate it.) If you think you might need to change the data sent to or received from a code module, wrap it in a class.

That does make me wonder... why did you add terminals to the plugin if you're not using any of those terminals in your main app? (I'm making a bit of a leap here based on your comment about only needing to open and resave the project to fix it.)

----------------

VI Package Manager is a very good tool. At first glance your problem appears to stem from the application's architecture, so I doubt that it would help you at all in this situation.

Edited February 7, 2010 by Daklu