Directory.Build.targets

<Project>

  <!-- IsTool controls shared tool publish behavior. The SDK derives the two
       specific documentation properties before this file is imported, so set
       all three here. A tool then participates in solution publish and carries
       neither its own API documentation nor documentation from a referenced
       library, while libraries remain non-publishable and continue generating
       XML documentation in their own outputs. Packaging properties stay
       explicit in each tool project because the SDK consumes PackAsTool before
       this file is imported. -->
  <PropertyGroup Condition="'$(IsTool)' == 'true'">
    <IsPublishable>true</IsPublishable>
    <PublishDocumentationFiles>false</PublishDocumentationFiles>
    <PublishDocumentationFile>false</PublishDocumentationFile>
    <PublishReferencesDocumentationFiles>false</PublishReferencesDocumentationFiles>
  </PropertyGroup>

  <!-- Runtime async is enabled by default only for NativeAOT. Ordinary non-AOT
       builds use the compiler default, which emits classic async state machines.
       The CoreCLR Browser comparison workflow opts in explicitly for that one
       published application graph. -->
  <PropertyGroup Condition="'$(TargetFramework)' == 'net11.0' and '$(PublishAot)' == 'true'">
    <Features>$(Features);runtime-async=on</Features>
  </PropertyGroup>

  <!-- Runtime flavor is a property of the published executable, not of dynamic
       code availability or its managed build input. NativeAOT consumes runtime
       host options during IL compilation, including when publish skips the
       managed build. Ordinary and RID-specific managed builds remain CoreCLR. -->
  <Target Name="DefineDotnetInspectNativeAotRuntimeFlavor"
          BeforeTargets="_PrepareTrimConfiguration;WriteIlcRspFileForCompilation"
          Condition="'$(DotnetInspectRuntimeFlavor)' == 'true' and '$(PublishAot)' == 'true'">
    <ItemGroup>
      <RuntimeHostConfigurationOption
          Include="DotnetInspect.RuntimeFlavor.NativeAOT"
          Value="true"
          Trim="true" />
    </ItemGroup>
  </Target>

  <!-- Updated memory-safety rules are a compiler feature and a decompiler
       fixture axis. Keep the repo default as whatever the project requested
       (property unset/legacy), and let fixture overlays opt in with
       <MemorySafetyRules>updated</MemorySafetyRules> (or "on"/"new"). -->
  <PropertyGroup Condition="'$(MemorySafetyRules)' == 'updated' or '$(MemorySafetyRules)' == 'on' or '$(MemorySafetyRules)' == 'new'">
    <Features>$(Features);updated-memory-safety-rules</Features>
  </PropertyGroup>

  <!-- Only CommandError may reach stderr (issue #3319). The rule is enforced by
       the compiler's semantic model via BannedApiAnalyzers, not by a scan of the
       source text, because a scan has to model C# to know what a name binds to
       and every spelling it does not model is a hole. eng/BannedSymbols.txt
       carries the list and the rationale.

       On by default so a project added to the CLI's reference closure inherits
       the rule rather than having to remember it. A project that legitimately
       owns its own stderr — a separate entry point, or a test that captures the
       stream — opts out with <OwnsItsOwnStderr>true</OwnsItsOwnStderr>, and
       StderrOwnershipTests pins the opt-out set against the CLI's closure so an
       opt-out cannot silently appear inside it.

       This lives in Directory.Build.targets (not .props) because the opt-out is
       set in the project file, which .props files are imported before. Items
       added here still take part in restore.

       The .csproj guard excludes project types this rule has no opinion about.
       It does not exclude file-based apps, which is the reading it invites: a
       file-based app builds through a generated project whose
       MSBuildProjectExtension is .csproj, so it inherits the rule. Every
       File-based apps that legitimately own stderr declare the opt-out in their
       nearest Directory.Build.props. eng/ does so directory-wide; standalone
       tools may make the same declaration at their own boundary.

       The rule is repository-wide, not solution-wide. Five projects are outside
       dotnet-inspect.slnx — tests/DotnetInspector.ILRoundtrip.Tests and four
       metadata fixtures — so a solution build is not evidence that this rule
       holds. Build them too, or let CI find it. -->
  <ItemGroup Condition="'$(OwnsItsOwnStderr)' != 'true' and '$(MSBuildProjectExtension)' == '.csproj'">
    <PackageReference Include="Microsoft.CodeAnalysis.BannedApiAnalyzers">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <AdditionalFiles Include="$(MSBuildThisFileDirectory)eng/BannedSymbols.txt" />
  </ItemGroup>

  <!-- Escalated explicitly rather than left to the repository-wide
       TreatWarningsAsErrors default. Warning-producing fixture projects can opt
       out of that default, but the banned-API rule must remain an error
       everywhere it is on. -->
  <PropertyGroup Condition="'$(OwnsItsOwnStderr)' != 'true' and '$(MSBuildProjectExtension)' == '.csproj'">
    <WarningsAsErrors>$(WarningsAsErrors);RS0030</WarningsAsErrors>
  </PropertyGroup>

  <!-- Source-mapping warnings always fail restore. Audit findings fail only
       when the nightly audit explicitly enables NuGetAudit. Neither policy is
       relaxed by a warning-producing fixture's compiler-specific exception. -->
  <PropertyGroup>
    <WarningsAsErrors>$(WarningsAsErrors);NU1507;NU1901;NU1902;NU1903;NU1904</WarningsAsErrors>
  </PropertyGroup>

</Project>