<Project Sdk="Microsoft.NET.Sdk">

  <!--
    Does the window fit?

    A second test project for one source project, and not for tidiness. Avalonia's application, dispatcher
    and platform are process-global singletons that can be initialised exactly once, so a suite that stands
    one up cannot share a process with one that must not have one. DodoSSH.Client.App.Tests is deliberately
    Avalonia-free — it runs the shell's state machine as ordinary objects — and keeping the renderer out of
    that process is what keeps it that way.

    What this covers is the class of defect nothing else here can see: a control laid out past the edge of
    its container, where it cannot be clicked. This window has shipped that once already, when the setup
    screens rendered sliced with their buttons unreachable.

    What it does not cover: the terminal's native child window compositing over Avalonia content. That is a
    Win32 property of a real window and no headless surface reproduces it — see the comments in
    MainWindow.axaml, which is why the WebView is collapsed rather than covered.
  -->

  <PropertyGroup>
    <!--
      Matches DodoSSH.Client.App rather than the repository default. This project loads that project's
      views, and a harness that measures text under different globalization rules than the application
      uses is measuring something the user never sees.
    -->
    <InvariantGlobalization>false</InvariantGlobalization>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Avalonia.Headless" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="../../src/DodoSSH.Client.App/DodoSSH.Client.App.csproj" />
  </ItemGroup>

  <ItemGroup>
    <!--
      Shared by source rather than copied or reached through a project reference.

      Laying out the vault column needs a real VaultViewModel, which needs a real unlocked VaultSession,
      which needs an enrollment — and enrollment is the one step that cannot be done without a server to
      enroll against. These fakes already exist for DodoSSH.Client.Session.Tests and there is no second
      opinion worth having about them.

      A project reference would make one test project a library of another, and a copy would be a third
      implementation of the same decision table drifting from the other two. A source link is neither: one
      file, compiled into both, changed in one place.
    -->
    <Compile Include="../DodoSSH.Client.Session.Tests/FakeAccountServer.cs"
             Link="Shared/FakeAccountServer.cs" />
  </ItemGroup>

</Project>
