Multiple LabVIEW/.NET Interop Problems

[NPrice]

Hello,

I'm having multiple problems trying to get some .NET assemblies I have running smoothly when being called from labVIEW.

1)  I have some .NET assembly dll's that rely on certain other configuration files being present in the same directory as them.  When accessing them through labVIEW it seems that the assemblies are copied elsewhere (to a temporary directory that is created and deleted during program excecution) to be used and so they can't find these configuration files anymore.  A temporary workaround is that the .NET assemblies also try to connect to our server to get these configuration files if they can't be found - but I need to get this software running even if that server connection is unavailable.

I've tried locating the temporary folder labVIEW creates for a VI that's running and copying them there, to no avail.  Is there any way to know exactly where these dll's are being accessed from when LabVIEW is running the VI?

2) Assuming that I'm not missing something obvious in my first question, is there any way to configure LabVIEW to just run .NET assemblies from the location they're stored in rather that letting it copy them goodness knows where (random temp directory, memory etc.) for use?

3) Is there any way to use 2 different versions of a .NET assembly in different VI's without shutting down LabVIEW and restarting it?  Any time I try referring to a different version of an assembly (whether in concurrant VIs or by closing down all open VIs and creating a new one) it will always default to the first version that was used since LabVIEW was started.  (ie. if I use myasm.dll version 1.0.0.0 in a VI then later try using myasm.dll version 2.4.12.1 in any other VI whether or not the first VI is open LabVIEW will always use methods from version 1.0.0.0)

4) A follow on from (3)... is there any way to remove a .net assembly from LabVIEW's "memory" once it has been used?  It's annoying to have to shutdown LabVIEW and restart it every time I need to re-build a .NET assembly that I'm working on for interop.  (especially becuase starting LabVIEW 8.0 is nowhere near lightning fast).

Thanks,

Neil

[minnellac]

I'm not sure that I have any answers for you, but one thing I would look into is the working directory. LabVIEW doesn't seem to care what the working directory is, but some dll's really do care. Maybe LabVIEW is changing the working directory (can happen any time you use a open/save dialog) after loading your dll's, and when they go to look for the config files, they are no longer in the working directory? You could try putting everything in the same directory as your vi, and try calling everything right away (for example, load the dll's and configure them in the init case of your program).

One way you can check the working directory is to press a browse button on a path control; the directory that you go to be default will be the working directory. I haven't figured out a way to programmatically change the working directory within LabVIEW without using external code.

Another change that may help (particularly if this is the problem) is passing an argument to your dll to tell it where the config files are.

good luck,
Chris

[NPrice]

Hi Chris,

Thanks for your response.  The DLL's I'm working with just care about where their configuration files are, beyond that directories aren't important to them. 

LabVIEW is definitely changing the working directory, depending on where and when I try to get the current directory from and how I receive a lot of different answers in various temporary locations underneath \local settings\ as well as the original directory the VI started running from.  Running a filewatcher on the computer also reveals labVIEW is creating temporary directories, copying assemblies there, then deleting them immediately too - I',m wondering if this is where my problem in (1) is stemming from.  I tried that path control trick you mentioned and it thinks the working directory is the VI's directory using that method - and the configuration files are stored there so the DLL's that are being called are not being executed from the same directory.

Passing an argument to the dll is unfortunately out of the question, it's actually an integral part of another framework we have running.  I'm beginning to think that maybe I'm going to have to find a way of editing that though.

Thanks,

Neil

[minnellac]

If I understand correctly, you are saying that LabVIEW is creating a temporary directory with your dll, and running it from there. So the problem is that the dll can not find it's configuration files because they are not located in the same temporary directory?

Okay, have you found a way to determine where the dll is actually running from within LabVIEW? This is getting hokey, but if you could copy the config files into that directory once you determine what it is, and before you call the function that reads the files, maybe you could alleviate your problem.

This whole temporary directory thing sounds weird to me. Is this new with 8.5? I have applications that I have moved from 8.2 to 8.5 that use .NET assemblies, and I haven't run into any of these problems.. but I also don't need any of them to access local files.

Chris

[NPrice]

I've actually got about 10-15 different copies of the configurations stored all over my computer, in the LabVIEW executable path, the application path, the dll path etc. but none of them seem to work.  These temporary directories I was wondering about are actually created and deleted (and randomly named) during the VI's execution so using them is out of the question (so far as I can tell).  I've attached the .NET code for the file system watcher that I keep running while executing my VIs so you can see exactly what I'm talking about with these temporary directories.  (You'll have to edit the path slightly if you run it as it's set up for my pc and username).

I've actually gotten around this problem right now by having one of our engineers hardcode another location check in the .NET dll that depends on an environment variable that can be preset with the path information.

As an aside I've never really had too many problems with .NET code being accessed from labVIEW before - typical that it happens on a time sensitive project! 😉

Thanks again for the response and I'm going to leave these questions open hoping someone can shed some light on the issues presented?

Neil

(Oh and I'm running 8.0 right now)

[Eric A.]

Hi,
I think the .NET assembly is being copied to another directory because of a feature called shadow copying.  I found this knowledgebase that discusses how to account for this in your .NET assembly.  I hope this helps but please let me know if it does not.

[NPrice]

Hi Eric,

Thanks for your answer, it does appear that shadow copying is happening here.

My next question however is why?  The answer you pointed me to claims that we can have concurrent development on an assembly whilst LabVIEW is using the shadow copy.  This is not the case however - whenever I try to build a .NET assembly that has been previously referenced in a VI (whether or not that VI is open anymore) the build fails saying the destination file (ie the assembly .dll) is currently in use.  I have to completely stop LabVIEW running to build and then restart it.

Thanks for any insight into this.

-Neil

[Eric A.]

Hi Neil,
I'm not sure why your .Net compiler is acting that way.  Building .Net assemblies is bordering on the edge of my knowledge.  I suspect the issue is not specifically related to LabVIEW.  I would imagine if any program were using the assembly you were building you would encounter the same problem.  I will let you know if I uncover information that is contrary.