<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <!--
    Both attributes here are side-by-side activation fields, and this application does not use
    side-by-side activation, so nothing reads either of them. They are deliberately not kept in step
    with anything.

    The version a person sees comes from the PE version resource, which MSBuild fills from
    FileVersion, which MinVer fills from the nearest v* tag. The version an update decision is made on
    is the one baked into the Velopack package. Neither passes through here, and wiring this attribute
    to the real version would be machinery maintaining a value with no reader.

    The name likewise stays DodoSSH.Client.App even though the assembly is now called DodoSSH.
  -->
  <assemblyIdentity version="1.0.0.0" name="DodoSSH.Client.App" />

  <!--
    Required, not optional. Without a supportedOS list Windows reports a downlevel version to the
    process, and Avalonia's native control host then fails outright with "Unable to create child
    window for native control host" — so the WebView, and therefore the terminal, does not start at
    all. The failure names the manifest, which is the only reason it is quick to diagnose.
  -->
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />
      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />
      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
      <!-- Windows 10 and 11 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
    </application>
  </compatibility>

  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <!--
        Per-monitor v2, so text stays crisp when a window moves between displays of different
        scale. A terminal is almost entirely text, so bitmap-stretched glyphs are more obvious
        here than in most applications.
      -->
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </windowsSettings>
  </application>
</assembly>
