Teilen über


Neues in Windows Workflow Foundation in .NET Framework 4.5

Durch Windows Workflow Foundation (WF) in .NET Framework 4.5 werden zahlreiche neue Features wie neue Aktivitäten, Designerfunktionen und Modelle für die Workflowentwicklung eingeführt. Viele, aber nicht alle der neuen, in .NET Framework 4.5 eingeführten Workflowfunktionen werden im neu gehosteten Workflow-Designer unterstützt. Weitere Informationen zu den neuen unterstützten Features finden Sie unter Unterstützung für neue Workflow Foundation 4.5-Funktionen im neu gehosteten Workflow-Designer. Weitere Informationen zum Migrieren von .NET Framework 3.0- und .NET Framework 3.5-Workflowanwendungen zur Verwendung der neuesten Version finden Sie im Migrationsleitfaden. Dieser Artikel enthält eine Übersicht über die neuen Workflowfeatures, die in .NET Framework 4.5 eingeführt wurden.

Warnung

Die neuen, in .NET Framework 4.5 eingeführten Windows Workflow Foundation-Features sind nicht für Projekte verfügbar, die auf frühere Versionen des Frameworks ausgerichtet sind. Wenn ein für .NET Framework 4.5 konzipiertes Projekt auf eine frühere Version des Frameworks ausgerichtet wird, können verschiedene Probleme auftreten.

  • C#-Ausdrücke werden im Designer mit der Meldung Wert wurde in XAML festgelegt ersetzt.
  • Viele Erstellungsfehler einschließlich des folgenden Fehlers treten auf.

Das Dateiformat ist nicht mit dem aktuellen Zielframework kompatibel. Zum Konvertieren des Dateiformats müssen Sie die Datei explizit speichern. Diese Fehlermeldung wird nicht mehr angezeigt, wenn Sie die Datei speichern und erneut im Designer öffnen.

Workflowversionsverwaltung

In .NET Framework 4.5 wurden neue Versionsverwaltungsfeatures eingeführt, die auf der neuen Klasse WorkflowIdentity basieren. WorkflowIdentity bietet Anwendern von Workflowanwendungen einen Mechanismus, um ihrer Definition eine persistente Workflowinstanz zuzuordnen.

activities

Die integrierte Aktivitätsbibliothek enthält neue Aktivitäten und neue Funktionen für vorhandene Aktivitäten.

NoPersist-Bereich

NoPersistScope ist eine neue Containeraktivität, die verhindert, dass ein Workflow persistent gespeichert wird, wenn die untergeordneten Aktivitäten von NoPersistScope ausgeführt werden. Dies ist in Szenarien hilfreich, in denen die persistente Speicherung des Workflows nicht angebracht ist, beispielsweise, wenn der Workflow computerspezifische Ressourcen wie Dateihandles verwendet, oder im Verlauf von Datenbanktransaktionen. Um zu vermeiden, dass die Persistenz während der Ausführung einer Aktivität auftritt, war früher eine benutzerdefinierte NativeActivity erforderlich, die einen NoPersistHandle verwendete.

Neue Flussdiagrammfunktionen

Flussdiagramme wurden für .NET Framework 4.5 überarbeitet und verfügen über folgende neue Funktionen:

  • Die DisplayName-Eigenschaft einer FlowSwitch<T>-Aktivität oder FlowDecision-Aktivität ist bearbeitbar. Auf diese Weise kann der Aktivitäts-Designer mehr Informationen über den Zweck der Aktivität anzeigen.

  • Flussdiagramme weisen eine neue Eigenschaft auf, die ValidateUnconnectedNodes genannt wird. Der Standardwert für diese Eigenschaft ist False. Wenn diese Eigenschaft auf True festgelegt ist, führen nicht verbundene Flussdiagrammknoten zu Validierungsfehlern.

Unterstützung für teilweise Vertrauenswürdigkeit

