UA-.NETStandard/Directory.Build.targets

<Project>
  <!--
    Per-project opt-in for the CI per-TFM build matrix: when a `.csproj`
    sets `<RestrictForLegacyTfm>true</RestrictForLegacyTfm>` in its main
    `PropertyGroup`, this Directory.Build.targets makes the project a
    no-op build (empty Library, no compile items, no references) for
    `dotnet build … /p:CustomTestTarget=<tfm>` invocations that the
    project cannot take part in.  That is the case for
    `<tfm>` in `net472` / `net48` / `netstandard2.0` / `netstandard2.1`,
    and for any project that pins a single `TargetFramework` different
    from `<tfm>`.  Use this for projects that are `.NET 8+` only
    (e.g. `PublishAot=true`, `ModelContextProtocol` server, TUnit AOT
    tests) and therefore can't participate in a `UA.slnx` build pinned
    to a legacy TFM via `CustomTestTarget`.

    The single-`TargetFramework` case matters because `CustomTestTarget`
    only redirects the shared TFM variables in `targets.props`; a project
    that hardcodes, say, `net10.0` keeps compiling against its own
    reference assemblies while the rest of the stack is built for
    `<tfm>`.  Mixing the two surfaces as `CS0433` on every BCL type the
    stack polyfills for older frameworks (`System.Threading.Lock` is
    defined by `Opc.Ua.Types` on `net8.0` and by `System.Runtime` on
    `net9.0+`), which is a property of the pinned build rather than of
    the project's own sources.

    The project still loads in the `.slnx` graph so the matrix prep
    script discovers it, but `Compile` / `ProjectReference` /
    `PackageReference` / `AdditionalFiles` / `None` / `Content` are all
    cleared and `OutputType` flips to `Library`, producing an empty
    assembly without dragging the project's `.NET 8+` source through
    the C# compiler against the restricted dependency set.

    Targets are deliberately NOT overridden here - same-named targets
    in `Directory.Build.targets` ALWAYS replace the SDK definitions
    (the `Condition` only gates execution, not registration), which
    would silently break the SDK's restore in unrestricted builds
    (e.g. the GitHub Actions `dotnet publish` / `dotnet test` flows
    that don't pass `CustomTestTarget`).

    Projects that don't set `RestrictForLegacyTfm` are completely
    unaffected by this file - every condition below evaluates to
    false and no items / properties / targets are touched.
  -->
  <PropertyGroup>
    <_RestrictedToLegacyTfm
        Condition="'$(RestrictForLegacyTfm)' == 'true' and ('$(CustomTestTarget)' == 'net48' or '$(CustomTestTarget)' == 'net472' or '$(CustomTestTarget)' == 'netstandard2.0' or '$(CustomTestTarget)' == 'netstandard2.1')">true</_RestrictedToLegacyTfm>
    <!-- Multi-targeted projects follow CustomTestTarget through targets.props,
         so only a project that pins exactly one TargetFramework can end up
         building against a framework the rest of the solution is not using. -->
    <_RestrictedToLegacyTfm
        Condition="'$(RestrictForLegacyTfm)' == 'true' and '$(CustomTestTarget)' != '' and '$(TargetFrameworks)' == '' and '$(TargetFramework)' != '' and '$(CustomTestTarget)' != '$(TargetFramework)'">true</_RestrictedToLegacyTfm>
  </PropertyGroup>
  <PropertyGroup Condition="'$(_RestrictedToLegacyTfm)' == 'true'">
    <OutputType>Library</OutputType>
    <EnableDefaultCompileItems>false</EnableDefaultCompileItems>
    <EnableDefaultEmbeddedResourceItems>false</EnableDefaultEmbeddedResourceItems>
    <EnableDefaultNoneItems>false</EnableDefaultNoneItems>
    <EnableDefaultContentItems>false</EnableDefaultContentItems>
    <IsPackable>false</IsPackable>
    <PackAsTool>false</PackAsTool>
    <PublishAot>false</PublishAot>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <GenerateTargetFrameworkAttribute>false</GenerateTargetFrameworkAttribute>
    <NoWarn>$(NoWarn);CS2008;CA1014;CA1016</NoWarn>
    <!-- The no-op shell strips all references, so on netstandard2.x there is no
         assembly providing System.Object; supply an explicit RuntimeMetadataVersion
         so the empty assembly still compiles (net4x get it from the targeting pack). -->
    <RuntimeMetadataVersion Condition="'$(RuntimeMetadataVersion)' == ''">v4.0.30319</RuntimeMetadataVersion>
  </PropertyGroup>
  <ItemGroup Condition="'$(_RestrictedToLegacyTfm)' == 'true'">
    <Compile Remove="@(Compile)" />
    <ProjectReference Remove="@(ProjectReference)" />
    <PackageReference Remove="@(PackageReference)" />
    <AdditionalFiles Remove="@(AdditionalFiles)" />
    <None Remove="@(None)" />
    <Content Remove="@(Content)" />
  </ItemGroup>
  <Target Name="_LogSkippedForLegacyTfm" BeforeTargets="Build" Condition="'$(_RestrictedToLegacyTfm)' == 'true'">
    <Message Importance="high" Text="Skipping $(MSBuildProjectName) for CustomTestTarget=$(CustomTestTarget) (.NET 8+ only)." />
  </Target>
  <!--
    Every package in this repository is licensed under the OPC Foundation MIT
    License 1.00 and ships the shared `LICENSE.txt` that `common.props` wires
    up as `<PackageLicenseFile>`. That license is NOT the plain SPDX `MIT`
    license: it carries the OPC Foundation copyright and preamble, so a package
    declaring `<PackageLicenseExpression>MIT</PackageLicenseExpression>` would
    advertise the wrong license on nuget.org (generic MIT plus a
    `licenses.nuget.org/MIT` URL) instead of the OPC Foundation text.

    Such a declaration also breaks the build outright: NuGet refuses to pack a
    project that carries both a license expression and the inherited license
    file (`NU5033: Cannot specify both a PackageLicenseExpression and a
    PackageLicenseFile`), which fails `pack` for the whole solution rather than
    just the offending project.

    `common.props` cannot catch this itself - it is imported from
    `Directory.Build.props`, i.e. before the project body, so it never observes
    a project-level license expression. `Directory.Build.targets` is imported
    after the project body, so it is the earliest place that can, and it fails
    with an actionable message instead of the cryptic NuGet error.
  -->
  <Target Name="_ValidatePackageLicense" BeforeTargets="Build;Pack"
          Condition="'$(IsPackable)' != 'false' AND '$(PackageLicenseExpression)' != ''">
    <Error Code="OPCUA0001"
           Text="$(MSBuildProjectName) sets PackageLicenseExpression=$(PackageLicenseExpression). Every package must ship the OPC Foundation MIT License 1.00 via the shared LICENSE.txt that common.props sets as PackageLicenseFile, which the SPDX expression neither matches nor is allowed to coexist with (NU5033). Remove the PackageLicenseExpression property." />
  </Target>
  <!--
    On netstandard target frameworks two [LoggerMessage] source generators can be active at once:
    the in-box generator shipped in Microsoft.Extensions.Logging(.Abstractions) and the R9
    Microsoft.Gen.Logging generator that flows in transitively from R9 packages such as
    Microsoft.Extensions.Http.Resilience / .Compliance / .Telemetry. Both emit an implementation
    for every partial [LoggerMessage] method, producing CS0757 ("a partial method may not have
    multiple implementing declarations"). On .NET Framework and net8.0+ only the R9 generator runs,
    so removing the R9 analyzer on netstandard leaves exactly one generator on every TFM. The
    Analyzer Remove is a no-op for projects that don't reference Microsoft.Gen.Logging.
  -->
  <Target Name="RemoveDuplicateLoggingGenerator" BeforeTargets="CoreCompile"
          Condition="'$(TargetFrameworkIdentifier)' == '.NETStandard'">
    <ItemGroup>
      <Analyzer Remove="@(Analyzer)"
                Condition="$([System.String]::Copy('%(Analyzer.Identity)').Contains('Microsoft.Gen.Logging'))" />
    </ItemGroup>
  </Target>
  <!--
    A `ProjectReference` with `OutputItemType=Analyzer` hands the compiler only the referenced
    project's own assembly, never its runtime closure. The `Opc.Ua.SourceGeneration*` generators
    need Opc.Ua.SourceGeneration.Core, Opc.Ua.Types and the Microsoft.Extensions.Logging /
    System.Text.Json graph at generator-load time, so without those paths the compiler cannot
    resolve them and the generators fail to initialize (CS8784).

    Registering the closure as `Analyzer` items mirrors the `analyzers/dotnet/<roslyn>/cs`
    payload the generator NuGet packages ship (see tools/SourceGeneratorPack.targets), which
    NuGet registers the same way for package consumers. The closure is discovered by globbing
    the generator's output directory, so a new dependency never needs a project file change.

    Assemblies the compiler itself supplies are excluded. Handing the compiler a second copy
    of Microsoft.CodeAnalysis*, System.Collections.Immutable or System.Reflection.Metadata
    splits the identity of types that cross Roslyn's own API surface and breaks generator
    initialization. See roslyn.props.
  -->
  <Target Name="AddSourceGeneratorAnalyzerDependencies" BeforeTargets="CoreCompile">
    <ItemGroup>
      <_SourceGeneratorAnalyzer Include="@(Analyzer)"
                                Condition="'%(Analyzer.MSBuildSourceProjectFile)' != '' AND
                                  $([System.String]::Copy('%(Analyzer.Filename)').StartsWith('Opc.Ua.SourceGeneration'))" />
      <_SourceGeneratorAnalyzerDependency
          Include="%(_SourceGeneratorAnalyzer.RootDir)%(_SourceGeneratorAnalyzer.Directory)*.dll"
          Exclude="@(_SourceGeneratorAnalyzer);
                   %(_SourceGeneratorAnalyzer.RootDir)%(_SourceGeneratorAnalyzer.Directory)Microsoft.CodeAnalysis*.dll;
                   %(_SourceGeneratorAnalyzer.RootDir)%(_SourceGeneratorAnalyzer.Directory)System.Collections.Immutable.dll;
                   %(_SourceGeneratorAnalyzer.RootDir)%(_SourceGeneratorAnalyzer.Directory)System.Reflection.Metadata.dll" />
      <Analyzer Include="@(_SourceGeneratorAnalyzerDependency->Distinct())" />
    </ItemGroup>
  </Target>
</Project>