Building application and lvanlys.dll

[Intaris]

We have an issue, I don't know if it's a problem.

Whenever we build an application and installer, a copy of lvanlys.dll is created which is always marked as modified by SVN....

Is this normal, or do we need to check for some virus or other issue?

[Andrey_Dmitriev]

There are couple of questions, and the first one is - how did you get lvanlys.dll in your distribution, because this is a part of Run-Time, usually not copied to build output.

The second question - why it saved in SVN? But if you really need this - may be just different timestamp? Just compare dll from SVN with original one taken by default from %Program Files%\National Instruments\LabVIEW xxxx\resource\lvanlys.* (with >fc /b command, for example).

[tst]

---

@Andrey_Dmitriev wrote:

how did you get lvanlys.dll in your distribution, because this is a part of Run-Time, usually not copied to build output.

---

Really? I see it all the time. I assumed it was simply because I use VIs from the analysis library (mean.vi, for instance) and I just assumed that's what LV does.

Now that you mention that it makes sense for it to be part of the runtime, I'm not sure why LV pulls it in to the data folder instead of taking it from the there. I see similar things with lvsound2.dll and lvinput.dll, just to name a couple (although these don't seem to be in <NI>\Shared\LabVIEW Run-Time\XXXX, so maybe there it makes more sense).

[rolfk]

They are (or used to be, 2023 might have juggled things as part of the LabVIEW version independent driver framework changes) in <LabVIEW>/resource.

The Application builder should exclude explicitly some of these shared libraries since they are part of the runtime installation. But in the Runtime installation they used to be in the root folder for the runtime rather than the resource subfolder, such as lvanlys.dll. lvsound(2).dll however is NOT part of a typical runtime installation so needs to be added to the application build. The Application Builder special treating some of these files such as the lvanlys.dll should eliminate adding them to a build but apparently doesn't in your case.

[Intaris]

Thanks guys, turns out if was simply a file we really don't commit any more. The DLL on the SVN server was in LV 2012, but our current build was in LV 2015.

Yes, I know, points at other issues, but at least this question is answered. And es, it was part of the build because it was code for a Real-Time target.

[Andrey_Dmitriev]

---

@Intaris wrote:

. And es, it was part of the build because it was code for a Real-Time target.

---

Yes, this could happen, but in normally it is not included, I quickly checked this before answering, there are no files in data folder (and no data folder at all):

But if I will put Query Input Devices.vi on the BD, then lvinput.dll will be present in \data SubFolder:

At this moment I have no logical explanation for this phenomena, may be because Mean belongs to NI_AALBase.lvlib, and QueryInputDevices is just stand alone SubVI. 

[rolfk]

Lvanlys.dll is part of the Runtime installation, lvinput and lvsound(2) not.

[Andrey_Dmitriev]

---

@rolfk wrote:

Lvanlys.dll is part of the Runtime installation, lvinput and lvsound(2) not.

---

Thank you, up to now I was sure that the lvinput is part of Run-Time (there are lot of lv*.dll bundled), but this one not, indeed, you're perfectly right! On the other hand It seems to be the lvinput.dll was included into LabVIEW NXG Run-Time.

[tst]

---

@Andrey_Dmitriev wrote:

---

---

Yes, this could happen, but in normally it is not included, I quickly checked this before answering, there are no files in data folder (and no data folder at all):

---

If I do the same thing (new project with a single VI which calls mean.vi under My Computer, in LV 2015, which is what I currently have open), I get the data folder with the DLL. The EXE does actually seem to use the DLL from the RTE, because if I rename or delete the folder the EXE still works and calculates the mean, so I don't know why LV puts it in the data folder.

Oh well, I managed to ignore it when it happens until now. I plan on keeping ignoring it.