call by reference with .NET DLL

[teejimenez]

Hello folks, hoping you can help. Using LV2013 on Win 7 64 bit.

Here is what I'm trying to accomplish. I have a group of different robots, that have different FW revisions and thus use different .NET DLLs. I wanted one set of vis to be able to talk to all of the robots, so I wrote wrappers that open/call vis at runtime for each robot/.NET DLL revision.

Those vis call the low level vis that actually interface with the .NET DLL.

This all works very well when running it in the source code. When I build it though, is when I have a problem. I include the vis that I call by reference in the data (Support) directory, I also include the .NET DLL that it is supposed to call, but it gives me the following error:

Property Node (Arg :1)  in mufasa_Connect.vi->mufasa_robot_init.vi->mufasa_robot_init.vi.ACBRProxyCaller.8AE00006

I can see the Connect vi and the init vi and DLL in the data (Support) directory, so that's not the issue. When I open the Connect vi (in the Support directory), and in the block diagram when I right click on the constructor, it says "An error occurred trying to load the assembly". This tells me that somehow the .NET DLL is not being loaded correctly or that the low level vi is losing that link.

I've tried using the .config file with both versions of CLR to no avail. This is my config file:

<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>

In my build settings, I have the Connect, init vis and .NET DLLs as Always Included and Destination: Support Directory.

My question is, is what I'm trying to do even possible and if so, what am I doing wrong?

[Libbin_la_vida_loca]

Hi teejiminez,

In my experience, when an application works in the development environment but not as an executable the problem tends to be related to paths. I would suggest adding indicators on all of your paths and verifying that the files your application is searching for are in the path directory that is being pointed to.

I also see that in the init VI you are using a ‘Current VI’s Path’ function and then stripping the path multiple times to get down to the actual application directory. If this is causing your issue, it may be more useful to get your path with an ‘Application Directory’ function. 

[mikeporter]

I don't understand. Why are you putting the dynamically called VIs in the data directory? And you said you got the error from the constructor node on the block diagram. What block diagram? Executables don't have block diagrams.

It sounds like you.might not be building your application correctly.

Mike...

[teejimenez]

Hey Mike, thank you for responding. I am new to using Call By Reference. From the reading I did, it seemed like you had to put the called vi into either the or another reference as source when you do the build so that the exeutable knows which vi to open. I guess I miswrote when I said that he error was comig from the block diagram. What i meant to say was that Itraced the error back to the Cconnect vi hrough the use of error indicators so I know that the vis are being called as expected. The vis are not finding the .NET DLL as expected. Where should I be putting the dynamically called vis, if not in the data directory?

Libby,

I believe your post is responded to in this post, as I know I'm calling the vis correctly.

Any more hints, tips are apprecited.

Thank you.

[mikeporter]

On my blog I just did a series on dynamically calling things that includes examples of a build specification. Check the link in my signature.

Basically, in the build you put them in the Always Include section of the source files section and let LabVIEW build them into the application. LabVIEW should automatically include the DLL you need.

Mike...

[teejimenez]

Thanks again, will check out your blog and give it a whirl.

Best Regards,

Tino

[rolfk]

---

@mikeporter wrote:

Basically, in the build you put them in the Always Include section of the source files section and let LabVIEW build them into the application. LabVIEW should automatically include the DLL you need.

---

Just one caveat: LabVIEW can not know about further dependencies of DLLs, so it will include the DLL that is directly called, but if this DLL needs any other DLLs or other files to work properly they will not be included. Such DLLs wiith dependencies really should come with their own installer application that knows what needs to be installed in the system to make it work.