Les événements de mise en veille prolongée (Sleep / Hibernate) peuvent s’avérer indispensables pour une application connectée, car les connexions vont être interrompues. Cet article présente deux approches: la première basée sur l’API standard SystemEvents, qui pose problème dans un service Windows; l’autre basée sur WMI qui fonctionnera dans tous les cas de figure (pour autant que je sache).

SystemEvents.PowerModeChanged

Le framework .NET fournit l’API SystemEvents à cet effet, avec l’événement PowerModeChanged.

Malheureusement, comme l’indique MSDN, cette API ne fonctionne pas en mode Service sans un petit « hack ».

MSDN recommande deux alternatives pour utiliser SystemEvents depuis un service Windows:

• Instancier une fenêtre (Form) masquée.
• Configurer le service pour interagir avec le bureau (ce qui n’est possible qu’avec le compte de service Local System, à moins d’avoir lu cet article).

Concrètement, SystemEvents dépend du mécanisme Message Pump mis en oeuvre automatiquement sur le thread principal lorsqu’on instancie la première fenêtre de l’application.

Aucune de ces deux solutions n’est vraiment élégante et il existe un autre moyen basé sur WMI, qui ne requiert aucun de ces hacks.

WMI

WMI, ou faut-il dire CIM maintenant, propose à cet effet l’API Win32_PowerManagementEvent.

Un exemple complet en C# est ici.

La logique est dans le composant Win32PowerManagementEventWatcher. La seule subtilité est que l’on traite indifféremment les événements ResumeFromSuspend et ResumeAutomatic comme une sortie de veille. À ce sujet, je vous conseille de lire les détails sur Stackoverflow.

Conclusions

En conclusion, sur une application avec une interface utilisateur (WinForms, WPF, ou console), l’API standard SystemEvents devrait être le premier choix car c’est le plus simple et le plus performant dans cette situation.

Cependant, contrairement à ce qui est proposé par MSDN, sur une application sans interface, je pense que WMI est la méthode la plus propre. Certes WMI est réputé pour être lent, cependant cette API consiste ici à s’abonner à un événement: l’inscription peut être lente mais celle-ci est typiquement effectuée une seule fois pour toute la durée de vie de l’application. Les notifications elles-mêmes ne paraissent pas être significativement plus lentes.