Fix path resolution for relative SARIF artifact locations relative to %SRCROOT% #615
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Issue
This change addresses an issue found when trying to manually open a SARIF log containing a relative URI for
artifactLocation
such as:in which the SARIF log was not successfully processed with the following error:
The issue was caused by the path resolution mechanism returning a relative path as the "resolved path" which caused an exception to be thrown when trying to convert that relative resolved path to an absolute Uri (
System.UriFormatException
- Invalid URI: The format of the URI could not be determined).To dive deeper, the reason the relative path was returned was because
_fileSystem.FileExists
was utilized to verify the resolved path existed on the file system. For more context,_fileSystem.FileExists
is simply a wrapper aroundFile.Exists
. IfFile.Exists
is passed a relative path, which is possible in this scenario, it is interpreted as relative to the current working directory and passes the check. As a result, the relative path is assigned as the "resolved path" where as we expect resolved path to be a full path. This relative resolved path then causes issues later in the flow.Fix
The fix modifies
src/Sarif.Viewer.VisualStudio.Core/CodeAnalysisResultManager.cs
to return a fully resolved and normalized path by verifying that the path is rooted. If it is rooted, great, simply return it. If not, make sure to combine (Path.Combine
) the relative path with the base path before returning.The
GetCommonSuffix
utility, which is used later in the path resolution flow, was also modified to normalize both paths before doing a comparison. Although this might cause redundancy if a path is already normalized, it removes the responsibility from the caller to handle path normalization.