Cela fait déjà plusieurs fois que l'on me fait remonter un bug qui n'en est pas un : votre application ne se ferme pas quand vous le lui demandez. Celle-ci a un ou plusieurs workflows en exécution constante.
Si votre application ne se ferme pas, c'est à cause de vos hôtes de worklows. Ceux-ci resteront actifs tant que vous ne leur aurez pas indiqué la marche à suivre.
Trois possibilités s'offrent à vous : décharger, terminer, annuler (méthode s Unload, Terminate et Cancel).
Un tel contrôle n'est envisageable qu'avec un WorkflowApplication ou un WorkflowServiceHost. Pour le second, cela coïncide avec la fermeture de l'hôte WCF, les blocages à ce moment sont inexistants.
Note: décharger, induira une persistance uniquement si vous avec configuré l'hôte pour qu'il fasse persister son workflow. La persistance n'est donc pas automatique.
Mais il ne faut pas croire pour autant que l'appel de ces méthodes est suffisant. Il faut aussi que l'activité en cours d'exécution accepte d'être interrompue. Pour une activité dont le temps d'exécution peut être long, il faudra impérativement coder la méthode Cancel de vos activités. Malgré son nom, celle-ci peu être utile quel que soit le motif d'interruption de l'exécution du workflow.
Pour rappel, voici un lien vers mon article MSDN : "Bonnes pratiques pour coder des activités avec WF4" qui expliquent entre autres la manière d'implémenter le cancel.
Jeu de briques
Snake
Pacman
Bubble