Nouveautés de Windows Workflow Foundation dans .NET Framework 4.5
Windows Workflow Foundation (WF) dans .NET Framework 4.5 présente de nombreuses nouvelles fonctionnalités, notamment de nouvelles activités, fonctionnalités de concepteur et modèles de développement de workflow. Nombre des nouvelles fonctionnalités de workflow introduites dans .NET Framework 4.5 sont prises en charge dans le concepteur de workflow réhébergé. Pour plus d’informations sur les nouvelles fonctionnalités prises en charge, consultez Prise en charge de nouvelles fonctionnalités Workflow Foundation 4.5 dans le concepteur de workflow réhébergé. Pour plus d’informations sur la migration des applications de workflow .NET Framework 3.0 et .NET Framework 3.5 afin d’utiliser la dernière version, consultez Conseils de migration. Cet article fournit une vue d’ensemble des nouvelles fonctionnalités de workflow introduites dans .NET Framework 4.5.
Avertissement
Les nouvelles fonctionnalités Windows Workflow Foundation introduites dans .NET Framework 4.5 ne sont pas disponibles pour les projets qui ciblent les versions précédentes de l’infrastructure. Si un projet qui cible .NET Framework 4.5 est reciblé vers une version antérieure du .NET Framework, plusieurs problèmes peuvent se produire.
- Les expressions C# seront remplacées dans le concepteur par le message Valeur définie en XAML.
- De nombreuses erreurs de build se produisent, y compris l'erreur suivante.
Le format de fichier n'est pas compatible avec l'infrastructure objet du ciblage. Pour convertir le format de fichier, enregistrez-le de manière explicite. Ce message d'erreur disparaîtra une fois que vous aurez enregistré le fichier et rouvert le concepteur.
Contrôle de version pour le workflow
Le .NET Framework 4.5 présente plusieurs nouvelles fonctionnalités de contrôle de version basées sur la nouvelle classe WorkflowIdentity. WorkflowIdentity fournit aux auteurs d'applications de workflow un mécanisme pour mapper une instance de workflow persistante avec sa définition.
Les développeurs qui utilisent l'hébergement WorkflowApplication peuvent utiliser WorkflowIdentity pour permettre l'hébergement de plusieurs versions d'un workflow côte à côte. Les instances de workflow persistantes peuvent être chargées à l'aide de la nouvelle classe WorkflowApplicationInstance, puis DefinitionIdentity peut être utilisé par l'hôte pour fournir la version appropriée de la définition de workflow en instanciant WorkflowApplication. Pour plus d’informations, consultez Utilisation du workflowIdentity et du versioning et Procédure : héberger plusieurs versions d’un workflow côte à côte.
WorkflowServiceHost est maintenant un hôte multi-version. Lorsqu'une nouvelle version d'un service de workflow est déployée, les nouvelles instances sont créées à l'aide du nouveau service, mais les instances existantes s'exécutent à l'aide de la version antérieure. Pour plus d’informations, consultez Versioning côte à côte dans WorkflowServiceHost.
Cette rubrique présente la mise à jour dynamique qui fournit un mécanisme pour mettre à jour la définition d'une instance persistante de workflow. Pour plus d’informations, consultez Mise à jour dynamique et Procédure : mettre à jour la définition d’une instance de workflow en cours d’exécution.
Le script de base de données SqlWorkflowInstanceStoreSchemaUpgrade.sql est fourni pour mettre à niveau les bases de données de persistance créées à l’aide de scripts de base de données .NET Framework 4. Ce script met à jour les bases de données de persistance .NET Framework 4 pour prendre en charge les nouvelles fonctions de versioning introduites dans .NET Framework 4.5. Des valeurs de versioning par défaut sont attribuées à toutes les instances persistantes de workflow dans la base de données et ces instances peuvent ensuite participer côte à côte à l'exécution et à la mise à jour dynamique. Pour plus d’informations, consultez Mise à niveau des bases de données de persistance .NET Framework 4 pour prendre en charge le versioning de workflow.
Activités
La bibliothèque d'activités intégrée contient de nouvelles activités et de nouvelles fonctionnalités pour les activités existantes.
NoPersistScope
NoPersistScope est une nouvelle activité de conteneur qui empêche la persistance d’un workflow lorsque des activités enfants de NoPersistScope sont en cours d’exécution. Cela s'avère utile dans les scénarios où il n'est pas nécessaire que le workflow soit rendu persistant, par exemple lorsque le workflow utilise des ressources propres à l'ordinateur telles que les handles de fichiers, ou pendant les transactions de bases de données. Auparavant, pour empêcher la persistance de se produire pendant l'exécution d'une activité, un NativeActivity personnalisé utilisant un utilisaitNoPersistHandle était nécessaire.
Nouvelles fonctions d'organigramme
Les organigrammes sont mis à jour pour le .NET Framework 4.5 et disposent des nouvelles fonctionnalités suivantes :
La propriété
DisplayName
d'une activité FlowSwitch<T> ou FlowDecision est modifiable. Cela laisse le concepteur d'activités afficher davantage d'informations sur l'objectif de l'activité.Les organigrammes ont une nouvelle propriété appelée ValidateUnconnectedNodes ; la valeur par défaut de cette propriété est
False
. Si cette propriété a la valeurTrue
, les nœuds déconnectés d’organigramme génèreront des erreurs de validation.
Prise en charge de la confiance partielle
Les workflows dans .NET Framework 4 nécessitaient un domaine d'application bénéficiant d’un niveau de confiance total. Dans le .NET Framework 4.5, les workflows peuvent s’exécuter dans un environnement de confiance partielle. Dans un environnement de confiance partielle, des composants tiers peuvent être utilisés sans leur octroyer un accès total aux ressources de l'hôte. Les problèmes liés à l'exécution des workflows dans un environnement de confiance partielle sont les suivants :
L'utilisation de composants hérités (comprenant des règles) contenus dans l'activité Interop n'est pas prise en charge dans un environnement de confiance partielle.
L'exécution de workflows dans un environnement de confiance partielle dans WorkflowServiceHost n'est pas prise en charge.
Les exceptions de persistance dans un scénario de confiance partielle sont une menace potentielle à la sécurité. Pour désactiver la persistance des exceptions, une extension de type ExceptionPersistenceExtension doit être ajoutée au projet pour supprimer les exceptions persistantes. L'exemple de code suivant illustre l'implémentation de ce type.
public class ExceptionPersistenceExtension { public ExceptionPersistenceExtension() { this.PersistExceptions = false; } public bool PersistExceptions { get; set; } }
Si les exceptions ne doivent pas être sérialisées, assurez-vous qu'elles sont utilisées dans un NoPersistScope.
Les auteurs d'activités doivent substituer CacheMetadata pour éviter que le runtime du workflow exécute automatiquement la réflexion sur le type. Les arguments et les activités enfants doivent être non-null, et Bind doit être appelé explicitement. Pour plus d’informations sur la substitution de CacheMetadata, consultez Exposition de données avec CacheMetadata. De plus, les instances des arguments qui sont de type
internal
ou privé doivent être créées explicitement dans CacheMetadata pour éviter d’être créées par réflexion.Les types n'utilisent pas ISerializable ou SerializableAttribute pour la sérialisation ; les types qui doivent être sérialisés doivent prendre en charge DataContractSerializer.
Les expressions qui utilisent LambdaValue<TResult> nécessitent RestrictedMemberAccess et, par conséquent, ne fonctionnent pas dans un scénario de confiance partielle. Les workflows qui utilisent LambdaValue<TResult> doivent remplacer les expressions qui ont des activités qui dérivent de CodeActivity<TResult>. .
Les expressions ne peuvent pas être compilées à l'aide de TextExpressionCompiler ou du compilateur hébergé Visual Basic, mais les expressions précédemment compilées peuvent être exécutées.
Un assembly unique qui utilise la transparence de niveau 2 ne peut pas être utilisé dans .NET Framework 4, .dans NET Framework 4.6.1 en confiance totale et dans .NET Framework 4.6.1 en confiance partielle.
Nouvelles fonctions du concepteur
Recherche du concepteur
Pour rendre les plus grands workflows plus pratiques, les workflows peuvent maintenant être trouvés par mot clé. Cette fonctionnalité est disponible uniquement dans Visual Studio ; elle n’est pas disponible dans un concepteur réhébergé. Il existe deux types de recherche disponibles :
Recherche rapide, initialisée avec Ctrl+F ou Édition, Rechercher et remplacer, Recherche rapide.
Rechercher dans les fichiers, initialisé avec Ctrl+Maj+F ou Édition, Rechercher et remplacer, Rechercher dans les fichiers.
Notez que Remplacer n'est pas pris en charge.
Recherche rapide
Les mots clés trouvés dans les workflows correspondent aux éléments de concepteur suivants :
Propriétés des objets Activity, des objets FlowNode, des objets State, des objets Transition, et d'autres éléments de contrôle de flux personnalisés.
Variables
Arguments
Expressions
La recherche rapide est exécutée sur l'arborescence ModelItem du concepteur. La recherche rapide n'ajoutera pas d'espaces de noms importés dans la définition de workflow.
Rechercher dans les fichiers
Les mots clés trouvés dans les workflows correspondent au contenu réel des fichiers de workflow. Les résultats de la recherche sont affichés dans le volet d'affichage des résultats de recherche de Visual Studio. Double-cliquez sur l'élément de résultat pour accéder à l'activité qui contient la correspondance dans le concepteur de workflow.
Supprimer l’élément de menu contextuel dans le concepteur de variable et d’argument
Dans .NET Framework 4, les variables et les arguments ne pouvaient être supprimés dans le concepteur qu’en utilisant le clavier. À partir de .NET Framework 4.5, les variables et les arguments peuvent être supprimés à l’aide du menu contextuel.
La capture d’écran suivante indique le menu contextuel du concepteur de variable et d’argument.
Encadrement automatique avec séquence
Étant donné qu'un workflow ou certaines activités de conteneur (telles que NoPersistScope) peuvent uniquement contenir une seule activité de corps, l'ajout d'une deuxième activité exigeait que le développeur supprime la première activité, ajoute une activité Sequence, puis ajoute les deux activités à l'activité de séquence. À partir de .NET Framework 4.5, lors de l’ajout d’une deuxième activité sur l’aire du concepteur, un activité Sequence
est créée automatiquement pour encapsuler les deux activités.
La capture d'écran suivante affiche une activité WriteLine
avec le Body
d'un NoPersistScope
.
La capture d’écran suivante montre l’activité Sequence
créée automatiquement dans le Body
lorsqu’un second WriteLine
est déposé sous le premier.
Mode Panoramique
Pour naviguer plus facilement dans un grand workflow dans le concepteur, le mode panoramiques peut être activé, ce qui permet au développeur de cliquer sur la partie visible du workflow et de la faire glisser, plutôt que d'utiliser les barres de défilement. Le bouton pour activer le mode panoramiques se trouve dans le coin inférieur droit du concepteur.
La capture d'écran suivante indique le bouton de panoramique qui se trouve dans le coin inférieur droit du concepteur de workflow.
Le bouton central de la souris ou la barre d'espace peut également être utilisé pour appliquer un panoramique au concepteur de workflow.
Multisélection
Plusieurs activités peuvent être sélectionnées en même temps, en faisant glisser un rectangle autour d'elles (lorsque le mode panoramique n'est pas activé), ou en maintenant la touche Ctrl enfoncée et en cliquant sur les activités souhaitées une à une.
Il est également possible de glisser-déplacer plusieurs activités sélectionnées et de les utiliser dans une interaction à l'aide du menu contextuel.
Mode Plan des éléments de workflow
Afin de simplifier la navigation dans les workflows hiérarchiques, les composants d’un workflow s’affichent dans un mode Plan de style arborescent. Le mode Plan est affiché dans la vue Structure du document. Pour ouvrir cette vue dans le menu principal, sélectionnez Affichage, Autres fenêtres, Structure du document, ou appuyez sur Ctrl W,U. Cliquer sur un nœud en mode Plan permet d'accéder à l'activité correspondante dans le Concepteur de workflow, et le mode Plan est mis à jour pour afficher les activités qui sont sélectionnées dans le concepteur.
La capture d’écran suivante du workflow terminé du Didacticiel Prise en main montre le mode Plan avec un workflow séquentiel.
Expressions C#
Avant .NET Framework 4.5, toutes les expressions de workflow ne pouvaient être écrites que dans Visual Basic. Dans .NET Framework 4.5, les expressions Visual Basic sont uniquement utilisées pour les projets créés à l’aide de Visual Basic. Les projets Visual C# utilisent C# pour les expressions. Un éditeur d'expressions C# fonctionnel est fourni, qui a des fonctions telles que la mise en surbrillance de la grammaire et IntelliSense. Les projets de workflow C# créés dans les versions antérieures qui utilisent des expressions Visual Basic continueront à fonctionner.
Les expressions C# sont validées au moment du design. Les erreurs dans les expressions C# sont marquées avec un soulignement ondulé rouge.
Pour plus d’informations sur les expressions C#, consultez Expressions C#.
Meilleur contrôle de la visibilité des éléments d'en-tête et de la barre de shell
Dans un concepteur réhébergé, certains des contrôles d'interface utilisateur standard peuvent ne pas avoir de signification pour un workflow donné, et peuvent être désactivés. Dans .NET Framework 4, cette personnalisation est prise en charge uniquement par la barre de shell en bas du concepteur. Dans .NET Framework 4.5, la visibilité des éléments d’en-tête de shell en haut du concepteur peut être ajustée en ajustant WorkflowShellHeaderItemsVisibility sur la valeur ShellHeaderItemsVisibility appropriée.
Connexion automatique et insertion automatique dans les workflows Organigramme et Machine à états
Dans .NET Framework 4, les connexions entre les nœuds d’un workflow Organigramme devaient être ajoutées manuellement. Dans .NET Framework 4.5, les nœuds Organigramme et Machine à états ont des points de connexion automatique qui sont visibles lorsqu’une activité est déplacée de la boîte à outils vers l’aire du concepteur. Le dépôt d’une activité sur un de ces points ajoute automatiquement l’activité avec la connexion nécessaire.
La capture d'écran suivante montre les points d'attachement qui sont visibles lorsqu'une activité est déplacée depuis la boîte à outils.
Les activités peuvent également être déplacées sur les connexions entre des nœuds d'organigramme et des états de façon à insérer automatiquement le nœud entre deux autres nœuds. La capture d’écran suivante montre la ligne de connexion en surbrillance où les activités peuvent être glissées-déposées depuis la boîte à outils.
Annotations du concepteur
Pour faciliter le développement de plus grands workflows, le concepteur prend désormais en charge l'ajout d'annotations pour faciliter le suivi du processus de création. Une annotation peut être ajoutée aux activités, états, nœuds d’organigramme, variables et arguments. La capture d'écran suivante montre le menu contextuel utilisé pour ajouter des annotations au concepteur.
États de débogage
Dans le .NET Framework 4, les éléments autres que des activités ne prennent pas en charge les points d’arrêt du débogage étant donné qu’ils n’étaient pas des unités d’exécution. Cette version fournit un mécanisme pour ajouter des points d'arrêt aux objets State. Lorsqu'un point d'arrêt est défini sur un State, l'exécution s'arrête lorsque l'état subit une transition, avant que ses activités d'entrée ou déclencheurs ne soient planifiés.
Définir et consommer des objets ActivityDelegate dans le concepteur
Les activités dans .NET Framework 4 utilisaient des objets ActivityDelegate pour exposer des points d’exécution où d’autres parties du workflow peuvent interagir avec l’exécution d’un workflow, mais l’utilisation de ces points d’exécution nécessite généralement du code. Dans cette version finale, les développeurs peuvent définir et utiliser des délégués d'activité à l'aide du concepteur de workflow. Pour plus d’informations, consultez Guide pratique pour définir et utiliser des délégués d’activité dans le Concepteur de flux de travail.
Validation au moment de la génération
Dans .NET Framework 4, les erreurs de validation de workflow n’étaient pas été comptées comme des erreurs de build pendant la génération d’un projet de workflow. Cela signifiait que la génération d’un projet de workflow pouvait réussir même lorsqu’il existait des erreurs de validation de workflow. Dans .NET Framework 4.5, les erreurs de validation de flux de travail provoquent l’échec de la génération.
Validation d'arrière-plan au moment du design
Dans .NET Framework 4, les workflows étaient validés en tant que processus de premier plan, ce qui pouvait éventuellement bloquer l’interface utilisateur pendant les processus de validation complexes ou longs. La validation de workflow a lieu à présent sur un thread d'arrière-plan, afin que l'interface utilisateur ne soit pas bloquée.
État d'affichage dans un emplacement distinct des fichiers XAML
Dans .NET Framework 4, les informations d’état d’affichage pour un workflow sont stockées dans le fichier XAML en différents emplacements. Cela n'est pas pratique pour les développeurs qui souhaitent lire le XAML directement, ou écrire du code pour supprimer les informations d'état d'affichage. Dans .NET Framework 4.5, les informations d’état d’affichage dans le fichier XAML sont sérialisées en tant qu’élément distinct dans le fichier XAML. Les développeurs peuvent facilement rechercher et modifier des informations d’état d’affichage d’une activité, ou supprimer complètement l’état d’affichage.
Extensibilité des expressions
Dans le .NET Framework 4.5, nous fournissons une méthode permettant aux développeurs de créer leur propre expression et expérience de création d’expression qui peut être intégrée au concepteur de workflow.
Opter pour les fonctionnalités de workflow 4.5 dans le concepteur réhébergé
Pour conserver la compatibilité descendante, certaines nouvelles fonctionnalités incluses dans .NET Framework 4.5 ne sont pas activées par défaut dans le concepteur réhébergé. Il s'agit de garantir que les applications existantes qui utilisent le concepteur réhébergé ne sont pas interrompues par la mise à jour vers la version la plus récente. Pour activer les nouvelles fonctionnalités du concepteur réhébergé, affectez à TargetFrameworkName la valeur « .NET Framework 4.5 », ou définissez des membres de DesignerConfigurationService pour activer des fonctionnalités.
Nouveaux modèles de développement de workflow
Outre les modèles de développement d’organigramme et workflow séquentiel, cette mise en production inclut des workflows Machine à états, et les services de workflow Contrat en premier.
Workflows de machine à états
Les workflows de machine à états ont été introduits dans le cadre du .NET Framework 4, version 4.0.1 dans Microsoft .NET Framework 4 Platform Update 1. Cette mise à jour inclut plusieurs nouvelles classes et activités qui permettent aux développeurs de créer des workflow de machine à états. Ces classes et activités ont été mises à jour pour le .NET Framework 4.5. Les mises à jour comprennent :
Possibilité de définir des points d'arrêt sur des états
Possibilité de copier et coller des transitions dans le concepteur de workflow
Prise en charge du concepteur pour la création de transition de déclencheur partagée
Les activités utilisées pour créer des workflows Machine à états, notamment : StateMachine, State et Transition
La capture d’écran suivante montre le flux de travail de machine à états terminé à partir de l’étape Didacticiel Prise en mainGuide pratique pour créer un flux de travail de machine à états.
Pour plus d’informations sur la création de workflows Machine à états, consultez Flux de travail de machine à états.
Développement de workflow « contrat en premier »
L’outil de développement Contrat en premier permet au développeur de concevoir un contrat dans le code en premier, puis, en quelques clics dans Visual Studio, de générer automatiquement un modèle d’activité dans la boîte à outils représentant chaque opération. Ces activités sont ensuite utilisées pour créer un workflow qui implémente les opérations définies par le contrat. Le concepteur de workflow validera le service de workflow pour garantir que ces opérations sont implémentées et que la signature du workflow correspond à la signature du contrat. Le développeur peut également associer un service de workflow à une collection de contrats implémentés. Pour plus d’informations sur le développement de service de flux de travail de premier contrat, consultez Guide pratique pour créer un service de flux de travail qui utilise un contrat de service existant.