LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

EXE Build cant find .NET dlls and calls are broken after manually pointing to dlls.

Solved!
Go to solution
Highlighted

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

 

 

 

 

 

 

 

0 Kudos
Message 1 of 15
(332 Views)
Highlighted

@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.

0 Kudos
Message 2 of 15
(326 Views)
Highlighted

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

0 Kudos
Message 3 of 15
(319 Views)
Highlighted

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...

Message 4 of 15
(309 Views)
Highlighted

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

0 Kudos
Message 5 of 15
(291 Views)
Highlighted

Any change it's related to XML?

 

https://answers.microsoft.com/en-us/windows/forum/windows_other-update/error-code0x8007045a/c7914207...

 

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.

0 Kudos
Message 6 of 15
(285 Views)
Highlighted

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!

0 Kudos
Message 7 of 15
(280 Views)
Highlighted

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...

0 Kudos
Message 8 of 15
(268 Views)
Highlighted

@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).

0 Kudos
Message 9 of 15
(262 Views)
Highlighted

@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.

0 Kudos
Message 10 of 15
(258 Views)