How to organize a reuse function that uses a .Net control

[Hooovahh]

So I have a bit of a dilemma that I'm struggling with.  I found an neat function on the community that does what I want and uses a .Net 4.0 control.  I don't actually need the control to be seen, just be available to call into some system level functions.  It works great when in a project but I want to wrap this up into a reusable function, and put it on the palette with VIPM.  The problem is a VI on the palette isn't in a project, and according to this document "National Instruments strongly recommends that you always put VIs that use .NET objects in a project."  But if it isn't, then the .Net DLL needs to be loaded from "The directory that contains LabVIEW.exe".

What I think the article means is is needs to be found in the search path setup by LabVIEW and a default one will fine DLLs placed anywhere under the install folder.  So in my case putting the DLL under the user.lib will work just fine in source.  But if I go to build a VIPM package, it will automatically build in the dependencies to a path that won't really exist, and then dropping it on the palette will result in a broken VI. It seems to be looking for the DLL in a directory named <Package>_internal_deps and the control is broken.

I can look into finding ways to perform this same function using non-.Net controls and DLLs, but I'd like to know the best way to try to have a function on the palette, that uses a .Net control for future reuse functions.  Any suggestions?  Thanks.

EDIT:  And for bonus points, is there any complications when dealing with making applications?  I'd really just like to drop this VI from the palette into my code, and then when I build an EXE it knows the dependencies and includes the .Net control DLL.  At the moment it seems I need to specify to always include the DLL, and I need to make sure it is in a folder called "data" next to my EXE.  I typically have the application builder settings rename this Support Directory to "Support" but that doesn't seem to be good enough for .Net and I need a seperate folder called data with the DLL in there.  Please tell me there is a reason for all of this madness, and that it is Microsofts' fault.

[KathrynTheGreat]

Hi Hooovahh,

My understanding, from the article you linked, is that the assemblies need to be installed in the same folder as LabVIEW.exe. On most computers, this would be Program Files (x86) > National Instruments > LabVIEW <version>. Just to clarify, when you save the file there and attempt to build a VIPM Package, the package tries to reference the file in a different location?

As for your question about building .Net controls into applications, based on the article you linked, putting it into a “data” folder seems to be the correct method. I also found another article specifically about stand-alone applications that include references to .Net objects that you might find helpful. There are certain requirements for .Net Configuration Files for use in LabVIEW, as well, and this article is a good overview of the topic.

[Hooovahh]

Okay I think I figured it out.  So VIPM recognizes that there is a DLL dependency, and when building a package includes it.  When that package gets installed the DLL is added to a folder in the user.lib, and the VI on the palette is linked to that DLL.  But what VIPM doesn't recognize is that this DLL depends on another DLL and VIPM doesn't include that.  So when the package is installed and it is dropped from the palette, the VI has no broken arrow, but the contol says "Control cannot be loaded" or something.  And there is no browsing dialog indicating that something is missing.

Additionally when building an application, the application builder seems to recognize that this is a dependency, and includes the .Net control DLL.  But what it doesn't do is include the DLL that that DLL depends on (just like VIPM) and that needs to be manually added to the always include list.

So what I needed to do is add some code in my VI that is never indended to be called, but causes the second DLL to be recognized as a dependency, and to be included in VIPM building, and the application building process.  Now when I build a VIPM package, or an appliation, the two DLLs required are included.  It seems this wasn't an organization issue at all, but a dependency one I didn't know existed.