Labview built executable locating DLL location at startup

[JETMike]

Hello, I am fairly new to LabVIEW, but am working on a project that uses LabView version 2020.  The project that I am working with has a VI that uses this DLL extensively.  This DLL is one created in Visual Studio 2022 and is a .NET 2.0 standard one.  It is a 32 bit DLL and works fine within the confines of the project/software.  However at startup, I am queried with the following:

I do not wish for this popup to appear and somehow tell (within my Labview project or VI) to use this dll which is not located in the same folder as the executable.

I have had our LabView developers look at using a call library node, but there is no input which references a location/path.

Thank you for any tips/pointers on this matter.

Thanks

__PRESENT

[altenbach]

---

@JETMike wrote:

I have had our LabView developers look at using a call library node, but there is no input which references a location/path.

---

Yes there is, once you check that box.

[JETMike]

Thank you for that tip.  Our LabView developers have already tried this and it still doesn't work. The DLL is located in a folder one level underneath the executable.

[altenbach]

---

@JETMike wrote:

Our LabView developers have already tried this and it still doesn't work. 

---

This is way too vague to be useful. What exactly have they tried and in what way doesn't it work?

[mcduff]

Is this occurring in the development environment or an EXE built by LabVIEW? For an EXE you need to make sure it is included in the EXE and placed in the support directory, EXE\data. Lastly, this thing is a bit perplexing to me but I just had this issue; when building the EXE there is the VI destinations option, you can check same as caller or specify where to put the DLL. In my case both put the DLL in the data folder in the EXE, but I had to use the "same as caller" instead (which also put it in the data folder), otherwise I got the dialog you are getting. So both were put in the same location, but that error appeared, that is the weird part.

[JETMike]

This is occurring in the environment where the EXE has already been built by LabVIEW. I am currently putting the DLLs in a subfolder named Support.  There is a folder named "Data" which houses another DLL for a 3rd party product. I can try putting the DLLs there and see what happens.

__PRESENT

[altenbach]

---

@JETMike wrote:

This is occurring in the environment where the EXE has already been built by LabVIEW. I am currently putting the DLLs in a subfolder named Support.  There is a folder named "Data" which houses another DLL for a 3rd party product. I can try putting the DLLs there and see what happens.

---

Obviously, this would have been important information from the beginning!!! Can we assume that specifying the path on the diagram actually works in the development environment?

A common mistake when defining relative paths is the use of  "current VI path" instead of "application directory". In a built application the VI path is inside the exe and any relative path that worked under development will most likely be invalid. (details).

[Andrey_Dmitriev]

---

@altenbach  a écrit :

---

@JETMike wrote:

I have had our LabView developers look at using a call library node, but there is no input which references a location/path.

---

Yes there is, once you check that box.

---

This suggestion is not applicable as long as we talking about native .net Assembly.

[Andrey_Dmitriev]

---

@JETMike  a écrit :

Thank you for that tip.  Our LabView developers have already tried this and it still doesn't work. The DLL is located in a folder one level underneath the executable.

---

Yes, this is common mistake. I'm very curious how you was able tried to specify path for .net assembly, but anyway,  for everyone who is in the trouble with external code like this:

would like to recommend the following troubleshooting steps.

First of them, just create a very basic DLL without any dependencies, something like that:

namespace MyClassLibrary
{
	public class MathClass
	{
		public MathClass() { }

		public double Calculate(double num1, double num2, string op)
		{
			double result = 0;
			switch (op)
			{
				case "Add":
					result = num1 + num2;
					break;
				case "Sub":
					result = num1 - num2;
					break;
				default:
					break;
			}
			return result;
		}
	}
}

Now create DLL, call it from LabVIEW, check that everything is OK. Build App and run it, deploy to the stand alone machine or check on Windows "OutOfTheBox" running in Virtual Machine. Once simple DLL is functional, proceed with more complicated in same way.

When Application is running (for example, on the development machine) and you are unsure from which location the DLL was loaded, then the easiest way to check this is using SysInternals Process Explorer, which will show all loaded DLLs in lower pane:

Now, if your application is unable to locate DLL, then you can use another tool called Process Monitor. On the first start you will be asked for Filters, I would like to recommend to setup two — one for Process application and another one for Path (this will reduce amount of entries in the list), you should use your names, of course:

Now keep Process Monitor running and start your app, this is how it looks in case of successfully loaded DLL:

And this is what happened in case of failure (like shown on the first screenshot):

And now you see clearly where DLL is expected to be located. The first location, which is checked is \data subfolder (I deleted DLL from this), the next one is original source location (yes LabVIEW still remember this, but I renamed it to simulate this issue), then the same folder where executable is located and so on and so on, but the underneath folders will be not included.

And if your DLL dependent on some other DLLs, then Dependencies Tool (https://github.com/lucasg/Dependencies) is also helpful:

Usually these three tools are sufficient to get rid about this trouble.Sample project in the attachment (LV2018/MSVC2022).

[JETMike]

Thank you Andrey for the information about Process Explorer/Monitor and the Dependency Checker/Walker.  This DLL was build with Visual Studio 2022 and the target framework is .NET Standard 2.0. The platform target is AnyCPU which means it will run on any processor. However what is being used for the LabView project, the DLL in question is 32-bit.   It has a couple of public methods in it, that call another class library DLL.  

I'm not sure what else to say that may be of help. One of our engineers who is more experienced in LabView thinks that the installer has something to do with this issue.  I'm not convinced though.

If there is anything else I could look into for this problem?

__PRESENT

__PRESENT