Каков идеальный метод для создания приложения Windows и пакета услуг?

Question

У меня есть проект, над которым я работаю, где мне нужно создать приложение и пакет услуг для Windows. Я хотел бы, чтобы процесс обслуживания выполнялся как SYSTEM или LOCALSYSTEM, чтобы учетные данные были неактуальны. Интерфейс приложения будет установлен и исполнен любым пользователем на машине. Данные из внешнего приложения будут переданы службе - скорее всего, пути к каталогам, выбранным пользователями. После запуска служба будет прослушивать команду для выполнения некоторых действий, принимая при этом вышеупомянутые пути.

Я использую C# на платформе .NET, и я изучил создание автономной службы и отдельного приложения отдельно, а также создание библиотеки служб WCF и хост-приложения - это насколько я получил.

Все эти методы кажутся чрезмерно сложными для достижения того, чего я пытаюсь достичь. Что такое современная конвенция при попытке чего-то подобного? Я желаю и могу изучить лучший способ продвижения вперед.

Редактировать: Это был отмечен как дубликат. Я не ищу информацию о том, КАК общаться с сервисом Windows. Это исправление и совсем не то, о чем я прошу. Я ищу подтверждение того, что я на правильном пути, а если нет, я ищу предложения. Мне сказали, что я на правильном пути и указал на с именем pipe binding.

Answer 1

Служба Windows, безусловно, является вариантом для размещения WCF, хотя это своего рода кошмар развертывания. Это действительно зависит от вашей среды и возможностей и поддержки ваших системных администраторов, поскольку у меня было много клиентов, где развертывание службы Windows, поскольку вам нужны права администратора для установки и обновления, просто не практично.

Консольные приложения могут звучать как страшная идея, но практичность возможности бросить их на долю и запустить сценарий powershell, чтобы начать их, очень убедительно.

Но, честно говоря, у IIS-хостинга есть все преимущества в моем сознании, так как продукт предназначен для простоты развертывания и увеличения времени. И вы можете использовать любую транспортную привязку в IIS, которую вы можете использовать в Windows Service или Console.

Что касается собственно связывания с именем pipe, на самом деле это не популярный вариант во многих корпоративных сценариях, поскольку он несовместим ни с чем, кроме .NET. Хотя то же самое можно сказать и для двоичного кода, который является одним из наиболее эффективных привязок. WSHttpBinding, вероятно, является самым популярным связыванием в сценариях, которые требуют неизвестных абонентов. WebHttpBinding - интересный вариант, поскольку он основан на HTTP/REST, хотя это требует дальнейшего оформления ваших операций, и, честно говоря, если вы идете по этому маршруту, вам действительно нужно использовать Web API.