LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Build Execution Errors

We have a LabView tool suite that we developed and built in-house (using LabView 2017 32bit), which also uses an underlying DLL that we also developed and built in-house (using Visual Studio 2017). On a Windows 10 64bit PC (this PC has the full development versions of both LabView 2017 32bit and VS2017) I used Visual Studio 2017 to re-build our "interface" DLL followed by using LabView 2017 32-bit to re-build our LabView Tool Suite which uses our "interface" DLL (the LabView project build absorbs the interface DLL as a dependency and places it in the data folder). I tested the full build on the same Windows 10 PC it was built on, and everything loads and works fine. Then we decided to move this build to a PC running Windows 7 64bit. On that Windows 7 PC we installed LabView 2017 32bit RunTime and Visual Studio 2017 RunTime. When launching the labview executable we built we get the error "Missing msvcp140d.dll", which is a VS 2017 debug dll. We found the debug DLL and moved it in the same data directory where our built "interface" DLL file resides. The "Missing msvcp140d.dll" error went away when trying to launch the LabView built executable, however we now get a bunch of other errors "Missing External function calls to the interface DLL" calls such as the write, hw_status, close etc which are really initialization calls to the interface DLL. As this looks like a VS2017 issue, are we maybe missing more visual studio files that need to be included in our LabView build? Or maybe are we missing or not setting a build property in VS2017 prior to building our DLL? We are lost and any help would be appreciated. One last addition is that we build our "interface" DLL using VS2017 in Debug mode.

0 Kudos
Message 1 of 6
(2,008 Views)

I'd install the Visual studio redistributable the proper way.

 

Probably:

https://www.microsoft.com/en-us/download/details.aspx?id=5555

0 Kudos
Message 2 of 6
(1,940 Views)

Our IT does the installation. Not sure what "install the Visual studio redistributable the proper way" really means. We installed the full Visual Studio 2017 development suite and that worked, but we need to be able to use our DLL without having to do that on every PC. Have not been able to find information as to how to build the DLL to include additional DLLs if necessary or information on how to install redistribution the proper way. I assumed installing redistribution on a PC only requires installing it with it's default setup and any DLL we build with VS2017 will work.

0 Kudos
Message 3 of 6
(1,901 Views)

@nlipsas wrote:

 LabView Tool Suite which uses our "interface" DLL (the LabView project build absorbs the interface DLL as a dependency and places it in the data folder).

That won't work. Use the suggested redistributable to install the runtime. That is the proper way to install it.

0 Kudos
Message 4 of 6
(1,888 Views)

IT installed the Visual Studio 2017 redistribution or VS2017 RTE (not sure what it is called) on the destination PC and it did not work. The DLL issued errors when it was being used/accessed by our LabView application. We use code interface node in our labview program to make specific function calls to our custom DLL.

0 Kudos
Message 5 of 6
(1,881 Views)

If there is a copy of the runtime dll in your executable, then you should delete it. The dll that was officially installed should be used.

 

If this improves things, you could change the project so it doesn't automatically include the dll in the build, so you don't have to fix this manually each time you make a new executable.

 

I hope you're not really using a Code Interface Node. Those have been obsolete for a decade. You probably mean a Call Library Function Node. CINs are probably not even possible to make anymore... If you are really using a CIN, switch to a CLFN. 

0 Kudos
Message 6 of 6
(1,852 Views)