09-28-2011 10:48 AM
I am packaging a set of VIs for use by customers, which are basically a helper wrapper around a .NET assembly. My problem is that every time the example VI is opened on another PC, or even another folder on the same PC, LabView displays a warning box that states
"- The .NET assembly expected to be at "D:\original.path.to.folder\my.dll.DLL" was loaded from "D:\new.path.to.folder\my.dll.DLL".
I feel like we've tried everything to resolve this, with no luck. Isn't there a way to specify that the DLL is in a folder relative to the VI?
I am currently using LabView 8.5.
09-28-2011 02:50 PM
Do you have some example code for us to get a better picture of what your doing? Are you using the library function call VI? If so have you tried building the path to the DLL using the "Current VI's Path" function?
09-28-2011 03:33 PM
I don't know how to build a path to the DLL and then feed it into any .NET node, as they don't accept any input path. When you drop a .NET constructor node onto a Block Diagram, you can either specify a .NET assembly from the GAC or you can Browse for one in a folder of your choice. There is no way that I can tell to specify a relative path for the DLL. This is a huge problem for sharing VIs with other users who might have their VIs in a different folder than mine.
09-28-2011 04:17 PM
I have to admit i dont work with .net that often. But can you use the call libary function with the dll instead of the .net construct node. Then from the call library function pass a refernce to property or invoke node. An example of your problem would help.
09-28-2011 05:15 PM
The call function node only works with standard Windows DLLs, not .Net assemblies. With call function, I see that you can pass in the name of the DLL from somewhere else, but the same functionality doesn't seem to exist for .Net assemblies.
Sorry I don't have an example right now, it would take me too long to put one together that doesn't contain proprietary code. But the scenario I'm describing is relatively basic, if you're working with .Net assemblies that is.
09-28-2011 05:34 PM