Выполнение пользовательской функции сервиса

Всем привет
Вопрос к знатокам: в принципе возможно ли реализовать в службе windows пользовательскую функцию (в частности, нужна функция для выполнения запроса к БД и возврата полученных значений) и потом вызывать эту функцию из другого приложения по кнопке и получать готовые результаты запроса к БД?
Я сам в шоке, что пришлось рассматривать такой вариант, но других попросту нет

0

Сообщение от leshiy_t службе windows

Работу, которую вы хотите переложить на windows service, обычно выполняет Web API, то есть веб-хост, который принимает запрос и отдает результат. Запросов нет? - сервис ничего не делает.
Да, Web API можно захостить (step-by-step гайд) как Windows Service.

Добавлено через 5 минут
Только шаблон подправить нужно, на деле вам не RazorPages (и WorkerService) нужен будет, а просто Controllers с маршрутами в описании пайплайна.

Добавлено через 15 минут
Вот еще пакет - Microsoft.Extensions.Hosting.WindowsServices. (правда пример кода оттуда не совсем актуален, но пакет сам по себе актуален).
Разбирайтесь.

Добавлено через 8 минут
Скорее всего, в идеале вам нужно именно Minimal API (если endpoint-ов мало) хостить как Windows Service.
Ссылки выше должны помочь.

0

Любой виндовый сервис -- обычная консольная программна без терминала (т.е. нет UI). Рассматривайте любое межпрограмное взаимодействие которое понравится. Web API хороший вариант, но обычно для програм берут gRPC.

0

Wolfdp, на самом деле не совсем обычное. Оно должно уметь обмениваться сигналами с менеджером служб (через апи специальный) иначе будет прибито как нерабочий сервис.

0

Usaga, Думаю даже если ТС сначала напишет полностью консольный вариант без единого понимания как собирать под сервис -- проблем перевода на сервис не будет и займет минимум времени. Особенно если возьмёт современный вариант web api, где всё стандартизировано и позволяет легко реализовать для обоих случаев, что резко упрощает разработку.

0

Сообщение от Wolfdp если ТС сначала напишет полностью консольный вариант

В этом то и заключается главная проблема - что стандартные решения не работают...
В общем, ситуация следующая:
Я пишу плагин для одной cad программы. Это плагин выбирает из БД необходимые данные, которые потом обрабатываются и отображаются в datagridview. В принципе, никаких сервисов, или дополнительных dll с выносом функция для работы с sql не требовалось - все работало из одной главной dll, которая и запускалась в этой cad программе. Проблема в том, что последние версии этой cad программы перевели на .net6, и этот переход оказался каким-то странным (не уверен, что буква "т" тут уместна) - любое взаимодействие с Microsoft.Data.SqlClient приводят к ошибке "Microsoft.Data.SqlClient is not supported on this platform" внутри этой cad программы. Я пробовал разные варианты - от выделения функций работы с БД в отдельную dll (пробовал .net6, core3.1, framework) до использования REST API и ODBC - результат один - ошибка, что это все не поддерживается в текущей платформе cad программы. Я не знаю, как именно происходит выполнение этих функций и команд, я не на столько грамотный программист, но у меня остался всего один вариант - вынести все функции для работы с БД в сервис, который должен (как я понимаю) выполняться на уровне операционной системы вне зависимости от того, кто вызывает эти функции, и возвращать уже готовый результат.

PS
попробовать web api смогу только в течение недели

0

leshiy_t, пробовали поставить в файле проекта
?

1

leshiy_t, ну так с исходной проблемы и надо было начинать обсуждение...

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

В данном обсуждении есть два поста с возможными решениями:

In my case, adding to .csproj file: <!--see: [url]https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#copylocallockfileassemblies[/url] --> **<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>** <!--<ProduceReferenceAssemblyInOutDir>true</ProduceReferenceAssemblyInOutDir>--> <!--<SupportedOSPlatformVersion>7.0</SupportedOSPlatformVersion>--> **<RuntimeIdentifier>win-x64</RuntimeIdentifier>** managed to make it work. (SQL, ODBC, ...) In my case, I'm developing a DLL plugin for the AutoCAD software, the problem is that all Microsoft's tests / examples are for EXE applications and not for DLLs.

I also had this problem when upgrading from .NET 7.0 to .NET 8.0. Adding the nuget package <PackageReference Include="Microsoft.Data.SqlClient" Version="5.2.0" /> To the executing application csproj fixed it. Why I don't know.

Звёздочками выделены добавленные строки. И две закомментированные\убранные.

1

Сообщение от OwenGlendower пробовали поставить в файле проекта XMLСкопировано 1 <TargetFramework>net6.0-windows</TargetFramework>

Да - изначально было

Сообщение от Usaga Звёздочками выделены добавленные строки

<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> - была изначально
<RuntimeIdentifier>win-x64</RuntimeIdentifier> - добавил и вроде это помогло, по крайней мере тестовая команда выполнилась и я получил нужный результат
Спасибо!!!

0

Сообщение от leshiy_t добавил и вроде это помогло

Если я правильно понимаю, то это из-за сборки Microsoft.Sql.Client.SNI.dll, в которой находится реализация пространственных типов данных и которая является нативной, Windows only. Из-за неё и может быть мозгоклюйство, даже в случае, если пространственные типы данных ты не используешь.

0