Directory.Build.props

<Project>

  <PropertyGroup>
    <TargetFramework>net9.0-windows7.0</TargetFramework>
    <UseWPF>false</UseWPF>
    <!-- Allow Linux/macOS to restore & evaluate the net9.0-windows7.0 leg of the multi-targeted
         headless projects (Core/MarketData/Infrastructure/Backtest.Engine/Backtest.Cli) so a plain
         `dotnet build -f net9.0` works on the Pi. Only the net9.0 leg compiles off-Windows; the WPF
         projects are simply never built there. No-op on Windows. -->
    <EnableWindowsTargeting>true</EnableWindowsTargeting>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <LangVersion>latest</LangVersion>
    <TreatWarningsAsErrors>false</TreatWarningsAsErrors>
    <NoWarn>$(NoWarn);CS1591</NoWarn>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
    <Authors>DaxAlgo</Authors>
    <Product>TradingTerminal</Product>
    <Copyright>Copyright (c) $([System.DateTime]::UtcNow.Year)</Copyright>

    <!-- Release version (single source of truth). Bump for every release; the git tag
         the release workflow runs on (e.g. v1.0.0) should match VersionPrefix. -->
    <VersionPrefix>1.0.0</VersionPrefix>
    <AssemblyVersion>1.0.0.0</AssemblyVersion>
    <FileVersion>1.0.0.0</FileVersion>

    <!-- Plugin-SDK package version — single source of truth for the FIVE NuGet packages
         (DaxAlgo.Sdk + DaxAlgo.Sdk.Wpf and the TradingTerminal.Core/UI/UI.Core contract packages
         they depend on; all published in lockstep). MUST equal SdkInfo.Version — the
         nuget-publish workflow refuses to push on a mismatch. Independent of the app release
         VersionPrefix above: the SDK contract has its own cadence (pre-1.0, every minor bump is
         breaking for plugins — see PluginLoader.IsCompatible). -->
    <DaxAlgoSdkVersion>0.1.1-alpha</DaxAlgoSdkVersion>

    <!-- Shared NuGet metadata for the packable projects (inert for everything never packed). -->
    <RepositoryUrl>https://github.com/dhruuvsharma/DaxAlgo-Terminal</RepositoryUrl>
    <PackageProjectUrl>https://github.com/dhruuvsharma/DaxAlgo-Terminal</PackageProjectUrl>
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <IncludeSymbols>true</IncludeSymbols>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>
    <!-- DaxAlgo logo shown on the NuGet.org listing (packed to the package root below). -->
    <PackageIcon>DaxAlgoLogo.png</PackageIcon>

    <PlatformTarget>AnyCPU</PlatformTarget>
    <Platforms>AnyCPU</Platforms>
    <AccelerateBuildsInVisualStudio>true</AccelerateBuildsInVisualStudio>

    <!-- Base directory under which each project's bin lives, mirroring the repo layout. Default:
         in-tree (repo root, trailing slash). Overridden below when build output is redirected
         (Windows dev). Plugin-staging targets use it to locate a sibling project's built output
         regardless of whether the redirect is active. -->
    <DaxAlgoOutputBase>$(MSBuildThisFileDirectory)</DaxAlgoOutputBase>
  </PropertyGroup>

  <!--
    Identity, skipped for WPF's temporary pass-2 project.

    A XAML file that references a type from its OWN assembly (a Window hosting a UserControl declared
    next to it) can't be markup-compiled up front — the assembly doesn't exist yet. WPF's answer is to
    build a throwaway copy of the project, named <Project>_<hash>_wpftmp, and resolve the local types
    against that; pass 2 then looks the type up by ASSEMBLY NAME, since `clr-namespace:` without an
    `assembly=` means "mine". WPF therefore keeps the original AssemblyName on the temp project.

    Deriving AssemblyName from $(MSBuildProjectName) here would overwrite it with the _wpftmp name,
    the name lookup would miss, and every local type would fail with "MC3074: the tag does not exist
    in XML namespace" — with nothing in the error pointing back at this file. So leave the temp
    project alone (the SDK defaults it to the project name anyway, which is all these lines did).
  -->
  <PropertyGroup Condition="!$(MSBuildProjectName.EndsWith('_wpftmp'))">
    <RootNamespace>$(MSBuildProjectName)</RootNamespace>
    <AssemblyName>$(MSBuildProjectName)</AssemblyName>
  </PropertyGroup>

  <!-- Pack the DaxAlgo logo (referenced by PackageIcon above) into every package's root. Inert for a
       project that is never packed — the file is only pulled into a .nupkg by `dotnet pack`. -->
  <ItemGroup>
    <None Include="$(MSBuildThisFileDirectory)assets/DaxAlgoLogo.png" Pack="true" PackagePath="/" Visible="false" />
  </ItemGroup>

  <!--
    Build-output redirect (Windows dev only). This repo lives on a small D: drive that the
    two-tree solution's bin/obj (~2 GB) repeatedly fills — which cascades into "metadata file not
    found" / restore errors. Send all build output to a roomy drive instead, keyed by each
    project's repo-relative path so the windows/ and linux/ trees (which deliberately share project
    names) never collide, and so the layout under the root mirrors the repo.

    Gated on Windows: a Linux/Pi build must keep its default in-tree output (a 'C:\' path would be
    nonsense there). Override the destination by setting a DaxAlgoBuildRoot env var / MSBuild
    property. BaseIntermediateOutputPath must be set here (in Directory.Build.props) so it lands
    before the SDK computes the obj/ location.
  -->
  <PropertyGroup Condition="'$(OS)' == 'Windows_NT'">
    <DaxAlgoBuildRoot Condition="'$(DaxAlgoBuildRoot)' == ''">C:\DaxAlgoBuild</DaxAlgoBuildRoot>
    <!-- Key the redirected output by the checkout's folder name so two checkouts of this repo
         (e.g. the standalone clone, the `public/` submodule inside DaxAlgo-Terminal-Pro, or a
         git worktree) never share obj/bin — sharing them across checkouts at different commits
         causes the same "metadata file not found" cascades the redirect was built to avoid. -->
    <_DaxAlgoRepoDirName>$([System.IO.Path]::GetFileName($([System.IO.Path]::GetDirectoryName('$(MSBuildThisFileDirectory)'))))</_DaxAlgoRepoDirName>
    <_DaxAlgoProjectRel>$([MSBuild]::MakeRelative($(MSBuildThisFileDirectory), $(MSBuildProjectDirectory)))</_DaxAlgoProjectRel>
    <BaseIntermediateOutputPath>$(DaxAlgoBuildRoot)\$(_DaxAlgoRepoDirName)\$(_DaxAlgoProjectRel)\obj\</BaseIntermediateOutputPath>
    <BaseOutputPath>$(DaxAlgoBuildRoot)\$(_DaxAlgoRepoDirName)\$(_DaxAlgoProjectRel)\bin\</BaseOutputPath>
    <DaxAlgoOutputBase>$(DaxAlgoBuildRoot)\$(_DaxAlgoRepoDirName)\</DaxAlgoOutputBase>
  </PropertyGroup>

</Project>