Observed
A user upgrading PostSharp Threading from 2025.1.6 to 2026.0.12 (Visual Studio 2022, .NET 8, .NET SDK 8.0.313 on CI) gets a compiler warning on every build:
...\DependencyRestore\8.0.313\net8.0-windows10.0.26100-sdk8.0.313-win-x64--ps2026.0.12.0-ee5c0b5.deps.proj : warning NU1901: Package 'NuGet.Packaging' 6.14.0 has a known low severity vulnerability
Root cause
PostSharp's .NET Core compiler host populates a fallback package directory by generating a synthetic <id>.deps.proj and running dotnet restore on it (BuildTimeDependencyRestorer.CreateDependencyRestoreProject, Core/PostSharp.MSBuild/NetCore/BuildTimeDependencyRestorer.cs). That project lists the compiler's own dependencies, including NuGet.Packaging 6.14.0 (referenced by PostSharp.Compiler.Engine).
On .NET SDK 8.0.3xx and later, NuGet auditing is on by default, so the restore emits NU1901 for that package. The restore runs inside the PostSharpCompile MSBuild task; its stdout is piped through ToolInvocationHelper → Log.LogMessageFromText, which recognizes the canonical file : warning CODE: text line and re-raises it as a real warning (code NU1901) in the user's build. Hence it surfaces as a "Compiler Warning."
Why this deserves fixing
- The user cannot act on it — the compiler's dependency versions are fixed by the PostSharp version.
- It is noise in every user build on a current SDK, and projects that treat warnings as errors fail.
Remediation
- Bump
NuGet.Packaging past the advisory and re-audit the full compiler dependency closure (note NuGet.Frameworks / NuGet.Versioning move in lockstep; keep net8.0 compiler-host compatibility).
- Enforce auditing in PostSharp's own build — turn on
NuGetAudit (warning or error) for the Engine project, similar to the existing <NuGetAuditLevel>low</NuGetAuditLevel> on Core/PostSharp.Compiler.Platform.NetCore/PostSharp.Compiler.Platform.NetCore.csproj. New advisories then surface in PostSharp CI and get fixed in a point release, instead of first appearing in customer builds.
We intentionally do not hard-disable NuGet auditing in the generated restore project: that would permanently silence every severity (including a future NU1903/NU1904) for every user, hiding a signal they may want even when they can't fix it themselves. The scoped, opt-in alternative is tracked separately in #40.
Workaround for affected users on an older PostSharp + newer SDK
- Targeted:
<MSBuildWarningsAsMessages>$(MSBuildWarningsAsMessages);NU1901</MSBuildWarningsAsMessages> in Directory.Build.props. Demotes the warning where it is actually re-raised (the main build), only for NU1901.
- Location-independent: set a
NuGetAudit=false environment variable on the build agent. MSBuild reads env vars as global properties and the parent environment flows into the child dotnet restore, so it reaches the generated .deps.proj without needing a file in the temp directory — but it is build-wide (also silences audit of the user's own packages).
🤖 Generated with Claude Code
Observed
A user upgrading PostSharp Threading from 2025.1.6 to 2026.0.12 (Visual Studio 2022, .NET 8, .NET SDK 8.0.313 on CI) gets a compiler warning on every build:
Root cause
PostSharp's .NET Core compiler host populates a fallback package directory by generating a synthetic
<id>.deps.projand runningdotnet restoreon it (BuildTimeDependencyRestorer.CreateDependencyRestoreProject,Core/PostSharp.MSBuild/NetCore/BuildTimeDependencyRestorer.cs). That project lists the compiler's own dependencies, includingNuGet.Packaging 6.14.0(referenced byPostSharp.Compiler.Engine).On .NET SDK 8.0.3xx and later, NuGet auditing is on by default, so the restore emits
NU1901for that package. The restore runs inside thePostSharpCompileMSBuild task; its stdout is piped throughToolInvocationHelper→Log.LogMessageFromText, which recognizes the canonicalfile : warning CODE: textline and re-raises it as a real warning (codeNU1901) in the user's build. Hence it surfaces as a "Compiler Warning."Why this deserves fixing
Remediation
NuGet.Packagingpast the advisory and re-audit the full compiler dependency closure (noteNuGet.Frameworks/NuGet.Versioningmove in lockstep; keepnet8.0compiler-host compatibility).NuGetAudit(warning or error) for the Engine project, similar to the existing<NuGetAuditLevel>low</NuGetAuditLevel>onCore/PostSharp.Compiler.Platform.NetCore/PostSharp.Compiler.Platform.NetCore.csproj. New advisories then surface in PostSharp CI and get fixed in a point release, instead of first appearing in customer builds.We intentionally do not hard-disable NuGet auditing in the generated restore project: that would permanently silence every severity (including a future
NU1903/NU1904) for every user, hiding a signal they may want even when they can't fix it themselves. The scoped, opt-in alternative is tracked separately in #40.Workaround for affected users on an older PostSharp + newer SDK
<MSBuildWarningsAsMessages>$(MSBuildWarningsAsMessages);NU1901</MSBuildWarningsAsMessages>inDirectory.Build.props. Demotes the warning where it is actually re-raised (the main build), only forNU1901.NuGetAudit=falseenvironment variable on the build agent. MSBuild reads env vars as global properties and the parent environment flows into the childdotnet restore, so it reaches the generated.deps.projwithout needing a file in the temp directory — but it is build-wide (also silences audit of the user's own packages).🤖 Generated with Claude Code