Why do you not use projects? When to use them.

Question

I responded to a post about what mistakes novice LabVIEW developers commonly make.  One I feel is a common problem is not wrapping up closely coupled reuse code into projects that modularize code sections.
As examples there are nice Instrument drivers that contain all of the functionallity of a specific piece of test equipment.  Keeping these vis that work together in a single reusable project is quite helpful.  Other reusable pieces of code that are less related together might be more of a problem.  For example a "Delay.vi" and a subvi that calculates a CRC for your company's propriatary communications bus have little cohiesion.
Yet namespacing might suggest that those vis sort of go together.  Delay.vi on MyCorp.lvproj does change the problems Delay.vi from Mycorp has when YourCorp has another vi named "Delay.vi" and neither is in any sort of project.
The real issues seem to show up when we forget how each type of LabVIEW containers affect the "fully qualified name" of that peice of code asnd that the FQN effects what we really want...... I want my code to be protected from accidental change because I want to use that other code too!
That make sense.....Lets chat.
Jeff

Answer 1

tst wrote:
The project does not provide namespacing, because it is not a container. You can think of it more as an execution sandbox, although being a sandbox is only one (relatively small, in my personal experience) reason to use a project. What you're thinking of is a project library.
In general, you would want to avoid having your entire reuse library in a single .lvlib, because as you said, there is no real connection between VIs which perform unrelated reuse functions. The obvious answer is to use VIPM - it automatically renames the VIs with whatever namespace you choose, so that each package can be completely separate.
Another alternative would be a packed library for each component, but that has its own set of problems.
Exactly the points I wanted free discussion on!  Things I would point out.:
A  *.lvproj does in fact aid with grouping logically related functions and, does provide some namespacing.  That "On<target ,project> in the FQN is not known to the vi itself but can make a huge difference to the caller!  Lets use A TestStand proxy as an example caller and a UUTxxx.lvproj would be a common grouping of test steps, objects and methods that act to test functionality of "xxx" units.  Say we use a DAQmx device to test these units, create our DAQmx Task and persist it to UUTxxx.lvproj (yes we can do that, Task creation at run time should be avoided but that is another topic).  When calling the lvproject item from TestStand the proxy asks the project for the vi and its dependancies encluding any DAQmx tasks only that project knows about.  Quite powerful namespaceing can be achieved with a simple *.lvproj!
Jeff