Сбой вызова родной библиотеки DLL из службы .NET Windows

Question

У меня есть сторонний API в виде собственной dll, которую я вызываю из C #, используя DllImport.Эта собственная dll зависит от того, открыто ли приложение стороннего производителя.

Когда я обычно запускаю код, API делает то, что ожидается, и управляет приложением.Однако, когда я запускаю тот же код, что и служба Windows, даже я, API возвращает тот же (недокументированный) код ошибки, который я видел при закрытии приложения;Обозреватель процессов подтверждает, что собственная dll правильно загружена из каталога приложения.

Что может быть причиной этого и как я могу решить проблему?

Answer 1

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

У меня есть сторонний API в виде нативной dll, которую я вызываю из C #, используя DllImport. Этот родной dll зависит от того, открыто ли приложение стороннего производителя.

(t) ржавая библиотека Office Interop работает точно так же. Вы фактически запускаете фоновый экземпляр рассматриваемой программы Office. Фоновый экземпляр нуждается в интерактивном сеансе, даже если он ничего не показывает (предположения / ошибки при разработке). Службы не работают в интерактивном сеансе , начиная с Vista . Использование переопределения не рекомендуется. Это одна из (3?) Причин, по которой мы больше не используем Office Interop.

Возможные обходные пути:

1. прекратить пользоваться услугой. Шедулер задач Windows может выполнять примерно ту же работу, предоставляя вам полные интерактивные сеансы. Даже MS сама начала перемещать вещи из сервисов в Sheduler, где это возможно
2. переместить доступ к DLL в процесс Helper. Это можно запустить в интерактивном сеансе. Используйте любой способ межпроцессного взаимодействия, чтобы общаться между помощником и основным сервисом. Этот шаблон в основном используется для работы с dll x32 только из программы x64, но он должен работать и здесь. И манифест, и Process.Start () имеют способ интерактивного запуска программы из Сервиса.

Судя по одному из комментариев, вы выбираете вариант 2, но вместо этого используете веб-сервис. К сожалению, веб-версии / веб-приложения обычно запускаются как служба Windows. И это, прежде чем вы считаете, что они работают под некоторыми из самых ограничительных прав (так как они доступны в Интернете). Таким образом, вы просто вернетесь к квадрату 1 или даже вернетесь на шаг 0.

Answer 2

Трудно сказать, но есть три возможности, о которых я могу подумать:

• Ваш сервис имеет компонент пользовательского интерфейса, для которого требуется опция "взаимодействовать с рабочим столом"
• Рабочий каталог дляСлужба Windows -% WinDir% \ system32 (например, C: \ windows \ system32), и у вашей dll есть код, который использует относительную ссылку на путь к другим ресурсам, которые не могут быть найдены
• Ваша служба использует соединение по сети через приложениекоторые запускаются в двух разных сессиях