Opkald til native DLL mislykkes fra en .NET Windows-tjeneste

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har en tredjeparts API i form af en indbygget dll, som jeg ringer fra C # ved hjælp af DllImport. Denne native dll afhænger af, at tredjepartsprogrammet er åbent.


Når jeg kører koden normalt, gør API'en det, der forventes og driver applikationen. Men når jeg kører den samme kode som en Windows-tjeneste, returnerer API'en, selv som mig selv, den samme (ikke-dokumenterede) fejlkode, som jeg har set, når programmet er lukket. proces explorer bekræfter, at den native dll er korrekt indlæst fra applikationskataloget.


Hvad kan forårsage dette, og hvordan kan jeg løse problemet?

Bedste reference


Lidt gammel, men det kom op som et af de bedste resultater i en søgning. Så jeg antager mine data vil stadig være hjælpsomme.



  Jeg har en tredjeparts API i form af en native dll, som jeg ringer fra C # ved hjælp af DllImport. Denne native dll afhænger af, at tredjepartsprogrammet er åbent.



Den (t) rustne Office Interop DLL er den samme måde. Du starter faktisk en baggrundseksempel af det pågældende Office-program.
Baggrundsopsøget har brug for en interaktiv session, selvom den ikke viser noget (design asumptions/fejl på arbejdspladsen).
Tjenesterne kører ikke i en interaktiv session siden Vista. Brug af overstyring anbefales ikke til praksis.
Det er en af ​​de (3?) Grunde til ikke at bruge Office Interop længere. [2]


Mulige løsninger:



  1. Stop med at bruge en tjeneste. Windows Task sheduler kan gøre jsut om det samme arbejde, samtidig med at du får fuld interaktive sessioner. Selv MS selv begyndte at flytte ting ud af tjenester, ind i sheduleren hvor muligt

  2. Flyt DLL-adgangen til en Helper-proces. Den kan køre i en interaktiv session. Brug enhver form for interprocess kommunikation til at tale mellem hjælperen og hovedtjenesten. Dette mønster bruges primært til at arbejde med x32 kun dll fra en x64 programm, men det skal også fungere her. Både manifestet og Process.Start () har mulighed for at starte en programm interaktivt fra en Service.



Baseret på en af ​​kommentarerne vises det, at du vælger valgmulighed 2, men bruger en webservice i stedet.
Desværre kører Webserices/Webapplications normalt som Windows Service. Og det er før du mener, at de løber under nogle af de mest restriktive rettigheder (da de er tilgængelige på nettet).
Så det ville bare få dig tilbage til firkant 1 eller endda et andet trin baglæns til firkant 0.

Andre referencer 1


Svære at fortælle, men der er tre muligheder jeg kan tænke på:



  • Din tjeneste har UI-komponent, der kræver indstillingen 'Interagere med skrivebordet'

  • Arbejdsmappen til Windows-tjenesten er\% WinDir\% \ system32 (fx C: \ windows \ system32) og din dll har kode, der bruger relativ stregreference til andre ressourcer, der ikke kan findes

  • Din tjeneste bruger netpipe-kommunikation med programmet, der kører i to forskellige sessioner