Directory.Build.props

<Project>
  <PropertyGroup>
    <PackageLicenseExpression>MIT</PackageLicenseExpression>
    <RepositoryUrl>https://github.com/LayeredCraft/compono</RepositoryUrl>
    <RepositoryType>git</RepositoryType>
    <Authors>Nick Cipollina</Authors>
    <PackageProjectUrl>https://github.com/LayeredCraft/compono</PackageProjectUrl>
    <PackageIcon>icon.png</PackageIcon>
    <PackageReadmeFile>README.md</PackageReadmeFile>
    <PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
    <!-- ADR-0031's discovery-metadata bar, centralized here rather than per-project since all five
         packages distribute as one coherent set (same reasoning as PackageLicenseExpression/
         RepositoryUrl/PackageIcon/PackageReadmeFile above) - no per-package tag differentiation
         (e.g. xunit/nsubstitute/bogus), since the package name itself already carries that. -->
    <PackageTags>testing;test-data;source-generator;dotnet</PackageTags>
    <!-- Points at the repo's stable releases index, not a per-version tag URL - a per-version
         .../releases/tag/v$(Version) link would 404 for every preview build publish-preview.yaml
         pushes on a plain main push, since no GitHub Release/tag exists for those, only for
         versions published through publish-release.yaml. -->
    <PackageReleaseNotes>$(PackageProjectUrl)/releases</PackageReleaseNotes>
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
    <CheckEolTargetFramework>false</CheckEolTargetFramework>
  </PropertyGroup>

  <PropertyGroup>
    <DebugType>embedded</DebugType>
    <NoPackageAnalysis>true</NoPackageAnalysis>
    <LangVersion>latest</LangVersion>
    <GeneratePackageOnBuild>False</GeneratePackageOnBuild>
  </PropertyGroup>

  <!-- MSBuild auto-imports process environment variables as property values (case-insensitively)
       whenever no project-file assignment has already set that property - CI's shared devops-
       templates PR-build workflow sets a GITHUB_ENV variable named "outputPath" (intended only for
       its own later Blazor/Lambda publish steps, which read it explicitly via an "output" CLI flag),
       but that variable stays set as a process env var for every subsequent step in the same job,
       including the plain "dotnet build"/"dotnet test" steps this repo's own PR build actually runs.
       Left unset, that env var satisfies MSBuild's standard `OutputPath`
       property (same name, case-insensitive) for every project the SDK builds - collapsing every
       project's per-TFM output into one shared directory across the entire solution instead of each
       project's own bin/<config>/<tfm>/. Verified by reproducing locally: `outputPath=<path> dotnet
       build Compono.slnx` puts every project (libraries and test projects alike) into
       <path>/<tfm>/ together. That shared directory is exactly the kind of setup where two
       projects' concurrent MSBuild copy-to-output steps can race on the same shared runtime
       dependency file - the actual cause of the intermittent "Could not load ...
       Microsoft.Testing.Extensions.MSBuild ... cannot find the file" CI flake (a different TFM each
       run, never reproducible via a single local build - exactly what a race looks like), not a
       missing/unpinned package reference. Explicitly reasserting OutputPath here, unconditionally,
       restores the SDK's own default per-project/per-TFM computation regardless of what an external
       CI environment happens to leak in - the same value
       Microsoft.NET.DefaultOutputPaths.targets computes when OutputPath was never externally set.
       Resetting to empty (not to an explicit bin\$(Configuration)\$(TargetFramework)\ value) is
       deliberate - a multi-targeted project's inner per-TargetFramework build unconditionally
       appends $(TargetFramework)\ onto whatever OutputPath already resolves to, so hardcoding that
       same segment here would double it (bin\Release\net10.0\net10.0\, verified while testing this
       fix). Resetting to empty instead makes the SDK's own conditional default-path computation
       fire again, exactly as if the leaked env var had never been set. -->
  <PropertyGroup>
    <OutputPath></OutputPath>
  </PropertyGroup>

  <!-- Tests never get packed - only src/ packages are consumer-facing. -->
  <PropertyGroup Condition="'$(IsTestProject)' == 'true'">
    <IsPackable>false</IsPackable>
  </PropertyGroup>

  <!-- documentation.md requires XML doc comments on every public member of a
       consumer-facing package, from the first one added - unlike a codebase
       with tracked doc-comment debt, CS1591 (missing XML doc comment) is
       deliberately left as a real build warning rather than suppressed here,
       so a missing doc comment on a new public member is caught immediately
       instead of silently accumulating. Applied unconditionally (not scoped
       off for test projects) because IsTestProject/IsPackable aren't reliably
       set yet at Directory.Build.props import time (it's imported before the
       project body) - see Directory.Build.targets, imported after the
       project body, for the test-project-only NoWarn that actually excludes
       test code from this. -->
  <PropertyGroup>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
  </PropertyGroup>

  <ItemGroup Condition="'$(IsPackable)' != 'false'">
    <None Include="$(MSBuildThisFileDirectory)icon.png" Pack="true" PackagePath="" Visible="false" Condition="Exists('$(MSBuildThisFileDirectory)icon.png')" />
    <None Include="$(MSBuildThisFileDirectory)README.md" Pack="true" PackagePath="" Visible="false" Condition="Exists('$(MSBuildThisFileDirectory)README.md')" />
  </ItemGroup>

  <!-- ADR-0031/PLAN-0008 Phase 0: API-compatibility baseline check for every publishable package.
       Deliberately no static PackageValidationBaselineVersion here - publish-preview.yaml/
       publish-release.yaml are opaque `uses:` calls to the shared devops-templates workflow with no
       step-level hook to inject a "compute baseline, then pack" sequence into, so the baseline is
       instead resolved and passed in (-p:PackageValidationBaselineVersion=<prior-version>) by this
       repo's own locally-controlled pre-merge PR gate (see the new package-validation.yaml
       workflow), not by either publish workflow. Validation is simply inert when no baseline is
       supplied (the very first-ever publish of a package). -->
  <PropertyGroup Condition="'$(IsPackable)' != 'false'">
    <EnablePackageValidation>true</EnablePackageValidation>
  </PropertyGroup>

  <ItemGroup Condition="'$(IsPackable)' != 'false'">
    <PackageReference Include="Microsoft.SourceLink.GitHub">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>
</Project>