I’ve thought about this issue a bit. We should be thinking about an analysis that provides a hit in any generated file that isn’t under source control. For example, a generated XAML code-behind file. The corner case covers something even
more problematic, a single analysis run where generated files are, for example, overwritten on a per-project basis (to a common location in some build intermediates folder). To answer your questions:
This isn’t tool specific, it relates to scan targets which are themselves generated content not under source control (and which are fluid/overwritten even while some larger build analysis
is taking place)
The file is a valid scan target, whatever that means. A PCH file or other intermediate. A header file that is generated by some perl script. Etc.
Producers SHOULD persist all files to run.files that aren’t managed by a version control system. This is just good general guidance.
It may be necessary to represent multiple versions of this re-written file in the run.files dictionary, if multiple results instances exist that point to different versions of the
generated content.
Ditto, a viewer will need to access any version of the file referenced by any result.
From: Larry Golding (Comcast) <>
Sent: Friday, April 6, 2018 2:31 PM
To: Michael Fanning <>; 'James A. Kupsch' <>;
Subject: Please comment on #125
#125:
Address corner case for generated files in run.files dictionary
This is the scenario where the same physical file is re-written in the course of an analysis. Please see my comments in the issue. What is the scenario here? – that is:
What tool is involved?
What is the nature of the file that’s being re-written?
Is it necessary to represent this file in the run.files dictionary?
Is it necessary to represent
multiple versions of this re-written file in the run.files dictionary?
Would a viewer need access to
any version of this file except the last one written?
Thanks,
Larr