Workflows in .NET Framework 4 benötigen eine voll vertrauenswürdige Anwendungsdomäne. In .NET Framework 4.5 können Workflows in einer teilweise vertrauenswürdigen Umgebung ausgeführt werden. In einer teilweise vertrauenswürdigen Umgebung können Komponenten von Drittanbietern eingesetzt werden, ohne ihnen vollen Zugriff auf die Ressourcen des Hosts zu gewähren. Mögliche Bedenken zum Ausführen von Workflows unter teilweiser Vertrauenswürdigkeit:

  1. Das Verwenden älterer, in der Interop-Aktivität enthaltener Komponenten (einschließlich Regeln) wird unter teilweiser Vertrauenswürdigkeit nicht unterstützt.

  2. Das Ausführen von Workflows unter teilweiser Vertrauenswürdigkeit in WorkflowServiceHost wird nicht unterstützt.

  3. Persistente Ausnahmen in einem teilweise vertrauenswürdigen Szenario stellen ein Sicherheitsrisiko dar. Um die Persistenz von Ausnahmen zu deaktivieren, muss dem Projekt eine Erweiterung des Typs ExceptionPersistenceExtension hinzugefügt werden. Im folgenden Codebeispiel wird die Implementierung dieses Typs veranschaulicht.

    public class ExceptionPersistenceExtension
    {
        public ExceptionPersistenceExtension()
        {
            this.PersistExceptions = false;
        }
        public bool PersistExceptions { get; set; }
    }
    

    Wenn Ausnahmen nicht serialisiert werden müssen, stellen Sie sicher, dass Ausnahmen in NoPersistScope verwendet werden.

  4. Aktivitätsautoren sollten CacheMetadata überschreiben, damit während der Workflowlaufzeit nicht automatisch eine Reflektion für den Typ ausgeführt wird. Argumente und untergeordnete Aktivitäten dürfen nicht NULL sein, und Bind muss explizit aufgerufen werden. Weitere Informationen zum Außerkraftsetzen von CacheMetadata finden Sie unter Verfügbarmachen von Daten mit CacheMetadata. Außerdem müssen Instanzen von Argumenten mit dem Typ internal oder private explizit in CacheMetadata erstellt werden, um eine Erstellung durch Reflexion zu vermeiden.

  5. Die Typen verwenden nicht ISerializable oder SerializableAttribute für die Serialisierung. Die zu serialisierenden Typen müssen DataContractSerializer unterstützen.

  6. Ausdrücke, die LambdaValue<TResult> verwenden, setzen RestrictedMemberAccess voraus und funktionieren deshalb nicht unter teilweiser Vertrauenswürdigkeit. Bei Workflows, die LambdaValue<TResult> verwenden, sollten diese Ausdrücke durch Aktivitäten ersetzt werden, die von CodeActivity<TResult> abgeleitet sind. .

  7. Ausdrücke können nicht mit TextExpressionCompiler oder dem von Visual Basic gehosteten Compiler für teilweise Vertrauenswürdigkeit kompiliert werden, zuvor kompilierte Ausdrücke können jedoch ausgeführt werden.

  8. Eine einzelne Assembly mit Transparenz der Ebene 2 kann in .NET Framework 4, in .NET Framework 4.6.1 mit voller Vertrauenswürdigkeit und in .NET Framework 4.6.1 mit teilweiser Vertrauenswürdigkeit nicht verwendet werden.

Neue Designer-Funktionen

Designer-Suche

Um größere Workflows überschaubarer zu halten, können sie jetzt nach Schlüsselwort durchsucht werden. Dieses Feature ist nur in Visual Studio, nicht aber in einem neu gehosteten Designer verfügbar. Es gibt zwei Arten von Suchen:

  • Schnellsuche: Wird entweder mit STRG+F oder unter Bearbeiten > Suchen und Ersetzen > Schnellsuche initiiert

  • In Dateien suchen: Wird entweder mit STRG+UMSCHALT+F oder unter Bearbeiten > Suchen und Ersetzen > In Dateien suchen initiiert

Beachten Sie, dass der Ersetzungsvorgang nicht unterstützt wird.

Schnellsuche

Schlüsselwörter, die in den Workflows gesucht werden, entsprechen den folgenden Designerelementen:

  • Eigenschaften von Activity-Objekten, FlowNode-Objekten, State-Objekten, Transition-Objekten und anderen benutzerdefinierten Flusssteuerungselementen.

  • Variablen

  • Argumente

  • Ausdrücke

Die Schnellsuche wird in der ModelItem-Struktur des Designers ausgeführt. Die Schnellsuche findet keine Namespaces, die in die Workflowdefinition importiert wurden.

Suchen in Dateien

Schlüsselwörter, die in den Workflows gesucht werden, stimmen mit dem tatsächlichen Inhalt der Workflowdateien überein. Die Suchergebnisse werden im Visual Studio-Ansichtsbereich Suchergebnisse angezeigt. Durch Doppelklicken auf das Ergebniselement navigieren Sie im Workflow-Designer zur Aktivität, in der die Übereinstimmung enthalten ist.

Löschen von Kontextmenüelementen im Variablen- und Argument-Designer

