drakulavl

Клиент: WPF.
Сервер: C# на HttpListener.
Транспорт: tls > http > json

По минимуму нужно два exe-шника + 2 dll:

1) на клиенте:
— Client.exe - модуль запуска клиентского приложения: проверяет обновления, загружает по необходимости другие файлы с сервера, передает управление в UserInterface.dll
— Common.dll - содержит программный код, общий как для клиентской, та и для серверной части;
— UserInterface.dll - содержит код, специфический для клиентской части.

2) на сервере:
— AppServer.exe - работает в качестве службы Windows, содержит код, специфический для серверной части;
— Common.dll - содержит программный код, общий как для клиентской, та и для серверной части.

Опробовано многократно.

1 - ну не факт про формы (сразу в трэш) - все зависит от сложности клиентской стороны. простой клиент на формах будет проще и создать и поддерживать (красивые мордочки есть, достаточно правильно задать вопрос тут или поисковикам) если функционал сложный, много повторяющихся элементов, нужен надежный биндинг - тогда да, wpf

2 - если сервер внутрикорпоративный - можно и на прямую с БД работать, опять же от сложности бизнес-логики все зависит, возможно стоит посмотреть на SignalR есть кейсы/демки прямо вот под десктоп клиента

однозначый совет невозможен - у любой задачи/команды есть особенности, есть различия и в навыках и в ресурсах, как требуемых, так и наличиствующих

если речь о небольшой конторе, где все уже на вин10 - почему не рассматривать сразу UWP?
если вдруг УЖЕ есть лицензия на MS SQL - довесить SSRS и возможно 90% нужд покроет готовый бесплатный UWP клиент?

Можно и в сторону трехзвенности посмотреть.
Только вот WinForms - однозначно в трэш. Смотреть в сторону WPF.

При должной организации архитектуры - получится конструкция, которая позволит "боковичком" встраивать и web-клиента (это может потребоваться в том или ином варианте интеграции с внешними сервисами/сайтом/мобильными клиентами)