Summary
The SDK's own jschema libraries Microsoft.Json.Pointer / Microsoft.Json.Schema / Microsoft.Json.Schema.Validation were held at 2.1.0 in #3120 (v5.5.0) because 2.3.0 tightens format: uri enforcement and surfaced a latent gap. This issue tracks taking 2.3.0 and closing the gap.
Root cause
Several SARIF Uri object-model properties lack a [JsonConverter(typeof(UriConverter))] attribute, notably:
ToolComponent.DownloadUri / ToolComponent.InformationUri
TranslationMetadata.DownloadUri / TranslationMetadata.InformationUri
UriConverter percent-encodes file-scheme paths (e.g. serializes new Uri(@"c:\path with a space\file.txt") as file:///c:/path%20with%20a%20space/file.txt). Properties that carry the attribute (ArtifactLocation.Uri, ReportingDescriptor.HelpUri, SarifLog.SchemaUri, Result's, VersionControlDetails) encode correctly; the un-attributed ones serialize the raw OriginalString — an invalid RFC 3986 URI.
Both SarifLog.Save (bare new JsonSerializer()) and the ValidatesUriConversion functional test (plain JsonConvert.SerializeObject) rely purely on these per-property attributes, so the gap is real, not test-only — it just only manifests for file-path URIs in those properties (normal https:// URIs serialize fine either way). Microsoft.Json.Schema.Validation 2.1.0 did not enforce format: uri and let it slip; 2.3.0 correctly flags it (JSON1024).
Proposed fix
- Add
[JsonConverter(typeof(UriConverter))] to every Uri object-model property that lacks it (and update the code generator so autogenerated files stay in sync).
- Bump
Microsoft.Json.Pointer / Microsoft.Json.Schema / Microsoft.Json.Schema.Validation 2.1.0 → 2.3.0.
- Confirm
SarifValidatorTests.ValidatesUriConversion passes under the stricter validator; consider having the test serialize via the SDK's real serialization path so it exercises production behavior.
Context
Deferred from #3120 to keep that dependency PR focused. The stricter 2.3.0 validation is a genuine improvement and aligns with the goal that emitted SARIF be error- and warning-free.
Summary
The SDK's own jschema libraries
Microsoft.Json.Pointer/Microsoft.Json.Schema/Microsoft.Json.Schema.Validationwere held at 2.1.0 in #3120 (v5.5.0) because 2.3.0 tightensformat: urienforcement and surfaced a latent gap. This issue tracks taking 2.3.0 and closing the gap.Root cause
Several SARIF
Uriobject-model properties lack a[JsonConverter(typeof(UriConverter))]attribute, notably:ToolComponent.DownloadUri/ToolComponent.InformationUriTranslationMetadata.DownloadUri/TranslationMetadata.InformationUriUriConverterpercent-encodes file-scheme paths (e.g. serializesnew Uri(@"c:\path with a space\file.txt")asfile:///c:/path%20with%20a%20space/file.txt). Properties that carry the attribute (ArtifactLocation.Uri,ReportingDescriptor.HelpUri,SarifLog.SchemaUri,Result's,VersionControlDetails) encode correctly; the un-attributed ones serialize the rawOriginalString— an invalid RFC 3986 URI.Both
SarifLog.Save(barenew JsonSerializer()) and theValidatesUriConversionfunctional test (plainJsonConvert.SerializeObject) rely purely on these per-property attributes, so the gap is real, not test-only — it just only manifests for file-path URIs in those properties (normalhttps://URIs serialize fine either way).Microsoft.Json.Schema.Validation2.1.0 did not enforceformat: uriand let it slip; 2.3.0 correctly flags it (JSON1024).Proposed fix
[JsonConverter(typeof(UriConverter))]to everyUriobject-model property that lacks it (and update the code generator so autogenerated files stay in sync).Microsoft.Json.Pointer/Microsoft.Json.Schema/Microsoft.Json.Schema.Validation2.1.0 → 2.3.0.SarifValidatorTests.ValidatesUriConversionpasses under the stricter validator; consider having the test serialize via the SDK's real serialization path so it exercises production behavior.Context
Deferred from #3120 to keep that dependency PR focused. The stricter 2.3.0 validation is a genuine improvement and aligns with the goal that emitted SARIF be error- and warning-free.