[VeriStand] Allow INI-based Paths for Plugins and Dependencies

[Pie566943.0]

VeriStand looks in specific directories for plugins.  This makes source code control and configuration management difficult for our ADG customers.  If Veristand.ini allowed customers to provide paths (plural) to VeriStand plugins, then the plugin destination directory could be under SCC/CM and isolated from COTS plugins.  For example:

AdditionalCustomDevicePaths = "C:\Projects\Resolver;C:\Projects\Valve"

AdditionalFPGAPaths = "C:\Projects\EMF"

AdditionalToolsPaths = "C:\Projects\RTSA"

etc.

[iwane]

Shame that I have only one kudo to give for this...

I hate the workaround of separate scripts that copy proper files to proper places before actually starting Veristand.

[Mathieu_R.]

@Piotr : if it makes you feel better, I did not find anything better thant scripts to copy project requiered components to VeriStand Public directory.

TestStand uses a mechanism of Search Directories, which is a global configuration to indicates TestStand where it is allowed to find file ressources (these settings can be modified programmatically, using the TestStand API).

A mecanism of the same kind could allow to define complementary compoents locations on the disk (Custom Devices / FPGA / Models). In particular in SCC controlled folders. You can imaging having a filter by type of component (in this folder, I'm expecting to find Custom Devices for instance).

Best regards,

[iwane]

@Matthieu_R: That's what we do too... 

Search Directories would also be fine. Also, it would probably enable the setting to be changed on the fly. Now you can't just swap versions of the Custom Device if their configuration pages or XMLs differ... I'd love being able to force Veristand to reload Custom Devices without closing and reopening the application.

[TeeW]

Another idea related to this one- allow VeriStand to use relative paths for Custom Devices. This can already be done for FPGA bitfiles if you copy the 'NI VeriStand FPGA DMA' .xsd and .xsl files to the directory that has the bitfile & .fpgaconfig in it. If this kind of relative pathing was extended to Custom Devices it would make distributing full system definitions with their dependencies so much easier.