Solution
This error can occur for multiple reasons, the steps to take will depend on whether the error only occurs on the deployment machine or if it reproduces on both the development environment and the target machine. Evaluate the error and complete the following steps accordingly.
Deployment machine errors
If this error is appearing only on your deployment machine, the cause is often a missing version of the .NET Framework, or a missing/unlicensed driver or DLL. Try the steps below first if you are encountering this error exclusively on your deployment machine:
- Install in the deployment machine the .NET version that was used in the development machine to build the executable. You can download the missing version of .NET Framework from Microsoft's website. Check Additional Information for information on determining what versions of .NET you have installed.
- Make sure all NI and third-party drivers and dependencies being used by the executable are installed on the computer trying to run the executable. Also, verify that you have the same versions of the drivers and that they are licensed correctly .
Deployment and development machine errors
If you are seeing this error on both your development and deployment machine, try the steps below. These steps are also helpful if the above steps do not address the error for deployment-side executables, as they can help to narrow down the cause of the error and address it more generically:
- Try mass compiling the project you used to create the executable and create the executable again.
- If you are using XControls or Type Definition Controls you can try checking the Disconnect Type Definition option in the Build Specifications and add the XControls/Type Definition controls to the Always Included section.
- There might be dependencies from a 3rd party DLL that the LabVIEW executable cannot find because they have not been deployed with the executable. To work around this issue place the DLL being called in the same folder as the executable (make sure these are not within a subfolder) the problem should be fixed. You can include the DLL in the build of the executable and change the output folder to be the same as the executable to avoid copying the files.
- Try debugging the executable remotely to identify where the error is occurring. This will give you more information on what might be the cause of the error.
- Try the same steps outlined for addressing Error 1502, especially if you encountered any errors while building your executable.
- When using LVOOP and looking to implement a Plugin architecture, you should use the paths to load the LabVIEW classes dynamically using the Get LV Class Default Value VI. Check the Source File Settings to see where is the output folder of the LV class, use the "Always Included" option for the LV classes being called dynamically. If you are not using a plugin architecture then you can place the LV classes directly in the block diagram. In this way, the Application Builder should identify that the class is being referenced and you don't have to select the "Always Include" option in the application properties. Keep in mind your classes may not be loaded in memory when the application starts up even if they are included in the executable.