Ich versuche, einen WF4 (RC) Service dynamisch zu hosten. Ich habe eine Testlösung mit zwei Projekten. Die erste ist eine deklarative Workflow-Service-Bibliothek mit einer Root-Flowchart-Aktivität und einer einfachen benutzerdefinierten Code-Aktivität. Die Workflow-Servicebibliothek hängt nicht von anderen benutzerdefinierten Assemblys oder Referenzen ab. Die zweite ist meine Host-App, die in meiner Testlösung nur eine Konsolenanwendung ist.
In meiner Host-App versuche ich ActivityXamlServices zu verwenden, um den Xaml für den Workflow-Service in eine Aktivität zu laden, und dann WorkflowServiceHost zu verwenden, um eine Workflow-Instanz mit dieser Aktivität zu starten.
Sobald ich versuche, das WorkflowServiceHost-Objekt neu zu erstellen, bekomme ich diese Ausnahme ...
Kann keinen unbekannten Typ erstellen '{clr-namespace: DeclarativeServiceLibrary1} CodeActivity1'.
Wenn ich CodeActivity1 aus meinem Flowchart-Designer entferne, läuft alles gut. Wenn ich einen direkten Verweis auf das Workflow-Service-Projekt von meinem Host-Projekt hinzufüge und dann einen WorkflowServiceHost mit einer Instanz meiner Flowchart-Aktivität statt der aus Xaml erstellten Aktivität erstelle, funktioniert das auch.
Es scheint nicht so zu sein, meine CodeActivity aus irgendeinem Grund zu verwenden, wenn sie dynamisch geladen wird.
Hat jemand irgendwelche Ideen, warum ich meinen Workflow-Service nicht dynamisch erstellen kann?
Mein Code ist wie folgt ...
DeclarativeServiceLibrary1.Activity1.xaml ...
%Vor%DeclarativeServiceLibrary1.CodeActivity1.cs ...
%Vor%DeclarativeServiceLibrary1.Web.Config ...
%Vor%ConsoleApplication1.Program.cs ...
%Vor%Ich habe ein Post-Build-Ereignis in der delarativen Workflow-Service-Bibliothek, das die Assembly- und Xaml-Datei in den Ordner bin \ debug \ der Host-Konsolen-App kopiert.
Kurze Antwort - Xaml load kann die lokale (Standard) Assembly nicht ableiten, daher müssen Sie sie in XamlReaderSettings.LocalAssembly angeben.
Öffnen Sie den Quellcode der Aktivität. Ändern Sie "xmlns: local=" clr-namespace: DeclarativeServiceLibrary1 "in xmlns: local="CLR-Namespace: DeclarativeServiceLibrary1; Assembly = DeclarativeServiceLibrary1".
Sie deserialisieren die XAML-Datei direkt, verweisen jedoch auf einen Typ (CodeActivity1), der als CLR-Typ in die Assembly "DeclarativeServiceLibrary1" kompiliert wird. Die naheliegendste Antwort ist, dass die Assembly DeclarativeServiceLibrary1 der Konsolenanwendung zur Laufzeit nicht zur Verfügung steht. Stellen Sie sicher, dass diese Assembly in den Ordner kopiert wird, in dem Sie die Konsolenanwendung ausführen (\ bin \ debug), und prüfen Sie, ob dies einen Unterschied macht.
Die Quintessenz ist, dass, obwohl Sie die XAML-Datei direkt lesen, immer noch Zugriff auf alle Typen benötigt wird, auf die sie verweist.
Wenn ich mir Ihren Code anschaue, kann ich feststellen, dass Sie statt einer einfachen Aktivität einen WorkflowService geladen haben sollten. Es gibt grundsätzlich zwei Optionen, die Sie hier ausprobieren können:
Option 1: Laden Sie die Aktivität und hosten Sie sie in einem generierten Workflow-Service.
Sie können dies tun, indem Sie die Aktivität normal laden und das folgende Snippet verwenden, um es zu einer Workflow-Service-Instanz zu machen:
%Vor%Danach können Sie es im Workflow-Service-Host hosten.
Option 2: Laden Sie den Workflow-Service direkt
Die zweite Option unterscheidet sich nicht sehr von dem, was Sie jetzt haben. Statt die ActivityXamlServices-Klasse zu verwenden, müssen Sie jedoch die XamlServices-Klasse zum Laden des Workflowdiensts verwenden. Danach müssen Sie den Workflow-Service-Host mit den Einstellungen starten, die Sie in Ihrem Beispiel verwendet haben.
Tags und Links xaml workflow-foundation workflow-foundation-4