Issues Calling C#.NET DLL from LabVIEW

[TeaAndBiscuits]

I have a VI which calls a DLL.

Happy situation:

VI is part of project. DLL is part of project (in dependencies). They both are in same phyisical folder.

VI is able to communicate with DLL when run in development environment.

Unhappy situation1:

I run VI by itself. IT is still n same location as DLL.

VI is not able to communicate with DLL. Since the DLL initiated actions are not seen.

However VI does not return any errors.

Unhappy situation2:

The complete project is moved at different location including VI.  DLL however is at the old location.

VI is not able to communicate with DLL. Since the DLL initiated actions are not seen.

However VI does not return any errors.

What may be the reason for Unhappy situation1. How can this be overcome?

i.e. will I ever be able to communicate to DLL when my VI is run by itself & not a part of the project?

 What may be the reason for Unhappy situation2. How can this be overcome?

i.e. will I ever be able to communicate to DLL when project is run from a different location?

[smercurio_fc]

---

Sandeepvd wrote: 

What may be the reason for Unhappy situation1. How can this be overcome?

i.e. will I ever be able to communicate to DLL when my VI is run by itself & not a part of the project?

---

I don't quite understand what the difference is between this and the "Happy Situation" in terms of how you are running the VI.

---

 What may be the reason for Unhappy situation2. How can this be overcome?

i.e. will I ever be able to communicate to DLL when project is run from a different location?

---

