LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DLL compilation depending on LabVIEW version

Solved!
Go to solution

Hello dear Community,

Best wishes for the new year!

I've a question regarding on the dll compilation. I've developp an application with LabVIEW, which call an external dll to do Something particular. I've used this method to be able to update the function into the dll without generate new application: I've just to stop my application, replace dll and restart application. The dll is generated with LabVIEW too. This application is used on some computers of my society, with run-time engine installation.

It's properly run, but I've a version problem: I can only use a dll compiled with the LabVIEW version corresponding to the higher version of LabVIEW Runtime installed of my computer. For example:

- dll compiled and application build with LV15; LVRTE10 and LVRTE15 installed: OK

- dll compiled and application build with LV15; LVRTE10, LVRTE15 and LVRTE18 installed: NOK

- dll compiled and application build with LV18; LVRTE10, LVRTE15 and LVRTE18 installed: OK

Is it a possibility to compile a dll which can used on a computer which have same or higher LVTRE version? it will be fine if my dll compiled with LV15 could be called on a computer which have LVRTE15, 18 and 19... (like an exe compiled with LV15).

Thank you per advance!

Francis M
0 Kudos
Message 1 of 8
(2,917 Views)

I don't have experience with Building DLLs with LabVIEW, but I have heard people like to use packed project libraries (.lvlibp) to handle your situation. You can update just the lvlibp to change functionality without modifying the code that calls it.

 

Just a question on your LabVIEW versions, are they all the same bitness? (32-bit or 64-bit?)

Message 2 of 8
(2,892 Views)

I don't know the answer to the question you're asking, but kinda wonder whether you should be asking it.

 

If I was distibuting an app to multiple PC's, I would make an installer that included the necessary RTE for the LV version I was developing in.   And then whenever I compiled a dll to be used by that app, I would create the dll in the same LV version I used to create the executable.

 

So what's different about your overall approach to things, and why?

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 8
(2,889 Views)

Hello,

 

Thank you for you responses.

 

@Gregory: for LabVIEW we use only 32-bits versions. I will have a look on packed project librairies... and i have to do some tests. I liked dll: just one file to manage and very short call time. I wanted first to know if is possible to compile a dll which can for example be call by a version >= to the compilation version.

 

@Kevin_Price: other personns can install other software with other RTE on each PC, and the application can be used by colleagues who have installed Labview. Typically, if a colleague install LabVIEW 2019, he can not more use my application even if he has LV/LVRTE 18 on his computer. The only way is to ebuild dll with LabVIEW 19. 

Francis M
0 Kudos
Message 4 of 8
(2,808 Views)

My understanding was that a LabVIEW DLL is always initialized to be executed in the RTE in which it was compiled and then called out of process EXCEPT when it determines that it is called by a LabVIEW process which has the same version in which it was compiled. This seemed to work in the past like this, so I'm not quite sure what happened.

 

There was a change in recent LabVIEW versions that allowed compiled code to be executed in newer RTE versions when available. I was under the impression that that was only introduced with LabVIEW 2016 but may be wrong. If LabVIEW 2015 has this option too there should be a setting in the Advanced Build settings of your Build Specification to not allow execution of the compiled code in a future LabVIEW RTE and you may have to enable that checkmark.

Rolf Kalbermatter
My Blog
Message 5 of 8
(2,798 Views)

I don't understand too, but I can confirm that the dll compiled with LV18 doesn't run on a computer with LabVIEW 2018 and LVRTE 2019... Are they some options in builder to solve problem? 

Francis M
0 Kudos
Message 6 of 8
(2,790 Views)
Solution
Accepted by topic author Cisco

@Cisco wrote:

I don't understand too, but I can confirm that the dll compiled with LV18 doesn't run on a computer with LabVIEW 2018 and LVRTE 2019... Are they some options in builder to solve problem? 


Read my response last edited 5 minutes before your post, which added the info about the build settings to prevent the compiled code to run in a newer RTE than what it was created in. This feature was mostly created for exes I believe and should be working there but something makes it apparently break for LabVIEW DLLs.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 8
(2,771 Views)

Hello,

 

You're right, sorry, I'd not all read. Effectively, we have this new option (not in LabVIEW2015).

LV15:

dll.PNG

LV18:

dll2.PNG

I will active it and do a test, and normally my problem will be solved! It would be great if I could make something like this with LV15 (the smallest version of rte used), but I think I can live with this solution… 🙂

 

Thank you and have a nice Week-end

Francis M
0 Kudos
Message 8 of 8
(2,746 Views)