In .NET Framework 4 konnten Variablen und Argumente nur im Designer mithilfe der Tastatur gelöscht werden. Ab .NET Framework 4.5 können Variablen und Argumente mithilfe des Kontextmenüs gelöscht werden.

Das folgende Bildschirmfoto zeigt das Kontextmenü des Variablen- und Argument-Designers.

Kontextmenü des Variablen- und Argument-Designers

Automatisches Umschließen mit Sequenz

Da ein Workflow oder bestimmte Containeraktivitäten (z. B. NoPersistScope) nur eine einzelne Textkörperaktivität enthalten können, musste der Entwickler zum Hinzufügen einer zweiten Aktivität die erste Aktivität löschen, eine Sequence-Aktivität hinzufügen und der Sequenzaktivität dann beide Aktivitäten hinzufügen. Wenn der Designeroberfläche ab .NET Framework 4.5 eine zweite Aktivität hinzugefügt wird, wird automatisch eine Sequence-Aktivität erstellt, um beide Aktivitäten zu umschließen.

Die folgende Bildschirmaufnahme zeigt eine WriteLine-Aktivität in Body von NoPersistScope.

WriteLine-Aktivität im Textkörper einer NoPersistScope-Aktivität

Die folgende Bildschirmaufnahme zeigt die automatisch erstellte Sequence-Aktivität in Body, wenn eine zweite WriteLine-Komponente unterhalb der ersten abgelegt wird.

Eine automatisch erstellte Sequenz im Textkörper eines NoPersistScope-Elements

Schwenkmodus

Um in einem umfangreichen Workflow einfacher im Designer zu navigieren, kann der Schwenkmodus aktiviert werden, der es dem Entwickler ermöglicht, den sichtbaren Teil des Workflows durch Klicken und Ziehen zu verschieben, anstatt die Bildlaufleisten zu verwenden. Die Schaltfläche zum Aktivieren des Schwenkmodus befindet sich in der rechten unteren Ecke des Designers.

Das folgende Bildschirmfoto zeigt die Schaltfläche zum Schwenken, die sich in der unteren rechten Ecke des Workflow-Designers befindet.

Workflow-Designer mit hervorgehobener Schaltfläche „Schwenken“

Die mittlere Maustaste oder die LEERTASTE kann ebenfalls verwendet werden, um den Workflow-Designer zu schwenken.

Mehrfachauswahl

Mehrere Aktivitäten können gleichzeitig ausgewählt werden, indem Sie entweder ein Rechteck darum ziehen (wenn der Schwenkmodus nicht aktiviert ist), oder indem Sie die STRG-TASTE gedrückt halten und nacheinander auf die gewünschten Aktivitäten klicken.

Mehrere ausgewählte Aktivitäten können auch im Designer gezogen und abgelegt und über das Kontextmenü bearbeitet werden.

Gliederungsansicht der Workflowelemente

Um das Navigieren in hierarchischen Workflows zu erleichtern, werden die Komponenten eines Workflows in einer strukturähnlichen Gliederungsansicht angezeigt. Die Gliederung wird in der Ansicht Dokumentgliederung angezeigt. Navigieren Sie über die obere Menüleiste zu Ansicht > Weitere Fenster > Dokumentgliederung, oder drücken Sie STRG+W und anschließend U, um diese Ansicht zu öffnen. Wenn Sie auf einen Knoten in der Gliederungsansicht klicken, wechseln Sie automatisch zur entsprechenden Aktivität im Workflow-Designer, und die Gliederungsansicht wird aktualisiert, um die im Designer ausgewählten Aktivitäten anzuzeigen.

Der folgende Screenshot des abgeschlossenen Workflows aus dem Tutorial zu den ersten Schritten zeigt die Gliederungsansicht mit einem sequenziellen Workflow.

Screenshot: Gliederungsansicht mit einem sequenziellen Workflow in Visual Studio

C#-Ausdrücke

Vor .NET Framework 4.5 konnten alle Ausdrücke in Workflows nur in Visual Basic geschrieben werden. In .NET Framework 4.5 werden Visual Basic-Ausdrücke nur für Projekte verwendet, die mit Visual Basic erstellt wurden. Visual C#-Projekte verwenden jetzt die Programmiersprache C# für Ausdrücke. Ein voll funktionaler C#-Ausdrucks-Editor wird mit Funktionen wie IntelliSense und der Hervorhebung grammatikalischer Fehler bereitgestellt. Die in früheren Versionen erstellten C#-Workflowprojekte, die Visual Basic-Ausdrücke verwenden, sind weiterhin funktionsfähig.

