Why won't a .net dll run in a standalone executable when it runs fine in the base vi?

[mikeporter]

OK, new problem. Same questions: what DLL? What error? When are you getting it?

Mike...

PS: you really should have started a new thread...

[ªL¡]

Problem: I am using a .NET dll in a LabVIEW code that I am writing. It works well while in development mode. Once compiled into an executable file, the application will give an "Error 4 occured at Constructor Node in QSBReadPWMEncoder.vi. Possible reason(s): LabVIEW End of file encountered".

The DLL is included in the support directory of the compiled application.

However: if I delete the DLL from the support directory, I will be prompted to select the DLL file. If I point to the DLL that came with the application (under C:\program files (x86)\US Digital\), the application will run and work properly. BUT if I point to any other copy of that SAME DLL, I will get the same error.

I tired placing copies of the working dll in the same directory of the application but the error still popped out.

I didn't start a new thread because sbuxton had the same problem and he said that he got it working.

[mikeporter]

Well, not exactly the same problem. What you need to do is put a VI_search path line in the application's INI file that points to where the original copy of the DLL resides.

The second step is to delete the DLL from the application data directory to make the rte load it from the location specified in the search path. You can do this operation with a batch file that you have the installer run when it finishes.

Mike...

[natasftw]

---

@ªL¡ wrote:

Problem: I am using a .NET dll in a LabVIEW code that I am writing. It works well while in development mode. Once compiled into an executable file, the application will give an "Error 4 occured at Constructor Node in QSBReadPWMEncoder.vi. Possible reason(s): LabVIEW End of file encountered".

I didn't start a new thread because sbuxton had the same problem and he said that he got it working.

---

He was getting an error related to bad parameters. You're getting an error due to end of file.  The errors are different.  The dll's are different.  It's likely you're using different versions of LabVIEW, different OS, etc.

The problems are barely similar.  He didn't have the same problem.  You should have started a new thread.

Does your executable work on your development machine as an executable or is it broken there as well?

[ªL¡]

Thanks Mike for your reply. Your solution would work (and that is what I was thinking of doing) but I got it working after 3 hours of head banging.

natasftw: it was exactly the same problem that he faced.

Why? I re-read the post and figured that he had it working after reading altenbach post (in which he mentioned other DLLs that might be involved).

So I went and took a look at the directory that I was pointing to and found a second DLL sitting there silently. I copied it to the support directory and voila: it's alive.

The nasty thing in all this issue is that this "other DLL" was not included in the project's dependencies! and to force the inclusion of this library in the executable I had to manually add it to the project and force it to be included in the support directory as well.

So a summary for anyone who might face this problem in the future: make sure to include any other DLLs that came with the library that you will be using in your executable!

[natasftw]

I'm glad you got it fixed.

But, it wasn't the same problem.  You're confusing two ideas here.  You fixed your problem using the same fix.  That doesn't mean you experienced the same problem.  The "exact same problem" comes with the "exact same error code." 

Generally speaking, bumping old threads brings irrelevant information into the discussion of your problem.  It's easier to focus on a problem if you create a new thread dedicated to what you're seeing.

[mikeporter]

The solution of simply copying both DLLs might "work" but it also raises potential legal complications. Remember that the two DLLs that you are going to be packaging with your code are intellectual property belonging to another company -- a company that might object to you including their IP in your application. And there are other issues. What if these two DLLs depend on other (non-DLL) files that also exist in their installation directory? Or what if the DLLs are dependent upon registry entries that are only set during installation?

This approach might work in this limited situation, but I would be leery of taking it as a general approach to solving this sort of problem -- especially since the robust solution is so very easy..

Mike...

[ªL¡]

Just for the record, "His exact same problem" was:

quoting subxton

‎07-28-2015 10:25 AM

Adding in the error handler I get:

Possible reason(s):
LabVIEW:  End of file encountered.
=========================
NI-488:  Invalid argument or arguments to function call.

Which is the "exact same error code" that I got.

And I didn't want to open a new thread and repeat all the hassle.

Anyways thanks for your help

[ªL¡]

Adding in the error handler I get:

Possible reason(s):
LabVIEW:  End of file encountered.
=========================
NI-488:  Invalid argument or arguments to function call.

Which is the "exact same error code" that I got.

And I didn't want to open a new thread and repeat all the hassle.

Anyways thanks for your help

[ªL¡]

mike:

The DLLS are accompanied with the SDL for a sensor that I am working with and provided by the company so I don't think there is an IP issue here.

Thanks and hope I don't face this sort of prblems in the future

AA