Description
Warnings emitted for file accesses matching AllowFileAccessAfterProjectFinishFilePatterns do not have an MSBuild warning code. This prevents consumers from selectively keeping these diagnostics as warnings when the rest of a build uses /warnaserror.
FileAccessRepository currently reports the match through ILogger.LogWarning(...) with a message such as:
File access reported from process after the project finished, but file path matched AllowFileAccessAfterProjectFinishFilePatterns ... This may lead to incorrect caching.
Because the warning is uncoded, /warnasmessage:<code> and /warnnotaserror:<code> cannot target it. The only supported consumer-side option is to disable warning escalation for the entire cache-enabled build.
Reproduction
- Configure
MSBuildCacheAllowFileAccessAfterProjectFinishFilePatterns to allow a known late access.
- Run a cache-enabled graph build with
/warnaserror.
- Observe that the allowlisted diagnostic is rendered as
MSBUILD : error : even though the access matched the configured allowlist.
This occurred in microsoft/testfx after #10090 using Microsoft.MSBuildCache.AzurePipelines 0.1.328-preview. Azure build 1519505 observed late Application Insights reads of INetCache\...\dyntelconfig[1].cache, matching the configured **\AppData\Local\Microsoft\Windows\INetCache\** pattern.
Expected behavior
Consumers should be able to retain /warnaserror globally while selectively leaving this diagnostic as a warning.
A stable MSBuild warning code would enable /warnasmessage:<code> or /warnnotaserror:<code>. Alternatively, a supported setting for the severity of matched allowlist diagnostics would address the same problem.
The request is not to hide the diagnostic by default; it remains useful because allowlisted late accesses are excluded from caching and may indicate a correctness risk.
Description
Warnings emitted for file accesses matching
AllowFileAccessAfterProjectFinishFilePatternsdo not have an MSBuild warning code. This prevents consumers from selectively keeping these diagnostics as warnings when the rest of a build uses/warnaserror.FileAccessRepositorycurrently reports the match throughILogger.LogWarning(...)with a message such as:Because the warning is uncoded,
/warnasmessage:<code>and/warnnotaserror:<code>cannot target it. The only supported consumer-side option is to disable warning escalation for the entire cache-enabled build.Reproduction
MSBuildCacheAllowFileAccessAfterProjectFinishFilePatternsto allow a known late access./warnaserror.MSBUILD : error :even though the access matched the configured allowlist.This occurred in microsoft/testfx after #10090 using
Microsoft.MSBuildCache.AzurePipelines0.1.328-preview. Azure build 1519505 observed late Application Insights reads ofINetCache\...\dyntelconfig[1].cache, matching the configured**\AppData\Local\Microsoft\Windows\INetCache\**pattern.Expected behavior
Consumers should be able to retain
/warnaserrorglobally while selectively leaving this diagnostic as a warning.A stable MSBuild warning code would enable
/warnasmessage:<code>or/warnnotaserror:<code>. Alternatively, a supported setting for the severity of matched allowlist diagnostics would address the same problem.The request is not to hide the diagnostic by default; it remains useful because allowlisted late accesses are excluded from caching and may indicate a correctness risk.