C#-Ausdrücke werden zur Entwurfszeit validiert. Fehler in C#-Ausdrücken werden mit einer roten wellenförmigen Unterstreichung gekennzeichnet.

Weitere Informationen zu C#-Ausdrücken finden Sie hier.

Bessere Kontrolle über die Sichtbarkeit der Shellleiste und Headerelemente

In einem neu gehosteten Designer sind einige standardmäßigen Benutzeroberflächen-Steuerelemente für einen bestimmten Workflow möglicherweise bedeutungslos und deaktiviert. In .NET Framework 4 wird diese Anpassung nur von der Shellleiste im unteren Bereich des Designers unterstützt. In .NET Framework 4.5 kann die Sichtbarkeit der Shellheaderelemente am oberen Rand des Designers angepasst werden, indem WorkflowShellHeaderItemsVisibility auf den entsprechenden ShellHeaderItemsVisibility-Wert festgelegt wird.

Automatisches Verbinden und Einfügen in Flussdiagramm- und Zustandsautomatworkflows

In .NET Framework 4 mussten Verbindungen zwischen Knoten in einem Flussdiagramm-Workflow manuell hinzugefügt werden. In .NET Framework 4.5 weisen Flussdiagramm- und Zustandsautomatknoten Punkte für die automatische Verbindung auf, die sichtbar werden, wenn eine Aktivität aus der Toolbox auf die Designeroberfläche gezogen wird. Durch Ablegen einer Aktivität auf einem dieser Punkte wird die Aktivität automatisch zusammen mit der erforderlichen Verbindung hinzugefügt.

Das folgende Bildschirmfoto zeigt die Anfügepunkte, die sichtbar werden, wenn eine Aktivität aus der Toolbox gezogen wird.

Startknoten eines Flussdiagramms mit Punkten für die automatische Verbindung

Aktivitäten können auch auf Verbindungen zwischen Flussdiagrammknoten und -zuständen gezogen werden, um den Knoten automatisch zwischen zwei anderen Knoten einzufügen. Das folgende Bildschirmfoto zeigt die hervorgehobene Verbindungslinie, auf die Aktivitäten aus der Toolbox gezogen und abgelegt werden können.

AutoEinfügen-Handle zum Ablegen von Aktivitäten

Designer-Anmerkungen

Zur einfacheren Entwicklung größerer Workflows unterstützt der Designer jetzt das Hinzufügen von Anmerkungen, um den Entwurfsprozess nachzuverfolgen. Aktivitäten, Zustände, Flussdiagrammknoten, Variablen und Argumente können mit Anmerkungen versehen werden. Das folgende Bildschirmfoto zeigt das Kontextmenü, das verwendet wird, um dem Designer Anmerkungen hinzuzufügen.

Screenshot: Menü zum Hinzufügen von Anmerkungen

Debugzustände

In .NET Framework 4 wurden von aktivitätsfremden Elementen keine Debughaltepunkte unterstützt, da es sich bei ihnen nicht um Ausführungseinheiten handelte. Dieses Release stellt einen Mechanismus bereit, um State-Objekten Haltepunkte hinzuzufügen. Wenn ein Haltepunkt für State festgelegt wird, wird die Ausführung unterbrochen, wenn vor der Planung der Eintragsaktivitäten oder Trigger ein Zustandsübergang stattfindet.

Definieren und Nutzen von ActivityDelegate-Objekten im Designer

Aktivitäten in .NET Framework 4 verwendeten ActivityDelegate-Objekte, um Ausführungspunkte verfügbar zu machen, in denen andere Teile des Workflows mit der Ausführung eines Workflows interagieren konnten. Zur Verwendung dieser Ausführungspunkte war normalerweise jedoch eine beträchtliche Menge an Code erforderlich. In diesem Release können Entwickler die Aktivitätsdelegaten mit dem Workflow-Designer definieren und nutzen. Weitere Informationen finden Sie unter Vorgehensweise: Definieren und Verarbeiten von Aktivitätsdelegaten im Workflow-Designer.

Validierung zur Buildzeit

In .NET Framework 4 galten Workflowvalidierungsfehler während der Erstellung eines Workflowprojekts nicht als Buildfehler. Das bedeutete, dass das Erstellen eines Workflowprojekts erfolgreich gewesen sein konnte, obwohl Workflowvalidierungsfehler auftraten. In .NET Framework 4.5 bewirken Workflowvalidierungsfehler, dass die Erstellung fehlschlägt.

Hintergrundvalidierung zur Entwurfszeit

