Suppose you open a VI, any VI. When LabVIEW opens it, it tries to find "all of the pieces" that it needs. Suppose you are not in a Project, you have no Project open, and this is the first VI you've opened, so it is the only VI in memory.
Bottom line -- you shouldn't need to specify anything in vi.lib. If they appear in a Product dependency, then something in your Project refers to an NI toolkit/module/driver (or User Library!) that isn't installed.
P.S. -- I went looking for NI_AALBase.lvlib, which is where you seem to be missing many functions. I have such a folder on my system, and it has the functions that are in your Dependencies. Which leads me to ask, are you running LabVIEW Student Edition, or LabVIEW Base Edition? This might require a higher-level license, as it clearly needs functionality that I've been using (with my higher-level license) for years without problems, so I may have missed this possibility ... [Sorry].
I am finding out today that the licensing is in fact, one of the problems. The original development machine is 2018 and they moved this messy project to another machine running 2020. And this computer does not have some of the licenses. I've been making small changes to the project on my 2020 machine and then saving to previous version (2018) and then opening up the project from the network drive on the 2018 machine. Only my second day here but I've made progress. I'll talk to them about getting my 2020 machine with the proper licenses. Thank you for all of your help.
Close those branches of the tree that say NI_AALBase.lvlib aan NI_AALPro.lvlib They are part of the LabVIEW install. They do not need to be moved, nor should they be moved. If they are missing, then it is certainly a sign that the wrong version of LabVIEW was licensed. If you have the license for the Pro version of LabVIEW and activate that, you shouldn't have any problems with those dependencies being missing.
So once you close those huge branches of the tree, you should be left with a lot fewer files. You should close the vi.lib branch since that is also installed with LabVIEW.
Instr.lib is a folder that holds various instrument driver libraries, if you have any missing dependencies there, then you need to find the appropriate instrument drivers and install them into LabVIEW. You can *probably* copy and paste folders of those from other PC's that have them in LabVIEW. But I try to avoid that since usually the install process doesn't just put the files there, it will manipulate the LabVIEW palettes as well.
As you start finding things and closing down branches of the tree, any missing dependencies would be from files you didn't copy over. Usually you can tell by the name which ones were homemade by another programmer, and which are more professionally done files and libraries. Often if they are missed, it is because they got pulled from a folder that was for another project and weren't in the folder hierarchy of the project you are working on. That is why the tips above always suggest storing the files in folders and subfolders of your single project. By looking at the explorer view of the project, it becomes obvious which files come from elsewhere and might be the result of cross-linking to other projects.
Well, this is such an interesting topic, that I am going to chime in again with some advanced advice.
First, s little curriculum vitae for those of you that don't know me well. I built a career out of LabVIEW Consulting on 3 to 12 month contracts. I only accepted positions with specific project scope (except for a few unmentionable mistakes.) I've been everything from "lone wolf" to lead Architect of programs that involved multiple developers in multiple cities in a dozen countries on 3 continents with uncounted installed solutions. I am an expert!
For the Lone Wolf work YOU can get away with the copy - paste - patch approach. Keep in mind that the next developer that has to look at your delivered solution will curse you and all Generations leading to the misfortune of your birth. This is not the best method.
Better, use SCC for your project. This comes with some challenges because a lvproj contains absolute paths to items in the project, "semi-symbolic" paths to dependencies. <vi.lib, user.lib, instr.lib, etc> and limited information about the targeted development Environment.
Addressing the Dev Environment (DE)! Things like; LabVIEW version, frameworks, modules, toolkits, drivers (instr.lib and *.inf files for computer peripherals) etc... A simple ReadMe.txt file in your lvproj listing these and where to locate your working copy is a good idea.
Moron the need to locate your working copy in the same location on each DE! Next post. Pun intended.
Where to install software is as important as what software is installed! Or, somethings belong where they belong!
The DE expects some things in specific locations. Examples:<application Data>/LabVIEW/
All other default search paths are fairly well documented. DON'T change the default search paths settings. They are in LabVIEW.ini so, that changes 1 LabVIEW version on 1 machine. I had a contract where the lead said to me "Oh, yeah you have to add xyz location to your search paths" Why? "Because we did that before we knew better and regret it."
Instrument drivers from NI ID Network are mostly project based or IVI COM dll based. IVI install fine. Project Style pop need to be unzipped to <Instr.lib>
The main thing to understand about your.lvproj is: they contain absolute paths. Just open one in any text editor and you will see. So, when you open a project file the first thing you will notice that happens is that the DE locates all project item and dependencies. It parses the XML string in the lvproj file and hopefully everything is right where it says it is. If something is not where the project last saw it, LabVIEW goes looking for it. LabVIEW has a list of locations where it searches. If it finds the item great! Right? Not so fast my young padawan! That might be just peachy for you in your DE, but the contents of the XML string in the lvproj have changed! No other DE knows about that change and when you push/commit to SCC everyone else will hate you.
That is also why everyone should have their working copy at the same location. AND why that ReadMe.txt is so important. It really doesn't matter where you choose to put you projects but you need to write it down where other developers can find it. Text files work well. BEST practice is to carve it in STONE! (That heavy object is handy for smacking the developer that didn't read it upside the head!)
Professional tip. VIPM can be used to install all Toolkits, drivers, addons, and even some bat files for seriously low level stuff like adjustments to the power manager power profile to stop shutting down USB power. This is LEGENDARY stuff when you have multiple teams that each work on several projects in VMs that allow multiple DEs per developer.