Missing External Function : 2013 SP1 Application Builder

[Don@GETS]

The target Application is referencing a C call DLL on my target. I have included all local (non-NI) dependencies in the application builder. I have used this tool for many Vis but this is the first one to reference my DLL function(s). Thinking it may not be how I generate the application, but how I reference the DLL. The actual error message : " Missing external function v5565_dll.dll:v5565Open: C in VI v5565_dll.lvlib:v5565Open.vi ".

cheers

Don

[Haagen-Dazs]

Hi Don,

When are you getting this error?

Does the error occur when building? Does the error occur when running the exe? Do you ever get the error in development 

I think there could be a couple causes of this.

1) You are not including the dll in your build which you can check by generating the exe preview and determining if the DLL is being added in.

2) The DLL is added in but the exe is altering its location. Try using relative paths and conditional disables to get a working exe and working development version.

If those things dont help then post a project with just a VI setup to call your DLL and I can try to run it on my end.

[Scott_Torrance]

Patrick,

I apologize if this is bad form butting into this thread - but I'm having a similar problem.  I've ported an old app with a CIN to Labview 2011, replacing the CIN with a Call Library Function, and an associated dll.

Everything seems to be working fine on my development computer.  But when I created a stand-alone exe, I'm getting the "Missing external function engmon.dll:EngMonMain:C in VI engmon.vi".

I have only one external function in my dll, EngMonMain().  I'm declaring it:

extern"C" {

__declspec

(dllexport) int32_t EngMonMain ( /* inputs */....

This is the function listed in my Call Library Function, same case, and specified as being called with a C calling convention in the Call Library Function.

The dll source code file is a cpp file - but my understanding is that the extern "C" declaration should deal with any name mangling - and as mentioned, the app works fine on my development machine, either within Labview or as an executable.  Its only when I try to run an executable version on a machine not equipped with Labview when I have a problem.

BTW - based upon searching on this topic, I also tried manually installing the Labview standard 2011 run time engine (my original install of the executable included the run time engine, but some folks had suggested I might not have full standard version).  No change.

Any advice?

Scott

[Haagen-Dazs]

Hey Scott,

I think my post above is still applicable in your case. Are you moving the EXE to a target machine? Is the DLL being transferred manually or included in the build? If it is included, how are you referencing the DLL in code? The path to the DLL in the project may not mimic the path to the DLL in the EXE. Another thought I had which could be used is creating a debuggable executable.

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

This will allow you to step through the code in the EXE and see exactly what values are getting fed into your DLL and hopefully identify where the problem may be coming from. As always, if you have a simple example you can post here then I can take a look at your code and try to determine what may be going wrong.

[Scott_Torrance]

Patrick,

Thanks for responding - unfortunately due to some limitations I have on what machines I can put on which network, I can't presently try the method you suggested (although, I'll see what I can work out).

I am moving the application to a target machine which does not have Labview, and this is where the problem occurs (everything works fine on my development computer with Labview, including running the executable).

The dll is definitely installed on the target machine - it resides in a data directory below the directory where the executable is residing, just as the executable does on my developmental machine.

The dll is referenced using a Call Library Function in my Labview application.

It appears the executable is finding the dll on the target machine however - it just seems like the one exported function in the dll isn't being found.

The above is based upon an experiment where I copied and ran the executable from the desktop on the target machine -  in this case, when I ran it, a dialog box popped up saying that it couldn't find the dll, and I had the opportunity to browse for it, which I did.  When I located and selected the dll, the executable responded in the same manner as the original problem - not being able to find the specific EngMonMain function (missing external function).

The stand-alone executable (plus run time library) was installed on the target machine using an installer created with the labview application builder.  The install put the dll in the data directory below the executable's location (in a directory underneath "Program Files (x86)")

After running into this problem, I also tried to manually install the standard run time library for labview, in the hopes that something was missing in the version that was installed with my application (no luck with this).  This was based upon some problems others had run into, where it was indicated that some lesser versions of the runtime library caused problems.

It seems like maybe there's some issue in the function not being exported properly?  As previously mentioned, I'm using the "__declspec (dllexport)" declaration method in my actual code to export the "missing" function.

What seems so strange is, that everything works fine on the developmental machine.

Scott

[Haagen-Dazs]

Hey Scott,

Can I see the function tab of the call library function node? I am curious to look at the way you are specifying your library path. If you are specifying it on the block diagram then I would like to see that also. Is this DLL thread safe? If it isnt then you should make sure you are running the DLL in the UI thread.

[Scott_Torrance]

Patrick,

Thank you for your assistance!

I have a feeling you are on to something here - this is my first time using a dll with Labview - previously, I used a CIN, but now that we're all on Windows 7 here, that is no longer viable for this application.

I'm honestly not sure what is or isn't thread safe - as you'll see in the graphic, the "Run in UI thread" is checked.

Scott

[Haagen-Dazs]

Hey Scott,

I believe that is your problem, you are trying to find the DLL at that location which does not exist on your deployment machine but does exist on your local machine which is why the EXE works correctly on your local machine. What you need to do is check the box for specify on diagram and then use relative paths. There are a few ways to do this but the easiest in my mind is to use the Application Directory VI in conjunction with build or strip path. You will start from the “Application Directory” and then use the build path to dive down the folder hierarchy or strip path to go up the folder hierarchy. String a few of these together until you land at the DLL and take note that the last step you will need to add engmon.dll.

Application Directory:

http://zone.ni.com/reference/en-XX/help/371361H-01/glang/application_directory/

Read the help carefully here because there is different behavior for when you run in the development environment and when you run as an EXE.  Depending on your folder layout and location of the DLL this may not be an issue. However, I recommend adding a condition disable to your code which will allow you to modify the path depending on if the code is running standalone or in development.

Conditional Disable Structure:

http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/creating_cond_disable_struc/

http://www.ni.com/white-paper/9853/en/

http://zone.ni.com/reference/en-XX/help/371361J-01/glang/conditional_disable_structure/

[Scott_Torrance]

Patrick,

You are the man!  Thank you so much.  So, I basically made use of all of your ideas - I used the conditional disable to create two conditions - one using the run time engine, and one not using it (the development environment), and developed two different paths to the engmon.dll dependent upon which case was being exercised.

It worked like a charm.

I'm more surprised there isn't a more elegant solution to this problem that is part of the labview project.  It seems like this would be needed for virtually any application that was going to be used in conjunction with the real time engine on other machines.

However, I'm so grateful for the assistance.

Something that did throw me for a loop initially - when I deleted the path to the dll in the Call Library function, Labview would then try to search for the dll, and then ask me to find it - but there was an option to essentially cancel the search and then everything was fine... but it just had me thinking initially that it wasn't legal to just specify the name of the dll without the path.

I can't guarantee I've done this real elegantly, but I'm attaching the solution in case someone else runs into this problem.

Scott

[JASRI]

Problem: “Missing external function BScanDLL.dll”
Development computer
• Windows 10
• i7, 16 GB Ram
• LabVIEW Prof Dev System 2013 SP1
Target computer
• Windows 10
• i7, 16 GB Ram

1. I have a DLL built using MSVC 2017
2. The DLL works fine in development mode
3. It also works as an EXE on my development machine
4. I built an installer so I can distribute to other users. However, when I ran it on the target computer, I got the following error:  Missing external function BScan_DLL.dll.  I can see the dll in the "data' folder