Trevor Christman

I would not expect friending an item to bring that item into memory. I suppose that renaming things in LabVIEW could have troubles if the thing is already in memory somewhere else. If you try the build in an environment without your additional tools installed, is it successful?

My implementation of Friendship and Community scope was a year or two ago, so I may be fogging some details. Here I go anyway: The library remembers the paths of its friended items because remembering the qualified name and path of a friend is free behavior provided by the foundational components that friendship was built on. I didn't foresee that there would be any problems with the existing behavior, so I didn't do any extra work to check only the qualified name of friends. It would be possible to change this in the future, but it would make save for previous a little rough, and in general I don't like having subtle behavioral changes between versions of LabVIEW. Lets see if we can get the behavior you want in some other fashion. Some possibilities that come to mind are: If you were willing to store your friended item in user.lib while it's being written, then when the friending library is saved I'd expect it to store the path '<user.lib>/foo/MyThing.lvlib'. When you deploy your value-added component, it would land in <user.lib> and everything should connect up fine without a crossload dialog, right? If you write some kind of friended command-broker kind of VI that gets distributed with your library and accepts commands which it forwards to the rest of the library, you could require that commands passed to the broker also include some kind of password. You could lock the broker and add-on clients of the broker, and that would be roughly as secure as the friendship validation scheme already in place (the validation scheme already in place is good, but not professional-caliber-cryptography secure). Do either of these options sound workable?