problem compiling: Librarian Path Location.vi

[cs42]

Hi,

I have a very  big problem creating an EXE. I always get the message: can't copy NVIORef.dll. This happens also, when I try to build a source package!

The interesting thing is, that this DLL is available and it works for other applications:

I tried so far (without success):

1. switching on and off enhanced DSC support
2. using the VI in a new project
3. moving all VIs out of the lvlib (it used shared variables to communicate in the first version)
4. copying all the code of the main VI to a new VI and tried to build that
5. build a source package

I attached a screenshot of the message when building a source code package which is similar (or the same) to the one when trying to build an EXE:



I don't know what else to do. Problem is I need the EXE as it is a project for a customer and it is supposed to run on a PC without IDE!

Any ideas please?

Thanks,
Carsten

Message Edited by cs42 on 08-31-2007 04:10 PM

[cs42]

So if nobody can shed light on this, I can at least a little 😞

You have to take this strange error message literally! LV somehow really looks for the DLL under this strange path instead of a sensible one. I discovered this by trying to compile sub-VIs one by one. One problem was with:

C:\Programme\National Instruments\LabVIEW 8.2\vi.lib\lvdsc\process\Get Shared Variable List.vi

When I removed this VI and simply reinserted it the containing VI compiled but there was an error message on first load:

C:\Dokumente und Einstellungen\schurig\Lokale Dateien\Versionskontrolle\LabVIEW\Ablaufsteuerung2\SubVIs\PROCESS_get writable variables.vi
    -  DLL wurde unter "C:\Programme\National Instruments\LabVIEW 8.2\resource\NVIORef.dll" erwartet und von "..\Programme\National Instruments\LabVIEW 8.2\resource\NVIORef.dll" geladen.

This is a really strange behaviour and unfortunately there are still some things hidden which are linked to this NVIORef.dll which I haven't found yet. :.-(

And I still do not understand how something like this happens. Another unexplainable instance where compiling breaks my neck...

Message Edited by cs42 on 09-03-2007 10:28 AM

[cs42]

Found more problems. The first VI doesn't compile (brings the NVIORef.dll error), the second one does:





Notice the slight difference? Yes, it is only the wire from the Name property of the SharedVariableIO! 😞

Message Edited by cs42 on 09-03-2007 10:57 AM

[RebeccaFo]

Hi Carsten

in this way it´s a little bit difficult. Have you recompiled your VI (Strg+Shift+Run-Button)?

When this not helps perhaps it´s possible that you attach you´re VI, better the project?

Thanks,

[tst]

As for why it doesn't break for the second piece of code, I believe I can explain that - LV analyzes the code when it compiles it so that it can optimize. I'm guessing that when it sees a property node which is not actually used, it simply ignores it as if it is not inside the code at all, which means it doesn't even have to look for the DLL.

At least, that would be consistent with other optimizations I've seen LV make.

[cs42]

Hi Rebecca,

yes I had recompiled the VI (and should not compilling be doing this anyway?) and the difference between error and no error is just reading this property.

I solved my problem writing a small VI which gets the name out of the URL myself at first. 😉 It's amazing, that I can switch back to using this property now without any problem. Somehow it vanished (I've read this in another thread about a problem with copying NVIORef.dll as well!).

It seems to have been a strange hickup. Did cost me two days to figure out and kind of "solve", though...

Carsten

[cs42]

Yes I assume this as well. Actually this shows quite a thorough optimization as the error cluster is wired...