This is by design of .NET. The .NET Runtime has a specific method for finding assemblies, and it is documented by Microsoft (http://msdn.microsoft.com/en-us/library/yx7xezcf%28v=VS.100%29.aspx).  If you wish it to work regardless of where your project is, then you need to install the assemblies into the GAC.

[TeaAndBiscuits]

Thank you 'smercurio_fc'

The difference between "Happy situation" and Unhappy situation1" is:

Happy...I run VI when project is openned and VI is launched from the project.

Unhappy1:....From windows explorer...I just launch VI (not the LabVIEW project)

Unhappy1 (only VI run) is not able to detect the DLL, even it is in the same folder location. Don't know why?

In case Unhappy2:

I believe it is LabVIEW (caller) which is trying to find the assembly, not the .NET. The .NET assembly is being used.

Although my LabVIEW project is in different location than DLL,

I specify the DLL path in my LabVIEW "Involke node",

Isn't LabVIEW supposed to detect the DLL?

[Perry_S]

Hi Sandeepvd,

I found a knowledge base article that could help. Here is it:

http://digital.ni.com/public.nsf/allkb/BF3AB44069EB3E9D8625755400758E9A?OpenDocument

A question that I do have is are there any dependancies to this DLL? What language is your DLL writen in.

Perry S.

[TeaAndBiscuits]

Hi Perry.

Per the link you sent (answer option2), windows (LabVIEWVI ) should search the DLL which is located in exact same location, when VI is opened by itself (not part of the project), isn't it?

My DLL is a C#.NET DLL.

I did not understand when you said dependencies. The DLL and its dependencies get called and perform correct operation once DLL is called.

The root is DLL does not seem to get called

-when LV VI is run from same location (but not as part of the project) .

To make a note again, my LV functions (application directory, current VIs path) etc provide same outputs in both the cases.

I do need to mention that the LabVIEW function 'default directory' returns "C:\program Files\National Instruments\LabVIEW 2010". But it is applicable in both cases. When VI is openned and run within the project (LabVIEW envioronment), or by itself without openning a project (but LabVIEW environment again)

Thanks

[smercurio_fc]

---

@Perry S wrote:

Hi Sandeepvd,

I found a knowledge base article that could help. Here is it:

http://digital.ni.com/public.nsf/allkb/BF3AB44069EB3E9D8625755400758E9A?OpenDocument

A question that I do have is are there any dependancies to this DLL? What language is your DLL writen in.

Perry S.

---

That article applies to "regular" DLLs, and has no bearing whatsoever with .NET assemblies. The only thing that .NET assemblies and regular DLLs share in common is the .dll extension. Why Microsoft chose to use .dll as the extension is a complete mystery to me, and has led to unending confusion.

[Norbert_B]

---

@TeaAndBiscuits wrote:
[...]

Although my LabVIEW project is in different location than DLL,

I specify the DLL path in my LabVIEW "Involke node",

[...]

---

The path stored in the constructor node (which is necessary before accessing the .NET assembly using invoke or property nodes!) is kept, if possible, as a relative path. So if your assembly is stored in the same folder as the VI, the relative path should not include 'folder-information'. So if you move sources (either DLL or VI), you have to update the path-information in the contructor node in order to find the correct assembly. The only exception are assemblies, which are stored in the Global Assembly Cache (GAC).

Therefore, i do not really get it, why there should be a difference between use-case 1 (lvproj) and use-case 2 (stand alone vi).

But it explains use-case 3, if you do not update (modify) the VI to the new (relative) position of the DLL-file.

I never encountered any difference for use-case 1 and 2, therefore it makes sense if you post a small example here.

thanks,

Norbert

[EDIT]: What version of LV are you working with?

How do you know that there are no errors in the VI (meaning: what does your error handling look like)?

[TeaAndBiscuits]

Hi Norbert.

It's LV2010.

#1

I do change the path in the constructor node when I change the location of my VI.

What I am finding is...the only way my LabVIEW project can find my .NET assemblies is only if .NET asasemblies are in the folder or sub folder.

(Or in GAC which I have not done). If not so, LabVIEW is unable to find them even though I specify the path in the constructor node !

#2

Now, relating to LabVIEW VI's inability to find the .NET assembly even when both of them is in the same folder, I am also puzzled.

Again, when VI is run as a part of (an open) project, it finds it, my assembly does what is supposed to do (communicate to a sever application)

but when I run my VI (from LV environment also) without launching the project, it just can't locate this assembly.

Interestingly in both above cases, VI or constructor node returns no error !

#3 My .NET assembly works with instrument. Hence to know if it is called or not/works or not, you need to have the instrument.

(When it works, it returns the info from the instrument)

But I am posting the code, and the steps to replicate as below anyhow.

______________________

Page 52 of the pdf is what is used to call the DLL.

The project is:TechSupportProj.lvproj.

The file is:TechSupport.vi.

To reporoduce the problem.

Download www.newport.com/NSTRUCT .

Apart from selected defaults, choose "CONEX-PSD" for download.

Replace the folder

C:\Program Files\Newport\Instrument Manager\NSTRUCT\Instruments\CONEX-PSD\ with attached ZIP.

Your project is:TechSupportProj.lvproj.

Your file is:TechSupport.vi.

First launch:

C:\Program Files\Newport\Instrument Manager\NSTRUCTServer\Bin\NSTRUCTServer.exe. This will run in the systems tray.

Now you connect Newport's CONEX-PSD9.

Now you are ready to replicate the problem that I see.

Problem:

When I call VI as a part of the project...it sees the instruments

When I call VI alone by itself, I do not see the isntruments.

Even a project, VI is not able to locate .NET assemblies if they are not in the folder-subfolder path.

[Beutlich]

Hi TeaAndBiscuits

I went through the setup and (naturally) I had no instruments for both, but I did notice one thing that would act as a discrepancy between the VI loading assemblies inside and outside a project. If I ran the VI from another folder first (say the desktop), then the dll would be loaded from that location instead of the same directory as the VI (since it is already loaded into memory). It looks like the loading of that dll is fine, but if that dll then loads other dlls based on relative paths, then that may cause an issue.

Restarting Labview will unload the dll so that it will load from the place on file. The project explorer allows you to navigate to the location of the dll dependency on disk, so it may load it from the correct location instead of using an old loaded library which a VI without a project might do. You should be able to get use case 3 (project in arbitrary location, dll in different location) via the comments above. Let us know if restarting LabView and running the vi as the first thing LabVIEW does when opened has any different impact. If not, could you post an image of the error when it pops up? It sounds like it is likely a problem with the handling of the third party dlls, as opposed to the LabVIEW loading/unloading nodes.

[TeaAndBiscuits]

Hi BigCheese.

Thanks for the note. Pls see my comments in blue.

"I went through the setup and (naturally) I had no instruments for both, but I did notice one thing that would act as a discrepancy between the VI loading assemblies inside and outside a project. If I ran the VI from another folder first (say the desktop), then the dll would be loaded from that location instead of the same directory as the VI (since it is already loaded into memory). It looks like the loading of that dll is fine, but if that dll then loads other dlls based on relative paths, then that may cause an issue."

When I run the VI from its original location, then also VI is not (seemingly) loading any DLLs; then how would it load these DLLs if VI is running from say Desktop (even if DLLs are on desktop, I still see it as a challenge).

It is correct that the DLL called by LabVIEW indeed calls other DLLs at different locations. But how to distibguish that VI calling to DLL is problem, or DLLs calling to DLL is problem?

In fact I suspect the first one, because, when the VI is being called from the project, (which forces LabVIEW to call the first DLL correctly) the DLL calling the other DLLs is not a prolem though they are in the relative paths.

You said

" Restarting Labview will unload the dll so that it will load from the place on file. The project explorer allows you to navigate to the location of the dll dependency on disk, so it may load it from the correct location instead of using an old loaded library which a VI without a project might do. You should be able to get use case 3 (project in arbitrary location, dll in different location) via the comments above. Let us know if restarting LabView and running the vi as the first thing LabVIEW does when opened has any different impact. If not, could you post an image of the error when it pops up? It sounds like it is likely a problem with the handling of the third party dlls, as opposed to the LabVIEW loading/unloading nodes."

Case 3 (project a different location and DLLs in other) does not work; except that the (nonGAC) working subset of it is the following

"DLLs called by LabVIEW project MUST be in the subfolder path of the project or EXE (if you build the EXE)"

If DLL calling other DLLs would have been a problem, it would not have depended on ,....

 if ..LabVIEW is run from the project or not? Or

..if the DLLs called by LabVIEW are in the folder/subfolder of the project or not.

Thanks