2009-12-22 6 views
3

J'ai créé un service Windows. Je veux ouvrir une application basée sur Windows à partir de ce service.Comment puis-je configurer mon service Windows dans le code pour accéder au bureau?

Mais mon service Windows est incapable de démarrer les applications de bureau. Pour activer l'accès que je devais faire les étapes suivantes:

  1. Opened l'outil d'administration « Services »

  2. faites un clic droit sur mon service et a dû sélectionner « Propriétés »

  3. Puis, en l'onglet "Connexion", sélectionné "Autoriser le service à interagir avec le bureau".

Après que mon service peut ouvrir les fenêtres souhaité sur la base des processus. Puis-je configurer mon service Windows avec le code (C#) pour accéder au bureau afin de ne pas avoir à modifier manuellement l'autorisation d'accès après l'installation?

+0

Oui, vous pouvez. Quelle langue? –

+0

je dois faire dans C# – Pankaj

Répondre

3

Dans .NET, vous pouvez remplacer la méthode OnCommited de la classe d'installateur de service pour configurer le service pour accéder au bureau. Le code se penchera comme suit:

[RunInstaller(true)] 
public partial class ProjectInstaller : Installer 
{ 
    private ServiceProcessInstaller serviceProcessInstaller; 
    private ServiceInstaller serviceInstaller; 

    public ProjectInstaller() 
    { 
     InitializeComponent(); 

     // adjust configuration to whatever is needed 
     serviceInstaller = new ServiceInstaller(); 
     serviceInstaller.ServiceName = "My Service"; 
     serviceInstaller.DisplayName = "My Service"; 
     serviceInstaller.StartType = ServiceStartMode.Manual; 
     this.Installers.Add(serviceInstaller); 

     serviceProcessInstaller = new ServiceProcessInstaller(); 
     serviceProcessInstaller.Account = 
      System.ServiceProcess.ServiceAccount.LocalSystem; 
     serviceProcessInstaller.Password = null; 
     serviceProcessInstaller.Username = null; 
     this.Installers.Add(serviceProcessInstaller); 
    } 

    protected override void OnCommitted(IDictionary savedState) 
    { 
     base.OnCommitted(savedState); 

     // The following code sets the flag to allow desktop interaction 
     // for the service 
     // 
     using (RegistryKey ckey = 
      Registry.LocalMachine.OpenSubKey(
       @"SYSTEM\CurrentControlSet\Services\My Service", true)) 
     { 
      if (ckey != null && ckey.GetValue("Type") != null) 
      { 
       ckey.SetValue("Type", (((int)ckey.GetValue("Type")) | 256)); 
      } 
     } 
    } 
} 
+0

Merci Divo .... – Pankaj

+1

Re vrai/faux; voir "important" ici: http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx –

+0

Merci Marc Gravell.Nice article et aussi un moyen facile de mettre en œuvre l'exigence. mais en ce moment mon aîné ne me permet pas de changer la structure c'est pourquoi j'essaye de résoudre ce problème. – Pankaj

3

juste ... ne sont pas. Ce n'est pas le travail d'un service. Pour ce travail, vous devriez utiliser une application utilisateur (peut-être dans leur démarrage) qui (si nécessaire) parle à un service via IPC. Je suis crois le plan est de rendre l'interface utilisateur indisponible à partir des services à un moment donné (à partir de Vista, j'ai cessé de faire service < => bureau longtemps temps).

Pour des raisons:

  • si vous avez plusieurs utilisateurs connectés (changement rapide d'utilisateur)? Et si vous avez plusieurs sessions RDP?

Ce que vous proposez n'échelles vraiment 1, et peut-être pas l'événement que si l'on considère que « la session 0 » est réservé à l'administration sur certains systèmes (si l'utilisateur interactif ne nécessairement sur la session 0).

+0

Je ne suis pas d'accord. Lors de l'automatisation des applications via un service, l'indicateur permettant l'accès au bureau doit être défini pour certaines applications (par ex.lorsque la seule façon d'interagir est via le presse-papiers). Certes, l'échelle est peut-être un problème, mais une solution qui n'échelle est souvent mieux que pas de solution du tout (comme l'évolutivité est pas toujours une exigence). –

+1

Ensuite: n'automatisez pas les applications via un service. Utilisez une application dans la session de l'utilisateur qui * parle * au service. Je l'ai dit dans la réponse ci-dessus. C'est peut-être une solution un peu plus * complexe *, mais c'est la solution * juste *. –

+0

Je ne voudrais pas aller aussi vite que dire qu'une chose est juste et l'autre tort. Pensez aux services qui utilisent des applications existantes pour effectuer des tâches telles que l'impression/la conversion automatique de documents. En général, vous ne pouvez pas l'application (MS Office, OpenOffice, WordPerfect héritage, etc.) écouter un service. Quand tout est contrôlé par votre service, vous pouvez même créer plusieurs sessions en parallèle sans la nécessité d'un utilisateur interactif tout pour qu'il soit parfaitement adapté pour fonctionner sur un serveur. Bien sûr, les outils de ligne de commande sont mieux adaptés pour de tels travaux, mais vous n'avez pas toujours le choix. –

Questions connexes