Files
DodoSSH/src/DodoSSH.Client.Shell/DodoSSH.Client.Shell.csproj
T
jaap-jan 2caedd93ff Merge branch 'main' into the Android head
Main grew the screens the host-management plan called for — hosts, pins, snippets, logs,
import, teams — plus the ObjectStore and Import projects behind two of them, and moved
WindowsDeviceKeyStore into the desktop head's Platform folder.

Five of those view models landed in a directory this branch had already moved, so they
join the rest in DodoSSH.Client.Shell: git spotted the rename and put them there, and the
namespaces followed. Shell picks up ObjectStore and Import as a result, which the Android
head then gets transitively and will use neither of at first — scoped storage means there
is no ~/.ssh/config to import, and file transfer is out of its first scope.

Desktop suites green at 155 and 64.
2026-07-31 21:03:22 +02:00

68 lines
3.3 KiB
XML

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<AvaloniaUseCompiledBindingsByDefault>true</AvaloniaUseCompiledBindingsByDefault>
<!-- Same reasoning as the two heads: this code formats timestamps and host names for a person. -->
<InvariantGlobalization>false</InvariantGlobalization>
</PropertyGroup>
<ItemGroup>
<!--
Avalonia, but deliberately not Avalonia.Desktop and not a windowing backend. What is actually used
here is Dispatcher, the asset loader and a resource dictionary — none of which imply a window, which
is why this project can be referenced by a phone.
This is the one place the repository's "everything except App is free of Avalonia" rule bends, and it
bends on purpose: the rule existed so the SSH layer, the flow control and the OIDC flow could be
tested without a toolkit, and none of those are here. What is here is the shell's state machine,
which two heads have to agree on exactly.
-->
<PackageReference Include="Avalonia" />
<PackageReference Include="CommunityToolkit.Mvvm" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="../DodoSSH.Client.Session/DodoSSH.Client.Session.csproj" />
<ProjectReference Include="../DodoSSH.Client.Ssh/DodoSSH.Client.Ssh.csproj" />
<ProjectReference Include="../DodoSSH.Client.Terminal/DodoSSH.Client.Terminal.csproj" />
<ProjectReference Include="../DodoSSH.Client.Transfer/DodoSSH.Client.Transfer.csproj" />
<!--
Both arrived with the view models rather than being chosen here. ImportViewModel reads an
~/.ssh/config, and TransfersViewModel puts a bucket behind IRemoteFileStore beside an SFTP host.
Worth knowing for the Android head, which gets both transitively and will use neither at first:
scoped storage means there is no ~/.ssh/config to find, and file transfer is out of its first
scope by decision. Neither is a problem — they are managed assemblies that simply go unused — but
the day the phone grows a file screen, the bucket is the half that ports and the local pane is not.
See docs/android-port.md.
-->
<ProjectReference Include="../DodoSSH.Client.Import/DodoSSH.Client.Import.csproj" />
<ProjectReference Include="../DodoSSH.Client.ObjectStore/DodoSSH.Client.ObjectStore.csproj" />
</ItemGroup>
<ItemGroup>
<!--
The view models are internal, as they were when they lived in the desktop head, and both heads plus
the two shell suites are let in explicitly. Making them public instead would turn every rename of a
command into a compatibility question about an assembly nobody consumes.
-->
<InternalsVisibleTo Include="DodoSSH.Client.App" />
<InternalsVisibleTo Include="DodoSSH.Client.Android" />
<InternalsVisibleTo Include="DodoSSH.Client.App.Tests" />
<InternalsVisibleTo Include="DodoSSH.Client.App.Layout.Tests" />
</ItemGroup>
<ItemGroup>
<!--
The renderer's files, including the vendored xterm bundles. They moved here from the desktop head
when the phone head needed the same terminal: two copies of a vendored bundle is how one of them ends
up a version behind. Embedded rather than copied to disk so there is no separate deployment step.
-->
<AvaloniaResource Include="WebAssets/**" />
<AvaloniaResource Include="Theme/**" />
</ItemGroup>
</Project>