When loading a project where a lot of reference have been moved, there should be a "use this folder location" option

[Matt_AM]

I got some code from a coworker that I'm building into an EXE.  There are a lot of references to user.lib (like 60 classes) and the folder structure that my coworker gave me makes some of the classes in user.lib too long and causes the exe to fail building.

I moved the stuff from user.lib to a root folder on my C drive and now I have to manually update every class because they aren't in user.lib.  Its pretty time consuming and I think just saying "Look in this directory for the missing files" would help tremendously for larger projects that need to get moved around.

[wiebe@CARYA]

Like a... search path?

Can't say I ever used it in 25 years, but it feels like it might just do the trick.

[fefepeto_kb]

Maybe getting the project as a source distribution from your colleague?

I know it sounds cumbersome, but that was created for scenarios like this. If the developers are not using source code control, or not using/not having access to the same repos the source distribution can help outputting the main project (preserve folder structure) as is and moving the dependencies nearby.

[Matt_AM]

Adding in the path makes sense, but you don't know if there are 1 or 100 references that need to be updated until you start going down that rabbit hole.  Why not make a more convenient UI and allow the user to add to the search path when searching for said references?  The button could add the desired folder location to the search path as a temporary thing.  

The code that spawned this suggestion was given to me by a third party company so I don't have access to their repos.  I was given the source code with their user.lib files.  When building an EXE, the path was too long for some user.lib vis which caused the exe build to fail.  So I moved said files to root C and had this issue of relinking a ton of references.  Ended up having to do it in a secondary project folder because doing it in the main project folder would cause LV to crash (my assumption was a mix between a ton of references that needed to be updated and the file path was too long for some VIs).

[fefepeto_kb]

Ok, I think we have a misunderstanding.

You can ask the partner company to have a source distribution created. The source distribution can have a flat folder structure including all the VIs required for their code to work. They also have the option to exclude VIs from the vi.lib. This should help with your problem, because the paths will become shorter. Creating a source distribution also relinks the files with the new paths.

I don't think that even a temporary search path would be a solution. A potential corner case is when you open another project, and then the new project also tries to load files from the temporary search path too. Finding files with the same name would cause conflicts.

[Matt_AM]

Should people be using source control for code?  Yes.  However, I believe that LV should have the tools to make life easier for those not using add ons since LV is more of an engineering language vs programming language.  By this I mean that you don't really need to know proper SW ENG or LV practices (although they should be followed) to get code up and running.  

My suggestion is gear towards the people who don't know the proper way to transfer source code since there isn't really a great tutorial for transferring source code to a new dev machine.  Or for people (like my situation) who had to move a bunch of classes from user.lib to a new location and didn't know the proper procedure, because, again, there isn't a ton of great tutorials walking people through the process.  I'd wager there's a large chunk of users who'd do what I did and physically move the classes to a new folder location and deal with relinking when opening the project again.

[fefepeto_kb]

Ok, I get your point, just as I got it from your post, but I also think that beyond sharing ideas we are also here to learn.

In that spirit, at least in my humble opinion, learning to share code within developers or companies is beneficial for both parties involved.

And, after a quick search I found a way to share the code, with tutorial: Sharing Code With the LabVIEW Project Library - NI.

Is it too complicated? I agree.

Then there is another option: Creating a VI Source Distribution - NI. Although it is not commonly advertised nowadays, since the library based approaches took over, it is there. Also, I have to admit that I have done the Core courses a long ago, but I have a vague memory of a lesson taking through the different build options were the Source Distribution has its own section.

Not saying that the search dialog could not be improved, but I think that there are viable options for solving this issue.

>> By this I mean that you don't really need to know proper SW ENG or LV practices (although they should be followed) to get code up and running.

In my opinion if somebody is using classes, they should already be aware of some programming best practices and the LabVIEW environment. For small prototyping code it is OK to just throw things together quickly, but I doubt that it would lead to very long path issues.

[Matt_AM]

Thank you for the links!  That will make life easier for us in the future.  

In the spirit of learning, I 100% understand where youre coming from and agree that we should be encouraging proper SW practices in general.  I know I've evolved a lot as a dev from when I originally started LV (polling bools, build bool array, convert to I32, choose case based on I32 val) to where I am at now (UI Loop).  Using git was a good step so we didn't have to keep full build backups if we wanted to go "back in time" and could more easily share repos for projects.  Side note, if there is a good tutorial about how you should keep your repos organized, I'd be interested in learning.  I currently have 1 repo per class and although that allows me to keep finer granularity of changes, its a bit of a pain to constantly pull all the repos for a project :/.