<userlib> files not being found in built application

[Saranac]

Version: 2012 SP1 f5

Key Words: Build Application, <userlib>, DAQmx

I have a project with a Main.vi and and a Sub.vi, both of which make multiple calls to DAQmx vi's in libraries (*.llb).

The project is located in ...LabView 2012\user.lib\this\this.lvproj

I note that when I build the application using the default settings, Main.vi set as Startup VI and nothing else changed, running the application from its default build directory gives load "errors" in that the application cannot load various DAQmx vi's like:

<userlib>:\builds\this\My Application\Application.exe\1abvi3w\vi.lib\DAQmx\configure\task.llb\DAQmx Clear Task.vi

nor can it find:

<userlib>:\builds\this\My Application\Application.exe\1abvi3w\user.lib\this\sub.vi

But if I change the Destination directory of the build from its default to:

C:\Program Files (x86)\National Instruments\LabVIEW 2012\builds\this\My Application

removing the user.lib and moving the build up one level, everything works fine.

Is this a feature of just my installation? My solution seems different from similar problems that I have read about and I can't find a coherent explanation of what I "fixed" by changing build folders. Wait ... there's a search term I haven't tired "build folder" ... nope. Must have something to do with <userlib>, but I'm missing the terminology to say what the problem is.

-Gregory

[JÞB]

<User.lib> is for reuse source code

Executables belong in the <apps> directory

Futher affiant saith not.

[crossrulz]

Why is your project in the LabVIEW directly structure anyways?  Your projects should be outside of the Programs structure.

[Yamaeda]

user.lib is meant as LV's own structure and part of the installation. As such, files from that structure are not included in the .exe. By having your project there you effectively disqualify your own files from the .exe ...

The solution is simple, move your project and it's files to c:\project, your Document and settings or similar.

/Y

[Saranac]

I would like to point out that for the situation described, the problem was solved by just changing the directory to which the built application was directed, not the location of the project file or vi's in the project.

And when did user.lib stop being the folder where users put there vi's? Perhaps I'm misunderstanding your points.

I work with a team of people. We've always kept our VI's in folders in user.lib where eveybody would have access to them. When we recently decided to move all new development from LV8 to LV2012, we started using 'Projects' and naturally put each project in its own folder in user.lib. Obviously compiled dlls and exe would eventually be deployed to new locations when everything worked, but what is so strange about working in user.lib and accepting all the defaults in building an executable?

[RavensFan]

---

@Saranac wrote:

And when did user.lib stop being the folder where users put their vi's? Perhaps I'm misunderstanding your points.

I work with a team of people. We've always kept our VI's in folders in user.lib where eveybody would have access to them. When we recently decided to move all new development from LV8 to LV2012, we started using 'Projects' and naturally put each project in its own folder in user.lib. Obviously compiled dlls and exe would eventually be deployed to new locations when everything worked, but what is so strange about working in user.lib and accepting all the defaults in building an executable?

---

User.lib has never been meant to be a working directory for user projects.  It is there for user's to put templates or subVI's intended for reuse.  Also, a location for 3rd party libraries.  It is the location for files that you want to be a part of LabVIEW, but weren't installed with LabVIEW.

For your working documents (VI's, projects, libraries) they never should be a part of the Program Files folder.  Depending in your user access rights, your IT department may not even let you save files to that directory path.  Documents are meant to be a part of the Documents file structure.  If you need to share it so that multiple users can work on it, it belongs in the All Users directory of the Documents folder as opposed to the My Documents folder of any specific user.  Note that Microsoft has changed the names of these paths over the years.  Documents and Settings has become Users. 

[Saranac]

In a closed IT environment, one would never be allowed access to All Users as you can screw with other peoples accounts. The Public folder could work, but there are a bunch of Group Policies set that screw with ownership. Getting Full Access to the Labview Programs directory was the easiest solution and had the added benifit of having full access to the Labview Programs directory. A top level directory could work, training people to not work in their own desktop environment and then drag&drop (permision and encryption problems) was the hard part.

Back to the main observation, if the application is built to a folder outside of the user.lib folder, there must be something different in the internal file structure of the exe? Perhaps <userlib> is fully spelled out? The problem only occured when including DAQmx vi's that had dependencies to other llbs in the the DAQmx vi.lib folder.