lvanlys.dll is not included in build output

[petrz]

Hello,

I'm upgrading from LV2016 to LV2018 and I found difference in application builder behavior. When building a library which uses lvanlys.dll, the build output doesn't includes this dll (note, excluding of shared libraries is off). In previous version of LabVIEW (2016 and 2017) the lvanlys.dll is copied in directory of the build (eg. data directory for executable).

I found this behavior only with lvanlys.dll and LV2018, for other dlls eg. sndvib.dll (also NI library) it doesn't happens.

Is this some new feature or bug in LV? Is the lvanlys.dll included in runtime in same folder as in development?

[altenbach]

Is anything broken if it is not included? Please test.

(There is a copy in "C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-Time\2018", so including it with the build seemed always redundant in the past.)

In the past for many of my builds, I actually added this dll to the project so I can explicitly excluded it in the build spec (e.g. for source distribution, etc.). 😄

[petrz]

It works on my computer even when build is moved, but I have LV development , which creates different environment (I don't have any without LV development around right now, I will test asap).

The path you mentioned is different from original which is "C:\Program Files\National Instruments\LabVIEW 2016\resource" so this can make some issues.

From my experience in LV2016 if dll is not at expected place eg. data dir, exe will break. If the dll is on different place (but it is in memory, eg. from different library) it will show warring.

The point is, if this behavior is correct and if there is something I should be aware about it. It is not problem when managing single packed library, but when you have several libraries it can be issue. I think managing of shared libraries in LV is quite tricky and sometimes it has strange behavior (especially for .NET), so any experience in 2018 are welcome.

Sure adding it to the project is an option, but if its not necessary I like to avoid.

[petrz · Accepted solution]

I did some test and here are some conclusions:

First, I run executable on PC with LV runtime only. The executable uses one simple VI calling another VI from lvlibp, which wraps calculation of mean (from lvanlys.dll). The example 2018 runs without problems. I also tried same scenario in LV2016, I built executable and then removed lvanlys.dll (data folder), for my surprise application also worked, but sometime I was able to see quick flash of search window, so apparently runtime engine search for that dll.

Next I tested the same VI (used for exe) to run it from LV development, there was no warring displayed or search attempt during opening and running project. Just for comparison, if you do same thing in LV2016 it will shows warring about loading dll from different path each time the project is opened.

So my conclusion is that in LV2018 you don't need to care about lvanlys.dll at all, looks like LV always "silently" replaces path to the dll. Works for both exe and packed libraries. This is quite good benefit because you will always end up with only one lvanlys.dll without any extra effort. Also the project dependencies looks much better since there is always one dll. This works only lvanlys.dll (maybe some others dll included in runtime), for example it doesn't for sndvib.dll (its included in Sound And Vibrations extension).

Project in LV2016, notice two lvanlys.dll from two places. One is dependence of mylib.lvlibp and second is for main.vi.

Same project in LV2018, there is only one dll. (note the packed lib was rebuild in 2018)