Discussion :

[camboui]

Bonjour,

J'essaie de cr�er un Service en C++ contenant des objets COM sous Visual Studio 2015 pro (et Windows 7).

J'ai cr�� un projet ATL win32, sans MFC, sous forme de Service executable (pas DLL).
Appelons-le MonServ.exe.
J'ai ajout� un objet COM, un membre et une m�thode pour essayer.
J'ai ajout� un appel � CoInitializeSecurity(...) dans HRESULT CMonServModule::InitializeSecurity() comme unique t�che "TODO" sugg�r�e par le wizard.
Pas de soucis jusque l�.
(un d�tail curieux, le wizard a en fait cr�� deux projets, le deuxi�me �tant une DLL avec le nom de mon executable suivi de PS en suffix, MonServPS.dll (PS comme Proxy/Stub ???), j'en fais quoi ?).

J'ai ensuite cr�� un autre projet de test win32 console pour acc�der � l'objet COM du premier.
Et l�, je ne parviens pas � acc�der � l'objet COM du service lorsque celui-ci est enregistr� comme tel par windows.

Je m'explique.
Je lance MonService.exe avec l'option -Service: il est enregistr� comme service sous Windows, mais je ne parviens pas � communiquer avec lui depuis mon prg de test (le service est bien demarr�, ou arr�t�, ou en pause, rien n'y change).
Je lance MonService.exe avec l'option -RegServer: l�, Windows le retire de sa liste des services (grrr, pourquoi ???). Par conte mon prg de test acc�de alors bien � l'objet COM (et lance comme par magie MonService.exe que je vois apparaitre dans la liste des t�ches, puis redisparait aussit�t lorsque mon prg de test se termine).

En bref, j'ai un service, ou un objet COM accessible, mais pas les deux en m�me temps, et je ne comprends pas ce qui manque pour cela. Le tout �tant cr�� enti�rement par les wizard de Visual Studio 2015.

Merci pour votre aide.

[camboui]

Petite info suppl�mentaire, j'ai d�bugg� et dans le code atlbase.h l'appel � CoCreateInstance() renvoit le code HRESULT = 0x80080005.
Le message associ� est "Server execution failed".

[M�dinoc]

Franchement je ne suis pas tr�s au fait des (in)compatibilit�s entre les Services Windows et les serveurs DCOM (tout ce que je sais, c'est que les second sont lanc�s par un des premiers, le "Lanceur de processus serveur DCOM", alias DcomLaunch).

Mais il y a fort � parier que DcomLaunch ne sait pas que ton programme doit �tre lanc� via StartService() plut�t que CreateProcess(). Est-ce qu'il existe un moyen de le configurer de la sorte, je l'ignore; mais tant que DcomLaunch lancera ton programme "normalement", l'appel � StartServiceCtrlDispatcher() �chouera avec ERROR_FAILED_SERVICE_CONTROLLER_CONNECT.

PS: MonServerPS.dll est bien le Proxy/Stub servant � marshaller les appels inter-processus pour toute interface que tu d�finis dans ton projet; tu es cens� l'enregistrer au m�me titre que le service, si Visual Studio ne le fait pas tout seul au build.

Toutefois, cette DLL sera superflue si toutes tes interfaces sont Automation-compatibles et marqu�es oleautomation, auquel cas le marshaling se fera via le OLE Automation Marshaler � la place, qui a seulement besoin d'avoir la Type Library contenant tes interfaces � port�e de main.

[M�dinoc]

Je ne trouve pas d'information sur comment configurer un composant DCOM pour que le lanceur le d�marre comme service.

Par contre, si tu es pr�t � ce que le service tourne H24 plut�t que � la demande (et d'ailleurs, j'ai du mal � voir d'autre raison pour laquelle tu voudrais sp�cifiquement que le composant soit un service), tu pourrais probablement t'affranchir compl�tement de DcomLaunch (en ne remplissant pas la cl� LocalServer32 peut-�tre?): Lancer simplement le service en "Automatique" (potentiellement diff�r� pour �viter de surcharger le d�marrage) et laisser COM le trouver dynamiquement...

[bacelar]

Je ne suis pas s�r qu'une approche Service Windows comme host d'un composant COM soit le genre de truc fiable dans des environnements multi-sessions (Terminal Server du bon vieux temps).

Pourquoi le composant en Service et pas dans une Dll d�di�es, qui pourrait ensuite communiquer avec le service via autre chose que COM ?

[bacelar]

Je ne suis pas s�r qu'une approche Service Windows comme host d'un composant COM soit le genre de truc fiable dans des environnements multi-sessions (Terminal Server du bon vieux temps).

Pourquoi le composant en Service et pas dans une Dll d�di�es, qui pourrait ensuite communiquer avec le service via autre chose que COM ?

[camboui]

M�dinoc, merci pour ta r�ponse.
Je pense que tu as compris le contraire de ce que j'exprime

Je souhaite comme tu le dis que le service tourne 24/24h, mais c'est justement dans ce cas que l'objet COM n'est pas trouv� (dynamiquement ?).

L'objet COM est par contre bien trouv� en "Local Server", quand l'EXE est charg� � la demande (ce qui ne m'aide pas, autant faire une DLL).

J'ai trouv� une page chez MS qui explique le d�roulement de cr�ation d'un service avec objet ATL COM, et o� on explique que lors du d�veloppement et pour faciliter le debugging l'objet est enregistr� en "local server".
Ensuite, rien n'emp�che en production d'enregistrer le service en tant que tel en fin de compte.
https://msdn.microsoft.com/en-us/library/74y2334x.aspx
Mais je n'y trouve aucune explication au fait que cela puisse ne pas fonctionner en service

Je pense que le soucis est une question de droit d'utilisateur.
J'ai essay� de faire plusieurs changements, autant dans les param�tres du service que dans la config DCOM, sans succ�s...

Toute aide suppl�mentaire est bienvenue.

[camboui]

Barcelar,
Je souhaite un service car je ne connais pas d'autre moyen d'avoir un prg qui tourne tout le temps, le but �tant de pr�charger en m�moire des donn�es afin de ne pas perdre ce pr�cieux temps � chaque acc�s.
Les DLL ne sont charg�es qu'� la demande, et leur espace m�moire est le m�me que celui du process les appelant (enfin, je crois...). Je me dis qu'avec un service la gestion de m�moire sera sans doute meilleure.

Ceci �tant, je r�cup�re un projet d'il y a 15 ans �crit sous Visual Studio 6.
Visual Studio 6 ne tourne plus sur les OS plus r�cents que XP. Des soucis de maintenance commence � se poser...
Je transf�re le tout sous VS2015 mais je dois conserver la compatibilt� d'usage, c-�-d la communication COM (script en VB, JS, ASP, etc...).
C'est une DLL, mais je voulais en faire un service pour �viter les initialisations r�currentes.

J'utilise toujours ceci en COM:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
#import <C:\Program Files\Common Files\SYSTEM\ADO\msado60.tlb> named_guids rename("EOF", "EndOfFile")
#import <msxml6.dll> named_guids

S'il y a mieux aujourd'hui, je suis preneur (c'est vrai que c'est vieux COM).

[M�dinoc]

Pour voir si c'est un probl�me de s�curit�, essaie en assignant au service le m�me utilisateur que celui qui tente de contacter l'objet.