Where to put my *.lvproj file on disk?

[msad66]

Hi,

I'm starting a large project and wanted to organize it properly.

I read the following link and want to organize my files like Figure 1.

http://www.ni.com/white-paper/7197/en/

The question is where to put my *.lvproj file?

Should I create a folder titled “Project” and save *.lvproj file?

Should I save *.lvproj file in the main root?

What about shared variable libraries?

Regards.

[TiTou · Accepted solution]

It's up to you really... I prefer to have my project file at the root but anyway the links in the lvproj to all you projects items are relative - appart maybe for the build destination path.

For your shared variables libs then it depends how you architecture your project, but a specific folder not to far down from the root seems reasonnable.

[Norbert_B]

My recommendation is that the lvproj should be placed in a location relativ to other sources where the final EXE should be placed later on.

So if you create an EXE but require external files (lvlibp, txt, cfg, ini, ...) and place it on the same place as the lvproj (in the release folder) you can work with the same approach regarding "path-resolution".

Hint: Always use "Application Directory" for starting to build relative paths in your application!

Also please note that it is best practise to add ALL required files to your LV project which are used in the application but not part of vi.lib, instr.lib and user.lib.

Norbert

[msad66]

Norbert_B,

I couldn’t see your point.

Do you suggest to save *.lvproj file in to “..\builds\Application\Software.exe” and create similar folder structure as your project for your executable?

Could you give me an example folder structure?

[Norbert_B · Accepted solution]

No, that's not what i said.

Imagine your application provides a help button (or menu item). Pressing that button loads and displayes a help file (e.g. html). This file cannot be compiled in the EXE, so it is an external source.

For loading the external source, you require the path. It is best practise to use relative paths.

Therefore, you have to build a relative path which ideally does NOT differ between "use case developer sources" and "use case EXE".

Please review the LV help to "Application Directory" to understand why i recommend that the lvproj shall "represent" the EXE location during development.

Note that above mentioned help file should be part of a deployment configuration you create using the LV AppBuilder. So for the EXE, you will have a copy of that file in a specific folder which is used for the EXE only.

Norbert

[msad66]

Thanks Norbert,

That is a great idea.

I have this problem in my previous projects.

The thing I did in my previous projects is similar to the following link:

https://decibel.ni.com/content/docs/DOC-4212

It is a bit complicated.

What I am going to do is to place my project in the main root, as TiTou said, and create a “data” folder for all supplementary files just like “Support Directory” in the “Build Specification”.

[RavensFan]

I do not recommend putting the .lvproj file in the root c:\ drive.  First of all, it is never just that file, it quite a few files that get created along side of it.

  There is an .aliases, .lvlps, perhaps and .ini going along with it.

You may have multiple versions of your project where you backup one before going off and making major changes (assuming you aren't using a formal source control system.)  You don't want multiple versions of your project to get intertwiend.

Of course you may have multiple different projects going on at once.

Also, c:\ is often very heavily protected by the OS in most recent version of windows.  It can often be hard to manipulate files and copy files into c:\root without constantly telling Windows it has your permission to to that.

I also believe the c:\ root drive should be relatively clean an not cluttered with a lot of files.

I create a project folder in c:\ root.  Inside of that I have the .lvproj, it associated files, and the top level VI or two.  All subVI's and other libraries I put in a few different subdirectories below that.

Now when I want to backup my project, I can just zip up the single folder.  Or copy it off elsewhere.  I don't need to find a half dozen files and a folder to do that.

I probably should not have my project folder in c:\, but I do that because I often seen messages in the forums where people have build problems becaused there file paths get too long, and there is nothing shorter than starting off c:\.

Project folders probably belong in your "My Documents" directory.  I know our IT recommends that because if they backup the PC, they just back up the user directory, and maybe a couple others.  They aren't in the habit of looking in the root drive for "user" files.  (Of course I never let them handle my PC, and I make sure I back up my own drive.)  Of course My Documents leads to long paths because it is c:\users\your name\Documents\  before you get to any files or folder, so you may have already added another 20-30 extra characters.

So I recommend a single folder per project in your root directory.  All files related to that project belong under that directory.  And you should try to maintain a hierarchy of files in that directory that more or less follows your hierarchy withing the project itself.

[Norbert_B]

---

@RavensFan wrote:

I do not recommend putting the .lvproj file in the root c:\ drive.[...]

---

I think he referred to the "project root directory". Not the term "root directory" all computer scientists understand in context of an OS.... 😉

But thanks for highlighting that possible pitfall.

Norbert

[msad66]

Sorry. I meant “project root directory”.

But thanks for the tips.

[Gregory]

I have a LabVIEW Projects folder under which I have different LabVIEW versions, 2013, 2014, 2015, etc. Then under the LabVIEW version I create the folder with the name of the project.

Note: if you are using source code control this would be a good time to create the trunk, branches, and tags folders as well.

You now have a folder something like: LabVIEW Projects/2015/My Application, in which you can save My Application.lvproj. You can then save your top level VI as My Application.vi.

I think the autopopulating folders work fine if you just have a couple folders, like SubVIs and Controls. Once you start making applications with a couple of functional globals and parallel processes, etc. it is nice to have these in their own library and organize them in the Project viewer using virtual folders. So you might save a functional global as My FGV.lvlib in a folder LabVIEW Projects/2015/My Application/Functional Globals/My FGV. This allows you to have VIs with the same name (Like init.vi) while not conflicting in the LabVIEW project (because they are in different libraries) or in the windows file system (because they are in different folders).

In the end, I think everyone finds their slightly different preferences, but you might find these as good starting points.