You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Roslyn compiler emits SARIF v1.0 with tool.fileVersion = "3.100.19.26603 (9d80dea7)". The multitool transform command blithely copies it to tool.driver.dottedQuadFileVersion -- but the new name makes clear that this is wrong.
What should the transformer do when fileVersion doesn't match the expected format of dottedQuadFileVersion?
Well, if fileVersion does contain a substring of the form n.n.n.n, we should probably populate dottedQuadFileVersion with that. But what should we do with the rest?
The text was updated successfully, but these errors were encountered:
The SARIF v1 spec does not specify a format for tool.fileVersion (although on the Windows platform, the spec anticipated that it would be of the form n.n.n.n where each n is one or more decimal digits).
The SARIF v2 spec is more prescriptive: it defines a property toolComponent.dottedQuadFileVersion with exactly that format. So if the v1 file contained a tool.fileVersion in any other format, the best we can do is put it in the property bag.
The Roslyn compiler emits SARIF v1.0 with
tool.fileVersion
="3.100.19.26603 (9d80dea7)"
. The multitool transform command blithely copies it totool.driver.dottedQuadFileVersion
-- but the new name makes clear that this is wrong.What should the transformer do when
fileVersion
doesn't match the expected format ofdottedQuadFileVersion
?Well, if
fileVersion
does contain a substring of the form n.n.n.n, we should probably populatedottedQuadFileVersion
with that. But what should we do with the rest?The text was updated successfully, but these errors were encountered: