How to export code for end users that is cleaned

[MaSta]

Hello!

We (as company) are using LabVIEW since more than 15 years to program our own device test applications. The pool of VIs contains communication VIs we also provided to our customers in password protected form. They are not optimized, not very elegant, but they work. Now we want to "tidy up". Means, clean the code from old, not anymore used stuff. That's easy.

But... in the code of the those sub VIs we want to sort of "export" for our customers we have internal stuff that we only use ourselves and which we

a) don't want them to see (the block diagram is locked by password, but the password of VI can be cracked quite easily) and

b) don't want to include in the export. 

One way of not including code parts is to use conditional deactivation. This would have LV not seek for sub VIs in deactivated code. So far, so good. But we learned that when you add one of the sub VIs to a project, you see the deactivated sub VIs listed under "Dependencies" as missing. That's the point.

Is there a way to export VIs in a code cleaned/reduced/stripped form? So that I won't list any missing dependencies or internally used sub VIs?

LV LIBs and LLB are not the right way.

[ZYOng]

don't want them to see (the block diagram is locked by password, but the password of VI can be cracked quite easily)

The only way to prevent password cracking is by removing the block diagram entirely. See Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams

However, LabVIEW will only allow running the VI on the same LabVIEW version and platform for which the VI was compiled and saved; future LabVIEW versions or other platforms will not be able to recompile the VI. Therefore, you will need to provide a separate VI for each combination of LabVIEW version and platform you wish to support. 

don't want to include in the export. 

I can only think of two ways to do that:

1. Swap between external and internal use VIs before exporting to customers. See Programmatically Replace LabVIEW VIs Using VI Scripting | DMC, Inc

2. Use Calling a LabVIEW VI by Reference, in which the subVI will not be included as the dependencies. However, calling VI by reference is slower and you need to export the VI explicitly. 

[MaSta]

Remove block diagram: I don't see how to do this. "Save as" doesn't offer it.

Regarding the other answers: calling sub VI is not the intended way of LabVIEW, as it can be very tricky. But yes, it would at least solve the topic regarding sub VIs being listed as missing. 

[ZYOng]

If you open and read the Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams, you will find out that Removing Block Diagrams from VIs is being included in that article.

[MaSta]

Sorry, OK, yes. I knew that way, but this is a bad compromise, because if you remove the block diagram this way you cannot load the VI in any newer version than it was created with. Seems that removing the block diagram is no option for us.

[crossrulz]

Just build the libraries into Packed Project Libraries (PPL).  They will be precompiled and will only allow the user to see/call VIs that are not Private.  As part of the build process, you can disable debugging and make it so the block diagrams are not visible.  Further, there is an option in the build specification to allow newer versions of the runtime engine (and LabVIEW IDE) to use the PPL.

[dkfire]

I would go with a lvlibp. 

Then your code will be compiled, and if disable debug, the block diagram will not be able to be viewed.

You sub'vi can also be hidden internal in the lvlibp, as only top vi's are able to be selected. 

[MaSta]

@dkfire: this is what @crossrulz suggested.

@crossrulz: nice idea, but the library could then not be used in future LV version. Tried that today. Created in LV 2015, then LV 2021 would refuse to load the VIs from it.

[JÞB]

---

@MaSta wrote:

@dkfire: this is what @crossrulz suggested.

@crossrulz: nice idea, but the library could then not be used in future LV version. Tried that today. Created in LV 2015, then LV 2021 would refuse to load the VIs from it.

---

That changed with 2017!  From 2017 on you do have a build spec OPTION (default = TRUE) to "Allow future RTE to execute" the build.

[JÞB]

And now for some additional advice:

Take the opportunity to create documentation and examples in the source lvproj for each lvlib that you will build into a lvlibp.  Then even find a nice location to install your example code to with you lvlibp installer.  It's a few minutes for the owning developer that will pay off at least 100:1 on the rest of the dementia [EDIT: DEVELOPMENT. sometimes automatic corrections are soooo true] team's code effort, debug, and integration time.

Just believe me now and thank me later. 😀