How to export code for end users that is cleaned

[JÞB]

---

@MaSta wrote:

I'll consider that. Thanks all. 

By the way, I figured it out. I can use multiple MNUs inside a packed lib. 😥

---

Not my favorite option.  Just because the pallet editing tool was never very good and hasn't really been redone to any kind of user friendly interface.  Maybe some day NI will work on that feature. 

[billko]

VIPM.  That's all you need.  Put the library in its own project, away from the user.lib folder.  Use VIPM to distribute.  Even the free version allows you to make quite comprehensive palette menus.  The pro version even allows you to have it in the right-click --> replace menu.

[MaSta]

However... the problems continue. This time it's a LabVIEW concept bug.

So I have this packed lib now. In the lib, I hid some files and one folder by making it private. If I open just the lib, the tree view wouldn't show the private stuff. If I then create a new VI and use some sub VI from the packed lib, the lib is shown in the dependencies of the project. Depending on how the status of the lib is, loaded or unloaded, the lib tree would show the hidden files or not. Doh!

Next step was to compile the new VI to an exe and run it to test the portability. Doesn't work. The exe would pop up a requester to find the sub VI in the lib. That would mean, the lib would always have to be next to the exe. Doh!

So no portability. The packed lib is no option. Back at the beginning. 😞   

[MaSta]

---

@billko wrote:

VIPM.  That's all you need.  Put the library in its own project, away from the user.lib folder.  Use VIPM to distribute.  Even the free version allows you to make quite comprehensive palette menus.  The pro version even allows you to have it in the right-click --> replace menu.

---

VIPM is JKI. JKI is an extra tool that you need a licence for. LV 2021 and perhaps a few versions before can make use of NIPKG, but both are just installers. We want to offer a wider range of version compatibility. Not every company has the latest LV. So we thought of starting from LV 2015.

LV 2015 has less options. A lib with stripped source code cannot be loaded in higher versions when created by LV 2015. It seems that the way we had it before (direct export of password protected VIs) is still the best option as this a) is easy to assemble and b) easy to compile by the user. 

It's sad that LV has no good export/portability design at this point.  

[billko]

---

@MaSta wrote:

---

@billko wrote:

VIPM.  That's all you need.  Put the library in its own project, away from the user.lib folder.  Use VIPM to distribute.  Even the free version allows you to make quite comprehensive palette menus.  The pro version even allows you to have it in the right-click --> replace menu.

---

VIPM is JKI. JKI is an extra tool that you need a licence for. LV 2021 and perhaps a few versions before can make use of NIPKG, but both are just installers. We want to offer a wider range of version compatibility. Not every company has the latest LV. So we thought of starting from LV 2015.

LV 2015 has less options. A lib with stripped source code cannot be loaded in higher versions when created by LV 2015. It seems that the way we had it before (direct export of password protected VIs) is still the best option as this a) is easy to assemble and b) easy to compile by the user. 

It's sad that LV has no good export/portability design at this point.  

---

True, VIPM is an external package, but it makes everything you are trying very easy.  For instance, multiple different LV versions.  But I do know what a hassle licenses are, especially if you're planning on making money off of it or you are a big company.

[wiebe@CARYA]

---

@billko wrote:

---

@MaSta wrote:

---

@billko wrote:

VIPM.  That's all you need.  Put the library in its own project, away from the user.lib folder.  Use VIPM to distribute.  Even the free version allows you to make quite comprehensive palette menus.  The pro version even allows you to have it in the right-click --> replace menu.

---

VIPM is JKI. JKI is an extra tool that you need a licence for. LV 2021 and perhaps a few versions before can make use of NIPKG, but both are just installers. We want to offer a wider range of version compatibility. Not every company has the latest LV. So we thought of starting from LV 2015.

LV 2015 has less options. A lib with stripped source code cannot be loaded in higher versions when created by LV 2015. It seems that the way we had it before (direct export of password protected VIs) is still the best option as this a) is easy to assemble and b) easy to compile by the user. 

It's sad that LV has no good export/portability design at this point.  

---

True, VIPM is an external package, but it makes everything you are trying very easy.  For instance, multiple different LV versions.  But I do know what a hassle licenses are, especially if you're planning on making money off of it or you are a big company.

---

AFAIK, JKI PM has a reasonably complete free version.

Features you need might indeed require a license.

[MaSta]

Forget about the WAY we distribute files, that's easy to arrange. The problem is in what FORM to distribute the VIs. As I wrote before, a packed library is not a source VI collection anymore, it's like a DLL. You have to deliver it along with your software.

The ideal would be some form that can securely hide the source code, but still includes it for compilation and compatibility. Yes, that would normally be a DLL, but LabVIEW's not made for DLLs. And DLLs are not portable to Linux.  

[wiebe@CARYA]

---

@MaSta wrote:

The ideal would be some form that can securely hide the source code, but still includes it for compilation and compatibility. Yes, that would normally be a DLL, but LabVIEW's not made for DLLs. And DLLs are not portable to Linux.  

---

DLLs are not source code.

No DLL made for Windows will run on Linux, although most languages allow cross compiling. Not LabVIEW though (except for RT).

LabVIEW DLLs work fine, but if you want to use it in LabVIEW, a PPL makes much more sense. You get to keep the VI API, in stead of the DLL API.

There is no programming language where you can (securely) hide the source code while still being able to re-compile. Actually, LV is probably the only language where it's even an option (although totally insecure).

At least as it (since LV14) is, you can use (most functionality of) compiled LabVIEW code in future LabVIEW versions, provided the bitness and OS are the same. The bitness problem will soon disappear, as LabVIEW will be 64 bit only (except maybe RT).

[MaSta]

No one wrote that DLLs are source code. I wrote that a DLL is a form of code that hides source code, because it's not included. Recompilation - seriously?

Anyway, if the password protection would be serious in LV, it would be secure enough. 

[wiebe@CARYA]

---

@MaSta wrote:

No one wrote that DLLs are source code. I wrote that a DLL is a form of code that hides source code, because it's not included. Recompilation - seriously?

---

I read 'hide source code' as actually hiding it, not remove it.

Your previous post suggest (to me) that dlls are different than LV DLLs or lv PPLs, while it is exactly the same, with the same drawbacks and advantages.

You do need to recompile a C\C++ dll if you change bitness, OS and the runtime engine, exactly like in LabVIEW.