Analyzer Config File

[JoeWork]

If you do it this way it appears that you lose the "Analyze the current project" ability.  But I just now discovered you can add folders when making the selections.  I assume that is good enough.

The different developers can create their own individualized CFG files to run their own tests.  But the intent was to be able to run a larger test based on the settings and tests need to adhere to our company LabVIEW design standards.  I definitely don't want anyone changing the test selections or their settings before running this.

[Darren]

If you're concerned about developers changing the settings, maybe you should consider using the VI Analyzer API to run programmatic analyses of the projects as part of a build process, as opposed to having the developers do it? That way since you're the one controlling the build process, you are programmatically configuring specific tests to run on the code, and developers can't change the settings since it's being done programmatically by the build process instead of interactively by them.

[warren_scott]

We've had good success with kinda a mix of all the above:

We created a standardized template VIAnalyzer cfg file.  It contains all the "company standard default" tests/configurations with NO files added.

We then created some LV Tools menu items that automate VI Analyzer.  Basically, to analyze stuff, we have users go to Tools >> COMPANY_NAME >> VI Analyzer menu (that we added).  you can then add entrypoints for "Analyze current VI", "Analyze all VIs in memory", "Analyze current project", "Analyze all files in directory", or any other thing you can figure out. Each of these then gets the list of VIs desired, then launches VI Analyzer, loads the default cfg file, and adds the files desired, and runs.

The only drawback we have come acrss here is managing an early termination of our analysis.