09-21-2020 06:48 AM
LV 2018sp1
Attempting to run executable on target machine results in the file prompt dialog for 2 .net dlls that labview cannot find.
LabVIEW has no issue finding both of the dlls in question on my dev machine.
The 2 dlls in question are from an sdk that I installed on my dev machine.
I have tried manually including the 2 dll's in the data directory (exe support directory). The prompt still ocurrs. Once I manually select the first dll, the second prompt does not ocurr and the exe runs- some remote debugging shows that all the calls to the dlls through .NET constructor refs are broken.
I also tried installing the whole sdk on the target machine. The vendors software works as expected so I think this rules out another dependency missing..
using where cmd with both dll names on both my dev machine and the target machine are the same.
Anyone have any ideas?
Thanks
Solved! Go to Solution.
09-21-2020 07:08 AM
@p27 wrote:
Once I manually select the first dll, the second prompt does not ocurr and the exe runs- some remote debugging shows that all the calls to the dlls through .NET constructor refs are broken.
The calls are broken? That is confusing. Either the wires are broken (the exe won't run) or the functions return an error? I guess you mean the latter. What is the error?
Any change you moved the dlls to the data directory from a zip? Then you have to unblock the dlls (explorer, properties, unblock (or was it unlock?)).
This might be a rights issue. Try to run the exe as administrator. Even if you are administrator, it's not the same... Long shot, but I'd try it at least once.
09-21-2020 07:15 AM
Sorry for being unclear- the wires are broken.
the dlls were put into the data directory from the dev machine, although I also tried from the installation directory of the sdk local to the machine.
I also tried running as admin, same result.
I don't get any error information while remote debugging
09-21-2020 07:41 AM - edited 09-21-2020 07:47 AM
Can you run the attached VI in your executable (include it in the build)?
Of course, change to path to your dll(s) (make it a control).
See what .NET has to say about it...
EDIT: You can also make a new exe, or compile the VI in your development system (mine is 64 bit) and then drop it onto the .exe in explorer. The VI will be opened by the exe (even if it's running). Point is to run the VI on the system...
09-21-2020 08:04 AM
thanks for the vi- I dropped it into the top level and got this error:
Invoke Node System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
Inner Exception: System.IO.FileLoadException: Could not load file or assembly '<XXXXXXXX.dll>' or one of its dependencies. A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A) <append><b>System.IO.FileLoadException</b> in Reflection Load Assembly.vi->Field Setup.vi
09-21-2020 08:15 AM - edited 09-21-2020 08:17 AM
Any change it's related to XML?
From this page:
https://ugetfix.com/ask/how-to-fix-0x8007045a-error-code-on-windows/
The 0x8007045A Error Code is related to Microsoft XML Core Services. That is the native Win32 API for XML-based applications that adhere to the XML 1.0 standard. Various Windows versions have this issue regarding the application. However, recent updates of the OS causes the error more often.
So it seems plausible that the dll depends on a legacy XML parser. On a 'used' system this is more likely to be available, on a new system it won't.
09-21-2020 08:25 AM - edited 09-21-2020 08:26 AM
no theres no XML stuff going on that I'm aware of.
edit: oh you meant down inside the api... yea I don't know... I'll look into that a bit more then thanks
Thanks again!
09-21-2020 08:49 AM
both systems have the same output when running the xml parser version query from here:
https://stackoverflow.com/questions/1802406/find-msxml-version-from-registry
really quite puzzled at this point...
09-21-2020 09:03 AM
@p27 wrote:
no theres no XML stuff going on that I'm aware of.
edit: oh you meant down inside the api... yea I don't know... I'll look into that a bit more then thanks
Thanks again!
In stead of installing things you're not sure about on a clean system, you could try some sort of .NET dependency viewer.
Even dnSpy (a .NET debugger) would work. Something link .NET Dependency Walker looks perfect for this, but I haven't tried it (and it's only partially free).
I think I had this once (with XML). IIRC, I turned on support for legacy .NET frameworks (2 and 3.5, IIRC).
09-21-2020 09:05 AM
@p27 wrote:
both systems have the same output when running the xml parser version query from here:
https://stackoverflow.com/questions/1802406/find-msxml-version-from-registry
really quite puzzled at this point...
That query probably returns the latest version available.
You're looking for the oldest version available.
Both systems are up to date, so include the newest version. But at some point some modules lost backward compatibility. If the driver depends on an old version, it needs to be installed on a new system.