In .NET Framework 4 wurde die Workflowvalidierung als Vordergrundprozess ausgeführt, was bei komplexen oder zeitaufwendigen Validierungsprozessen zu einer Blockierung der Benutzeroberfläche führen konnte. Da die Workflowvalidierung nun in einem Hintergrundthread stattfindet, wird die Benutzeroberfläche nicht blockiert.

Der Ansichtszustand wird an einem separaten Ort in XAML-Dateien gespeichert

In .NET Framework 4 werden die Anzeigemodusinformationen für einen Workflow an vielen verschiedenen Orten in der XAML-Datei gespeichert. Dies ist für Entwickler, die XAML direkt lesen oder Code zum Entfernen von Ansichtszustandsinformationen schreiben möchten, ungünstig. In .NET Framework 4.5 werden die Anzeigemodusinformationen in der XAML-Datei als separates Element in der XAML-Datei serialisiert. Entwickler*innen können die Anzeigemodusinformationen einer Aktivität ganz einfach finden und bearbeiten oder den Anzeigemodus entfernen.

Erweiterbarkeit von Ausdrücken

In .NET Framework 4.5 haben Entwickler*innen die Möglichkeit, eigene Ausdrücke zu erstellen und eine Umgebung zum Erstellen von Ausdrücken zu nutzen, die als Plug-In für den Workflow-Designer verfügbar ist.

Opt-In für Workflow 4.5-Funktionen im neu gehosteten Designer

Zur Gewährleistung der Abwärtskompatibilität sind einige neue Features von .NET Framework 4.5 im neu gehosteten Designer standardmäßig nicht aktiviert. Dadurch wird sichergestellt, dass vorhandene Anwendungen, die den neu gehosteten Designer verwenden, nicht beeinträchtigt werden, indem ein Update auf die neueste Version ausgeführt wird. Um neue Funktionen im neu gehosteten Designer zu aktivieren, legen Sie entweder TargetFrameworkName auf „.NET Framework 4.5“ oder einzelne Member von DesignerConfigurationService fest, um einzelne Funktionen zu aktivieren.

Neue Modelle für die Workflowentwicklung

Zusätzlich zu den Entwicklungsmodellen für sequenzielle oder Flussdiagramm-Workflows umfasst dieses Release Zustandsautomatworkflows und Vertrag zuerst-Workflowdienste.

Zustandsautomatworkflows

Zustandsautomatworkflows wurden als Teil von .NET Framework 4 (Version 4.0.1) im Microsoft .NET Framework 4 Plattform Update 1 eingeführt. Dieses Update umfasste verschiedene neue Klassen und Aktivitäten, die es den Entwicklern ermöglichten, Zustandsautomatworkflows zu erstellen. Diese Klassen und Aktivitäten wurden für .NET Framework 4.5 aktualisiert. Updates umfassen:

  1. Festlegen von Haltepunkten für Zustände

  2. Kopieren und Einfügen von Übergängen im Workflow-Designer

  3. Designerunterstützung für das Erstellen von freigegebenen Triggerübergängen

  4. Aktivitäten, die zum Erstellen von Zustandsautomatworkflows verwendet werden, darunter: StateMachine, State und Transition

Der folgende Screenshot zeigt den abgeschlossenen Zustandsautomatworkflow aus dem Schritt Vorgehensweise: Erstellen eines Zustandsautomatworkflows des Tutorials zu den ersten Schritten.

Abbildung: Abgeschlossener Zustandsautomatworkflow

Weitere Informationen zum Erstellen von Zustandsautomatenworkflows finden Sie unter Zustandsautomatworkflows.

Vertrag zuerst-Workflowentwicklung

Das Entwicklungstool für vertragsbasierte Workflows ermöglicht es Entwickler*innen, einen Vertrag zuerst im Code zu entwerfen und dann in Visual Studio mit wenigen Klicks automatisch eine Aktivitätsvorlage in der Toolbox zu generieren, die die einzelnen Vorgänge darstellt. Diese Aktivitäten werden dann verwendet, um einen Workflow zu erstellen, der die vom Vertrag definierten Vorgänge implementiert. Der Workflow-Designer überprüft den Workflowdienst, um sicherzustellen, dass diese Vorgänge implementiert wurden und dass die Signatur des Workflows mit der Vertragssignatur übereinstimmt. Der Entwickler kann einen Workflowdienst auch einer Auflistung implementierter Verträge zuordnen. Weitere Informationen zur Entwicklung eines vertragsbasierten Workflowdiensts finden Sie unter Vorgehensweise: Erstellen eines Workflowdiensts, der einen vorhandenen Dienstvertrag nutzt.