Runtime: Portieren von Workflow Foundation auf .NET Core

cc: @terrajobst , @joshfree , @weshaggard

Wir müssen System.Xaml öffnen, bevor ernsthafte Portierungsversuche unternommen werden können.

Ich verstehe @jakesays .

Der Punkt ist, dass WF seine Workflow-Definitionen in C#-Klassen anstelle von XAML (vorerst) erstellen lassen kann und viele Leute nicht einmal die XAML-Darstellung davon verwenden. Später, wenn System.Xaml geöffnet wird, können wir auch den visuellen Designer und die XAML-Definitionen integrieren. Außerdem arbeiten wir an einer Workflow-Engine, die der WF-Nutzung/Implementierung strikt folgt, aber anstatt XAML als Basisspeicher für Workflow-Definitionen zu verwenden, haben wir sie auf Json für den Store basierend, was viele Möglichkeiten für neue Workflow-Designer eröffnet Plattformen (nicht nur VS oder die gehostete Designerkomponente für WPF/WForms) und haben mehrere Vorteile wie schnelleres Lesen/Schreiben, Einfachheit des Schemas, schnelleres Laden/Kompilieren und Laufzeitvorgänge. Es kann sogar verwendet werden, um Client-Workflows zu stärken, um beispielsweise Anwendungs-UI-Flows in Windows Phone/Store-Apps aufgrund seiner schlanken Laufzeit zu steuern.

Ich denke wirklich, dass WF eine WIRKLICH leistungsstarke Komponente auf der .Net-Plattform ist, aber für heutige Technologien ist XAML immer noch ein „Begrenzer“ davon, aber wenn wir es für eine Strategieentscheidung von MS beibehalten und auf CoreCLR portieren können.

Danke

@zhenlan kann über das aktuelle Denken rund um WF sprechen

@galvesribeiro Viele Leute verwenden XAML vielleicht nicht, aber viele tun es, und es wird in der Tat als Kernbestandteil von WF angesehen. Wir verwenden xaml ausgiebig, daher würde ich WF ohne xaml-Unterstützung kaum als lohnenswert ansehen.

Ich würde es vorziehen, wenn wir uns weiterhin dafür einsetzen, dass Microsoft System.Xaml öffnet.

Und die Verwendung von JSON als Ersatz ist einfach nicht im Geringsten ansprechend.

@galvesribeiro @jakesays Wir möchten wirklich gerne erfahren, wie sehr WF-Kunden daran interessiert sind, die .NET Core-Version von WF zu haben, daher ist es großartig, Feedback von der Community zu hören. Wenn es genug Nachfrage gibt, wird es für uns hilfreich sein, voranzukommen.

Wir befinden uns in einem frühen Stadium der Bewertung der Machbarkeit, Abhängigkeiten, Funktionsprioritäten usw. Daher wird es für uns sehr hilfreich sein zu erfahren, welche Szenarien Sie sich vorstellen, warum WF auf .NET Core (im Vergleich zu WF in vollem .NET) sein wird nützlich für Sie und welche WF-Funktionen Sie zuerst sehen möchten.

@galvesribeiro In Ihrem Szenario mit dem Erstellen von Workflows im Code und dem Speichern dieser Definitionen als JSON, was verwenden Sie (planen Sie?) für Ausdrücke? Verwenden Sie VB-Ausdrücke, C#-Ausdrücke oder haben Sie eigene Ausdrucksaktivitäten, die auf CodeActivity basieren, um mit Ausdrücken umzugehen?

Danke für die Eingabe.

@jakesays es ist in Ordnung für mich, XAML zu verwenden. Mir geht es nur um die Leistung...

@zhenlan Wir haben einen elektronischen Zahlungsschalter, der täglich Milliarden von Kredit-/Debitkartentransaktionen für einige Banken hier in Brasilien und einige andere im Ausland verarbeitet. Wir waren vollständig vor Ort und aktualisieren die Technologie, um sie vollständig in die Cloud zu integrieren und als Dienst auf Azure anzubieten. Wir haben ein Enterprise Agreement abgeschlossen, um alles zu erkunden, was wir hier von Azure als Multi-Tenant-Plattform für die Zahlungsabwicklung für unsere Kunden benötigen.

Wir untersuchen die Verwendung von NanoServer für und CoreCLR, damit wir den Platzbedarf, die Angriffsfläche und den Wartungsaufwand für die Ausführung unserer Dienste reduzieren können, und wir haben festgestellt, dass CoreCLR (zumindest) System.Activities noch nicht portiert hat. Mit anderen Worten, keine Workflow Foundation.

Unsere zentrale Verarbeitungs-Engine ist eine Business-Engine, die auf Top-WF aufbaut und mehr als 40 benutzerdefinierte Aktivitäten enthält, die sich auf unser Geschäft konzentrieren. Diese Engine verarbeitet den Transaktionsprozess/die Transaktionsregeln in Echtzeit, um die Transaktionsgenehmigung zu erhalten. Wir müssen es über die Nachfrage skalieren, und das ist mit der aktuellen Implementierung von WF in der Cloud, sagen wir mal, nicht machbar.

Die Portierung auf .net Core, anstatt es auf dem .net full (Serverprofil) zu belassen, eröffnet die Möglichkeit, Client-Workflows auszuführen, das ist etwas, das wir in unserem Geschäft wirklich vermissen. Diese Client-Workflows können Menschen dazu bringen, Client-Geschäftslogik deklarativ zu entwickeln, in einer Weise, wie kleine Geräte wie Smartphones, Wearables, IoT und unsere Zahlungsterminals einige Entscheidungen treffen können, ohne echten sich wiederholenden Code zu schreiben.

Da wir keine Bemühungen auf WF für .net Core gefunden haben, und selbst es seit Jahren nicht geändert wurde und immer noch auf XAML angewiesen ist, haben wir uns entschieden, unsere eigene Workflow-Engine zu starten, die sich genau so verhält wie WF. Gleiches Aktivitätsmodell, gleicher Codestil usw., aber viel leichter und basierend auf Json als Definitionsspeicher. Dies ermöglicht es Geräten mit geringer Rechenleistung, die Workflows ohne den Aufwand für den Umgang mit XAML/XML zu verarbeiten, sodass der größte Teil unseres für WF erstellten Codes ohne viele Änderungen an Json-Definitionen anstelle von XAML-basierten Workflows funktioniert. Außerdem eröffnet die Abkehr von XAML die Möglichkeit für neue Workflow-Designer ... Nicht an Visual Studio und an WPF-Anwendungen gebunden, um den VS-Designer neu zu hosten.

Was ich vorzuschlagen versuche, ist eine dieser Optionen:

1. Portieren Sie WF (mit XAML) unverändert zu .Net Core. Diese Optionen werden viel mehr Zeit in Anspruch nehmen, da WF heute vom Serverprofil von .Net abhängt, wodurch wir viel Zeit damit verbringen werden, es zu entkoppeln, damit es mit .Net Core funktioniert.
2. Port WF, der es auf .Net Core umschreibt. Auf diese Weise können wir die Kernkonzepte erhalten und uns auf das Design einer leichteren Engine konzentrieren, die auf Servern, Clients, IoTs oder was auch immer benötigt wird, wobei die Designprinzipien und Funktionen beibehalten werden, die derzeit in WF implementiert sind. Auf diese Weise machen wir die Migration von XAML zu (zum Beispiel) Json-basierten Workflow-Definitionen zu einem wirklich geringen Aufwand und reibungslosen Prozess. Alle aktuellen Aktivitäten müssen auf das neue Modell portiert werden.

Ich fordere Sie nicht auf, ein Team aufzubauen oder sich für ein neues Produkt zu engagieren. Die Community kann dies so tun, wie sie es für ASP.Net und Entity Framework tut. Machen Sie es zu einem externen und Hilfsgerüst, das nicht in den Kern eingebettet ist.

Danke

@jimcarley Die Ausdrücke würden genauso kompiliert wie heute in XAML. In einem unserer Workflows haben wir dies (es kann auch ein VBValue sein, habe gerade ein Beispiel bekommen):
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

Die Ausdrücke in XAML geben heute meistens einen booleschen Wert zurück oder weisen einer Variablen einen Wert zu, sodass dies auf die gleiche Weise gespeichert würde wie heute in XAML, aber in Json, und es könnte nach denselben Ideen kompiliert werden heute.

Wenn Sie sich Azure Resource Manager (ARM) ansehen, haben sie das bereits getan! Sie haben die Ressourcenbereitstellung als Json-Vorlage vorgenommen, die Abhängigkeiten und einen Fluss aufweist, und die Variablen können als Ausdrücke aufgerufen werden. Schau dir das an:

"Variablen": {
"location": "[resourceGroup().location]",
"usernameAndPassword": "[concat('parameters('username'), ':', parameters('password'))]",
"authorizationHeader": "[concat('Basic', base64(variables('usernameAndPassword')))]"
}

Ok, sie verwenden JavaScript-Funktionen, aber das Prinzip ist das gleiche. Sie haben eine $schema-Variable über der Vorlage, die die Dokumentstruktur leitet, Schritte im Bereitstellungsprozess, die wir als Aktivitäten ausführen können. Das Design ist dem WF ziemlich ähnlich, aber diese DSL konzentriert sich auf die Ressourcengruppenbereitstellung. Wir können es allgemeiner machen und Aktivitäten genauso verwenden, wie sie es in der aktuellen WF-Implementierung tun.

Wenn ihr entscheidet, dass es einen Versuch wert ist, können wir damit beginnen, eine Dokumentation zu einem anderen Thema zu zeichnen, das die Architektur des "neuen WF" leiten wird. Wenn es so verrückt klingt und außerhalb Ihrer Pläne liegt, lassen Sie es mich wissen, wir werden es trotzdem an unserer Seite entwickeln, um .net Core zu unterstützen, und es später als Nuget für Leute veröffentlichen. Ich versuche nur, dieses wunderbare Framework mit den aktuellen (kommenden) Technologien auf den neuesten Stand zu bringen. Dies ist wirklich eine geschäftliche Notwendigkeit für uns. Wir sind stark von WF abhängig, aber wenn es nicht schneller wird und von CoreCLR nicht unterstützt wird, müssen wir mit der Vorbereitung dieses neuen Frameworks beginnen, damit wir, wenn NanoServer + CoreCLR RTM sind, darauf umsteigen können.

Bitte lassen Sie mich wissen, wenn Sie Fragen haben.

Danke

PS: Ich bin jeden Tag auf den gitter-Kanälen, wenn Sie einen Chat brauchen.

@galvesribeiro Sie verwenden also den TextExpressionCompiler, um die Ausdrücke zu kompilieren, nachdem Sie das Aktivitätsobjekt aus der in JSON gespeicherten Workflowdefinition erstellt haben. Richtig?

@jimcarley Wir haben noch keinen Ausdrucks-Compiler, der funktioniert. Wir entwerfen es immer noch nach den gleichen Prinzipien von TextExpressionCompiler, aber ja, es sieht nach dem gleichen Konzept aus. Aktuelle Implementierungen scheinen noch an System.XAML gebunden zu sein. Da es nicht geöffnet ist, kann ich nicht bestätigen, ob es (intern) genauso funktioniert wie TextExpressionCompiler, aber ja, nachdem die Aktivität geladen wurde, sollten wir die Ausdrücke auswerten/kompilieren (falls nicht bereits in einem Cache) und ein Expression-Objekt verfügbar machen darauf, von den Verbrauchern der Aktivität bewertet zu werden (falls erforderlich).

Letztes Jahr habe ich einige Arbeiten auf der Ausdrucksseite durchgeführt, um die Unterstützung von C#-Ausdrücken in selbst gehosteten WF-Designern zu aktivieren. Es basierte auf Teilen von nrefactory und roslyn. Kann ich mal ausgraben falls es jemanden interessiert.

@galvesribeiro Nachdem ich mehr über Ihren Json-Ansatz nachgedacht habe, denke ich, dass es am Ende wirklich keine Rolle für die Neuentwicklung spielen würde. Wenn MS die XAML-Unterstützung nicht öffnet, funktioniert dies möglicherweise.

@zhenlan Ich stimme @galvesribeiro darin zu, dass wir nicht unbedingt nach MS suchen, um ein Team zu bilden, um WF zu portieren. Dies ist definitiv etwas, was die Community mit der Anleitung Ihres Teams usw. tun könnte.

@jakesays Ich stimme dir zu, dass der Speicher eigentlich keine Rolle spielt, wenn wir wieder WF für Coreclr erstellen.

Der Punkt ist, warum weiterhin XML anstelle von Json verwenden, da wir viele Tests im Internet haben, die die (De-)Serialisierungsleistung von beiden vergleichen, und json weitaus schneller ist und weniger Ressourcen verbraucht als es? (Zum Beispiel ein Vergleich von Newtonsofts Json.Net mit normaler XML-Serializer) Wenn WF auf einem Clientgerät mit geringem Platzbedarf (irgendein IoT) laufen würde, ist jedes Speicherbyte wichtig.

Außerdem ist es mit json viel einfacher, sofort neue webbasierte WF-Designer zu erhalten. Die Kompilierung und Ausführung von Ausdrücken ist nicht schwer zu implementieren. Es ist ungefähr ein Parser der Zeichenfolge, um das Ausdrucksobjekt zu erstellen. Der schwierige Teil (imho) ist, Intellisense für die Typen zu bekommen, die beim Entwerfen des WF verwendet werden, aber ich bin mir ziemlich sicher, dass Roselyn und Sprachdienste uns dabei helfen können und VS die Infrastruktur dafür hat.

@galvesribeiro Sie erwähnen, dass Sie bereits Ihre eigene Workflow-Engine mit JSON-basierter Workflow-Definition und Serialisierung erstellt haben. Wenn WF auf Core portiert würde, würden Sie es tatsächlich verwenden?

@dmetzgar Wir haben mit der Entwicklung und dem Testen als Proof-of-Concept begonnen, dass wir ein besseres Ergebnis in einem saubereren WF mit fast keinen Abhängigkeiten vom Framework erzielen können, was gut ist, um es auf Coreclr zum Laufen zu bringen. Wir haben es nicht fertig.

Ich würde gerne keine eigene Engine bauen und WF weiterhin verwenden, selbst wenn es auf XAML basiert, aber auf Coreclr portiert wird und wenn es beispielsweise dem gleichen Konzept von Coreclr-Versionen von EntityFramework und ASP.Net folgt (nicht abhängig von Serverbibliotheken und läuft überall).

Der Punkt ist, wenn es immer noch von XAML und dem Serverprofil abhängt, wird es weiterhin langsam sein (zu viele Ressourcen erfordern), auf die Auswahlmöglichkeiten des Designers beschränkt sein usw.

Mein Vorschlag ist, es mit Json auf coreclr zu portieren und viele Abhängigkeiten zu entfernen, die es heute hat, sodass der Benutzer es überall ausführen kann, wo er möchte, genauso wie Sie ASP.Net vNext auf einem IoT ARM-Gerät ausführen können (bald als ARM-Unterstützung fertig!) und keine Angst vor Abhängigkeiten und hohem Ressourcenverbrauch.

Alle unsere heutigen Workflows werden mit der aktuellen Version erstellt, von denen einige mit reinem Code und einige mit XAML geschrieben wurden, aber in beiden Fällen haben wir immer noch Abhängigkeiten.

IMHO, Portieren Sie es so wie es ist auf Coreclr, bringt nicht so viele Vorteile, es sei denn, jemand kommt mit einer super neuen, leichten Engine für XAML/XML-Parsing/Rendering sowohl für die Laufzeit als auch für die Entwurfszeit. Aber wenn ihr euch entscheidet, so zu portieren, wie es ist, werden wir es trotzdem weiter verwenden, da es meine XAML-Workflows (hoffentlich) von Tag 0 an funktionieren lässt, auch wenn ich weiß, dass es keine praktischen Vorteile bringen wird ...

Auch hier kann ich (wahrscheinlich @jakesays und andere WF-Benutzer) bei diesem Port auf beide Arten (XAML oder JSON) helfen, unabhängig davon, wie Sie sich entscheiden. Ich möchte nur sicherstellen, dass dieser Port nicht nur kopiert, eingefügt und repariert wird, damit er funktioniert, sondern dass er wirklich Vorteile für Leute bringt, die ihn verwenden, indem er der gleichen Idee von coreclr folgt und überall ohne Probleme ausgeführt werden kann.

Danke

@galvesribeiro Ich stimme zu, dass XAML zu eng in WF integriert ist. Um auf Dharmas ursprüngliches Buch über Arbeitsabläufe zurückzukommen, hatte er ein Beispiel, das einen Arbeitsablauf aus Visio erstellte. Zumindest mit der Portierung auf den Kern können wir es aufteilen, sodass die Laufzeit von XAML getrennt ist. Dadurch können wir mit oder ohne Portierung des XAML-Teams zum Core fortfahren, und wir können die XAML-Workflowunterstützung später jederzeit als separates GitHub-Projekt/NuGet-Paket hinzufügen. Ich bin definitiv dafür, dass es möglich ist, Workflows in jedem Format zu definieren und zu erhalten. Danke, dieses Feedback ist hilfreich.

@dmetzgar Ich habe keine Zweifel, dass XAML eines Tages auf den Kern portiert wird ... Wenn .net Core auf Windows Phone oder einem Windows 10-Mobilgerät ausgeführt wird, wird dies irgendwann geschehen, und ich stimme Ihnen vollkommen zu, dass wir es bauen können einen neuen Kern, und fügen Sie später auch die Persistenz beider Definitionen und des Status des Workflows hinzu.

Was müssen wir also tun, um mit der Portierung zu beginnen? (Wir haben bereits die Beitragsvereinbarung unterzeichnet und haben andere NDAs als Unternehmen mit MS usw.)

Danke

@galvesribeiro Ich schätze die Begeisterung! So verlockend es auch ist, ein GitHub-Repository zu öffnen und mit dem Hacken zu beginnen, es sind einige Schritte erforderlich. Außerdem muss nicht nur System.Xaml herausgearbeitet werden. Es gibt andere Abhängigkeiten, die tief in WF verwurzelt sind, wie System.Transactions und einige gemeinsam genutzte Komponenten mit WCF. Wir untersuchen jeden von diesen.

Ich verstehe. Nun, ich will euch nicht drängen, ich mache mir nur Sorgen um die Zeit. Wir müssen jetzt eine Entscheidung treffen, ob wir selbst weiter bauen oder der Community hier beitreten und WF auf coreCLR portieren, damit es unseren Zeitplan für unser Produkt einhalten kann.

@dmetzgar Haben Sie darüber nachgedacht, die Teile, die jetzt Open Source sein können, auf https://github.com/Microsoft/referencesource zu veröffentlichen? Ich denke, das könnte wesentlich einfacher sein, als ein vollwertiges Open-Source-Projekt zu erstellen, das tatsächlich funktioniert.

Auf diese Weise können Sie sich Zeit für die richtige Version nehmen, und andere können in der Zwischenzeit ihre eigenen Teil-/benutzerdefinierten Versionen erstellen.

@svick WF-Komponenten in vollem .NET wurden bereits vor einiger Zeit auf Github Referencesource veröffentlicht. Beispielsweise finden Sie https://github.com/Microsoft/referencesource/tree/master/System.Activities

@zhenlan ja, das Problem dabei ist, dass einige Abhängigkeiten nicht "auflösbar" sind ... Ich kann das Verhalten einiger Klassen aufgrund ihrer Abhängigkeit von System.Xaml, das nicht öffentlich ist, nicht richtig sehen ...

Wir können es am Ende immer herausfinden, aber das bedeutet, dass wir nicht sicher wissen, ob wir den gleichen Weg gehen.

@dmetzgar System.Transaction ist etwas, das (noch?) Nicht offen ist, aber ich denke, wir können uns (vorerst) damit befassen. In Bezug auf WCF zeigt die Abhängigkeitsstruktur nur Aktivitäten und den Host für Arbeitsablaufdienste an. Nichts auf dem Kern (IIRC) ist abhängig von WCF ...

@galvesribeiro Die Situation mit System.Transactions ist komplexer. Es ist über die gesamte WF-Laufzeit verteilt und hängt stark von der dauerhaften Instanziierung ab, wo sich die Basisklassen für die Persistenz befinden. WCF und WF wurden um den .Net 4.0-Zeitrahmen in demselben Team zusammengeführt, sodass wir Dinge wie System.ServiceModel.Internals haben, die sowohl von WCF als auch von WF verwendet werden. .Net Core hat viele der großen Dinge portiert, aber es gibt viele, die fehlen. Das Umgehen fehlender Teile kann Designänderungen oder Neuschreiben von Features erfordern.

Keines dieser Probleme ist unüberwindbar, ich will den Aufwand nur nicht bagatellisieren. Das gilt für den Code und alles drumherum, wie das Einholen gesetzlicher Genehmigungen, Build-Umgebungen, Testen der Infrastruktur usw. Wir möchten auf jeden Fall, dass die Community hilft, und wir arbeiten darauf hin. Ob Sie Ihren eigenen Port schreiben oder auf den "offiziellen" warten sollten, hängt von Ihrem Zeitrahmen ab. Das Ausführen von Workflows auf einem Nano-Server ist eines unserer größten Szenarien, und ich würde gerne Ihre Hilfe dabei in Anspruch nehmen.

@dmetzgar Ich habe es verstanden, hatte immer eine gewisse Verzögerung, wenn eine Frage an PR oder Legal weitergeleitet werden musste, wenn ich auf Ihrer Seite war :)

Nun, wenn wir zumindest eine Vorstellung von einem Zeitrahmen haben, können wir uns vorbereiten und darauf warten. Ich hasse die Idee, etwas an der „falschen Stelle“ zu implementieren oder wenn irgendwo schon Anstrengungen unternommen werden, die wir gemeinsam besser machen können.

Bitte lassen Sie mich wissen, ob wir irgendetwas tun können oder ob Sie Neuigkeiten haben, oder pingen Sie mich an, wenn Sie Vorschläge zum Design/Port benötigen.

Danke

Sobald der Zeitrahmen klarer wird, werde ich Aktualisierungen in diesem Thread vornehmen. Ich würde gerne hören, an welchen anderen Szenarien die Leute interessiert sind. WF auf Nano ist derzeit das primäre Szenario, aber es wäre gut zu wissen, was andere tun.

Hallo Leute, neben XAML und JSON gibt es eine COOLE Art, Aktivitäten zu erstellen: Metaprogrammierung. Werfen Sie einen Blick auf mein experimentelles Projekt: Metah.W: A Workflow Metaprogramming Language (https://github.com/knat/Metah).

@jakesays Können Sie eine Anleitung zum Aktivieren der C#-Ausdrucksunterstützung in selbst gehostetem WF geben.

Bitte bewahren Sie Xaml auf. :) JSON-serialisierte Objekte wären auch interessant. Aber ich würde es vorziehen, Anbieter zu sehen, die irgendwie im Framework konfiguriert sind, um das bevorzugte Format auszuwählen.

@dmetzgar (und andere MSFT-Leute) gibt es Neuigkeiten zu diesem Thema?
Danke

Daran haben wir gearbeitet und große Fortschritte gemacht. XAML ist derzeit nicht in Core verfügbar, daher konzentrieren wir uns auf die Laufzeit. Wir arbeiten daran, uns für andere Serialisierer zu öffnen. Anstatt also zwischen JSON oder XAML zu wählen, würden wir es Ihnen vorziehen, Ihren eigenen Serializer mitzubringen. Es gibt noch mehr Compliance und rechtliche Dinge, die genehmigt werden müssen. Da nicht viele Kunden auf diesen Port drängen, hat er eine geringere Priorität.

@dmetzgar süß! Ich würde mehr als glücklich sein, dazu beizutragen, wie auch immer ich kann, wenn dies ein Kernprojekt wird ... sei es ein Web-Workflow-Designer usw. Scheint, als ob xaml kaum für das Definitionsformat da sein muss ... bin gespannt zu hören über diese Arbeit!

Hallo Leute, frohe Weihnachten und einen guten Rutsch ins neue Jahr!

Haben wir also ein Update zu diesem Port oder zumindest eine OSS-Version der aktuellen Arbeit, damit wir dabei helfen können?

Danke

@galvesribeiro Ich werde versuchen, die Situation so gut wie möglich zu erklären. In meinem Eifer, WF auf .NET Core zu portieren, habe ich es versäumt, die geschäftliche Seite dieser ganzen Sache zu berücksichtigen. WPF/XAML wird nicht auf .NET Core portiert, und das stellt einen erheblichen Teil von WF dar. Obwohl XAML für die Laufzeit nicht wesentlich ist, erstellen die meisten Kunden damit Workflows. Dies schränkt das Publikum ein, das WF auf Core nützlich finden würde. Eine der Befürchtungen ist, dass wir WF auf Core veröffentlichen und es nicht viel Beteiligung der Community gibt. Dies erhöht unsere Supportkosten und verbessert die Situation für die meisten WF-Kunden nicht. Es ist zwar cool zu sehen, dass WF auf einem Linux-Rechner läuft, aber es ist schwer zu beweisen, dass irgendjemand es tatsächlich benutzen würde.

Mir ist OmniXAML bekannt und wir konnten den Autor davon überzeugen, zu einer MIT-Lizenz zu wechseln. Mit etwas Investition könnten wir also möglicherweise XAML zum Laufen bringen. Es stellt sich jedoch die Frage, wie dies den bestehenden WF-Kunden zugute kommt. Wenn eines Tages ein großer Kunde wie SharePoint oder Dynamics kommt und sagt, dass er zu Nano wechselt, dann hätten wir einen überzeugenden Fall. Das ist jedoch alles strittig, wenn das .NET Framework-Team beschließt, ein Paket zu erstellen, das das vollständige Framework auf Nano ausführen kann.

Wenn es genug Interesse in der Community gäbe und jemand bereit wäre, sich für das Projekt einzusetzen, könnten wir versuchen, es so zu machen. So ähnlich wie Open Live Writer. Der knifflige Teil dabei ist, dass mein Team zwar so viel wie möglich dazu beitragen würde, diese Art von Projekt jedoch nicht von Microsoft unterstützt würde. Ich vermute, dass die meisten WF-Kunden WF hauptsächlich deshalb verwenden, weil Microsoft es unterstützt.

Ich denke, es ist wichtig hervorzuheben, dass .NET Core und das vollständige .NET Framework zwei verschiedene Produkte sind. Das .NET Framework stirbt keineswegs. Wir werden es weiterhin unterstützen, Funktionen hinzufügen usw. Es ist also nicht so, dass wir WF auf .NET Core portieren müssen, um es am Leben zu erhalten. WF on Core wäre im Grunde ein neues Produkt. Es ist schwierig, eine solide geschäftliche Begründung zu finden. Es könnte sogar eine Frage des Timings sein. Da immer mehr Unternehmen Nano-Server einführen, könnte es einen stärkeren Fall geben.

@dmetzgar Wie wäre es mit Portable.Xaml, könnte es eine Alternative sein? https://github.com/cwensley/Portable.Xaml Es wurde zur Verwendung durch den Autor des fantastischen Eto.Forms-Projekts für Eto extrahiert. Es ist MIT-lizenziert und (ebenso wie die Klassenbibliotheken, von denen es im Mono-Projekt abgeleitet ist).

@dmetzgar ,

Ich werde versuchen, die Situation so gut wie möglich zu erklären. In meinem Eifer, WF auf .NET Core zu portieren, habe ich es versäumt, die geschäftliche Seite dieser ganzen Sache zu berücksichtigen. WPF/XAML wird nicht auf .NET Core portiert, und das stellt einen erheblichen Teil von WF dar. Obwohl XAML für die Laufzeit nicht wesentlich ist, erstellen die meisten Kunden damit Workflows. Dies schränkt das Publikum ein, das WF auf Core nützlich finden würde. Eine der Befürchtungen ist, dass wir WF auf Core veröffentlichen und es nicht viel Beteiligung der Community gibt. Dies erhöht unsere Supportkosten und verbessert die Situation für die meisten WF-Kunden nicht. Es ist zwar cool zu sehen, dass WF auf einem Linux-Rechner läuft, aber es ist schwer zu beweisen, dass irgendjemand es tatsächlich benutzen würde.

Ich denke, die größte Motivation für aktuelle WF-Benutzer sind Nano Server und Micro Services und nicht Linux. Linux wird mehr Benutzer hinzufügen, ist aber nicht die eigentliche Motivation.

Es stellt sich jedoch die Frage, wie dies den bestehenden WF-Kunden zugute kommt.

Wir befinden uns in Wolkentagen. Denken Sie daran, „Cloud first, mobile first …“ und eine der großen Technologien, die wachsen, sind Container, Micro Services und ein großes Angebot von MS für alles, was Nano Server ist.

Wenn eines Tages ein großer Kunde wie SharePoint oder Dynamics kommt und sagt, dass er zu Nano wechselt, dann hätten wir einen überzeugenden Fall.

Selbst mit der größten Sharepoint- oder Dynamics-Bereitstellung der Welt werden wir niemals die gleiche Anzahl von Benutzern erreichen und ich würde sogar sagen, das gleiche Umsatzniveau wie mit Cloud-Technologie.

Das ist jedoch alles strittig, wenn das .NET Framework-Team beschließt, ein Paket zu erstellen, das das vollständige Framework auf Nano ausführen kann.

DNX besteht heute (bis zum RC1) nicht nur aus coreCLR. Es verfügt auch über das vollständige Framework (dnx451), sodass wir derzeit WF auf DNX verwenden können, und darum geht es hier nicht. Wir sprechen von coreCLR (dnxcore50)

Wenn es genug Interesse in der Community gäbe und jemand bereit wäre, sich für das Projekt einzusetzen, könnten wir versuchen, es so zu machen. So ähnlich wie Open Live Writer.

Ich würde es nicht mit dem vergleichen, was auf Open Live Writer gemacht wurde ... Ich denke, das ist mehr oder weniger das, was mit ASP.Net, MVC, Entity Framework gemacht wurde. Kern-„Produkte“ der .Net-Familie, die heute Open Source sind.

Der knifflige Teil dabei ist, dass mein Team zwar so viel wie möglich dazu beitragen würde, diese Art von Projekt jedoch nicht von Microsoft unterstützt würde. Ich vermute, dass die meisten WF-Kunden WF hauptsächlich deshalb verwenden, weil Microsoft es unterstützt.

In der Tat nutzen WF-Kunden MS-Supportverträge ... Besonders Dynamics- und Sharepoint-Kunden tun dies, aber es gibt viele Anwendungen außerhalb dieser Welt, die noch Unterstützung benötigen. Zu sagen, dass die Leute es nur wegen der Unterstützung verwenden und das OSS nicht unterstützt wird, ist fast dasselbe wie zu sagen, dass CoreCLR, EF, ASP.Net keine Unterstützung von MS haben wird. Obwohl diese Projekte jetzt OSS sind, werden sie von MS-Teams stark überwacht und moderiert.

Zum Beispiel habe ich als Benutzer im MS Orleans-Projekt angefangen. Es betreibt seit fast 7 Jahren alle Halo-Cloud-Dienste. Skype, Outlook und viele andere öffentliche/Cloud-Dienste von MS machen davon Gebrauch. Vor einigen Jahren wurde es von MS Research OSSed und wird jetzt von 343 Studios, einigen Leuten von MSR und einigen anderen von anderen Gruppen innerhalb von MS gepflegt, aber hauptsächlich von der Community gepflegt. Heute betrachte ich mich als einen aktiven Mitwirkenden an diesem Projekt und unterstütze dort neue Benutzer zusammen mit anderen MS- und Nicht-MS-Leuten. Wir haben sogar Leute, die ehemalige (wie ich) und Nicht-MS-Mitarbeiter im GH-Team für Orleans sind. Bedeutet das, dass wir keine Unterstützung haben? Nun, ich habe Orleans nicht gekauft, also bitte ich ausdrücklich um Unterstützung in meinen Verträgen mit MS für Orleans, aber ich kann das tun, indem ich auf .Net Framework oder ein anderes verwandtes Produkt abziele, also stimme ich Ihrer Aussage nicht wirklich zu.

Es ist schwierig, eine solide geschäftliche Begründung zu finden.
Ich stimme Ihnen zu, wenn Sie nur nach Sharepoint- und Dynamics-Kunden suchen.

Nun, wir haben, wie viele andere Unternehmen auf der ganzen Welt, große Enterprise Agreements (EA) mit Microsoft unter Verwendung der meisten variablen Produkte in diesen Verträgen. In unserem Fall verarbeiten wir täglich Millionen von Finanztransaktionen (Kredit-/Debitkarten), und jede stellt eine Instanz einer WF dar, die auf Orleans und innerhalb von Microsoft Azure ausgeführt wird. Ich weiß nicht, was für Sie groß wäre, um als geschäftliche Rechtfertigung zu fungieren.

Ich denke nur, dass der Kern (System.Activities) ohne XAML auf coreCLR portiert werden könnte und Designer bei Bedarf für XAML, Json, HTML, XML usw. erstellt werden könnten. Durch die Entkopplung dieser Abhängigkeit eröffnen sich weitere Möglichkeiten.

Wie ich am Anfang dieses Threads sagte, ist die schwerste Arbeit, die wir jetzt wollen, es OSSed zu bekommen und jemand (zumindest anfänglich) von MSFT verfügbar zu werden, um die PR zu überprüfen. Der gesunde Menschenverstand hier ist, WF neu zu schreiben und nicht nur zu kopieren und für coreCLR einzufügen, also erwarten wir große Beiträge dazu.

Wenn das nicht passieren wird, können wir dieses Problem meiner Meinung nach schließen, und die Leute werden zumindest anfangen, nach anderen OSS- oder sogar kostenpflichtigen Workflow-Engines zu suchen, die schließlich CoreCLR-Unterstützung erhalten. Ich denke nur, es ist ein großer Verlust, es nicht in CoreCLR zu haben ...

Ich kann einen sehr starken Grund nennen, warum WF auf .Net Core portiert werden sollte.

Microsoft führt Entwickler in Richtung der UWP-Plattform. UWP wird die Windows-Plattform der Zukunft sein. Es hat nichts mit der luftigen Feenidee zu tun, Apps auf Linux usw. zu portieren. WF muss dringend auf Windows 10-Computern ausgeführt werden, und UWP ist die Zukunft für die Windows 10-Plattform.

Wir bauen gelegentlich verbundene Apps. Wir haben ein .Net-Backend und ein UWP-Frontend. Derzeit wird die gesamte Geschäftslogik von .Net und UWP gemeinsam genutzt. Aber wir möchten Geschäftslogik in WF weich codieren. Dies funktioniert gut in .Net, aber WF wird derzeit nicht von UWP unterstützt, sodass WF nutzlos wird, da der Benutzer keine Anrufe tätigen kann, die von der WF-Logik validiert werden, es sei denn, er ist mit dem Internet verbunden.

UPW hat einen XamlReader, also ist das Analysieren von XAML keine große Sache ...

@MelbourneDeveloper stimmen Ihnen aus allen Gründen zu, denken Sie jedoch daran, dass UWP und .Net Core (zumindest jetzt) ​​nicht unter demselben Spitznamen geführt werden, was bedeutet, dass selbst sie dieselben APIs auf niedrigerer Ebene teilen und dieselbe API-Oberfläche (und . Net Core ist OSS, UWP jedoch nicht), sie sind nicht dasselbe und nicht kompatibel. Mit anderen Worten, Sie können einer UWP-Assembly keine .Net Core-Assembly hinzufügen. Diese Unterschiede (IMHO) werden irgendwann beseitigt, aber im Moment existieren sie noch ...

Ja. Verstanden. Es war mit der Arbeitshypothese, dass diese beiden Dinge in Zukunft zusammengebracht werden. Wenn sie es nicht sind, Gott helfe uns!

Auch das Xaml von @MelbourneDeveloper UWP ist eine völlig andere, abgespeckte Version des Xaml von .NET. Die UserVoice von WindowsDev ist gespickt mit (was weiterhin ignoriert wird, wie bei allem UWP, wie es scheint – es ist kein Wunder, warum sie überhaupt eine UserVoice haben), um ihr Xaml-System zu verbessern:
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9523650-add-support-for-xmlnsdefinitionattribute

Hoffentlich tun sie das Richtige und versammeln sich wie vorgeschlagen hinter @cwensleys Mono Xaml-Portierung und/oder OmniXaml. Das Xaml-System von UWP ist in seiner jetzigen Form wirklich ein Witz und einer der Gründe, warum seine Akzeptanzrate so schrecklich ist.

Neben dieser Anmerkung habe ich einen geschäftlichen Anwendungsfall für die MSFTies zu berücksichtigen: NodeJS. Je länger wir uns alle über dieses Problem ärgern, desto mehr Wert gewinnt NodeJS auf dem Markt, da es wirklich plattformübergreifend und wirklich allgegenwärtig ist, etwas, das die MSFT-Technologie im Moment (oder in absehbarer Zukunft) einfach nicht beanspruchen kann. NodeJS arbeitet auf dem Server und dem Client (ALLE VON IHNEN) und ermöglicht die Wiederverwendung von Code zwischen den beiden. Eine Codebasis funktioniert in nativen (über Cordova) und Web-Szenarien (über Standard-HTML5-Browser), was viel billiger ist als das, was Sie mit einer MSFT-basierten Lösung tun müssten.

Es wird bald zu dem Punkt kommen, dass die Überarbeitung eines Systems in NodeJS und der Verzicht auf MSFT schmackhafter (und offensichtlich kostengünstiger) wird, als darauf zu warten, dass (wie es sich anfühlt) dysfunktionale Teams die wirtschaftlichen Realitäten des Marktes einholen.

Ich erwähne dies auch, da erwähnt wird, dass MSFT anscheinend auf UWP für seine Client-Plattform setzt, aber es erreicht einen Bruchteil des Marktes, den NodeJS erreicht. Und wenn ich Bruch sage, ist das vielleicht übertrieben. Wir sprechen von 200 Millionen (letzte bekannte Installationsanzahl von Windows 10) im Vergleich zu ~3 Milliarden (Milliarden) Geräten, die nodejs-basierte Anwendungen erreichen können.

Verstehen Sie mich nicht falsch, ich liebe MSFT. Ich habe über 15 Jahre meines Lebens in seine Technologien investiert und bin hier persönlich voll und ganz investiert. Mit dieser Investition geht jedoch die Leidenschaft einher, zu sehen, dass jeder es richtig macht, und stolz auf die Entscheidungen und Bemühungen zu sein, die hier mit der neuen Ära der plattformübergreifenden Großartigkeit von Open Source getroffen wurden. Ich möchte auch, dass sich jeder der drohenden Marktbedrohung bewusst ist (und vielleicht auch meine Befürchtungen bestätigt/bestätigt).

Schließlich, wenn alles gut geht, haben wir ein weiteres großes Problem mit unserem aktuellen Stand von plattformübergreifendem Xaml, da Portable.Xaml anders ist als OmniXaml, also müssen wir als Community irgendwann herausfinden, wie wir die beiden in Einklang bringen können Codebasen ... idealerweise. :)

@Michael-DST stimme dir in allen Punkten zu. Eines der Ziele, für die WF ausgeführt werden soll, sind Clients (insbesondere mobile und eingebettete). Wir möchten den Client-Code für lokale Geschäftsregeln reduzieren, indem wir ihm WF hinzufügen. Mit Clients spreche ich nicht streng über UWP wie Windows-Geräte (Telefon, Tablets und IoT) ...

Ich glaube, dass es wichtige Produkte gibt, die sich auf WF wie BizTalk und Sharepoint stützen, aber sie können sich immer noch auf die .Net-Vollversion verlassen, während Benutzer von .Net Core (und später UWP) sich auf die brandneuen WF/XAML-APIs verlassen könnten. Ich weiß, dass es viele #ifs um die Codebasis herum geben wird, aber das wird der richtige Weg sein ...

@galvesribeiro vielen Dank für die Überprüfung/Unterstützung. Es fühlt sich an, als würde ich manchmal bergauf skaten, da niemand dieses sehr reale (existenzielle?) Problem zu erkennen scheint, mit dem .NET konfrontiert ist. Tatsächlich trägt die .NET-Führung dazu bei, dieses Problem zu verschärfen, indem sie empfiehlt, .NET mit AngularJS für Webanwendungen zu koppeln, was Organisationen im Grunde wagt, insgesamt auf NodeJS umzusteigen! (vollständige Offenlegung, das habe ich geschrieben. :P ).

Ich zögere, hier so viel über NodeJS zu posten, da WF eher eine serverseitige Technologie ist, aber so wie ich (und andere Organisationen beginnen) es zu sehen, betrifft dies alle Bereiche und bedroht .NET auf breiter Front. Es ist einfach kostengünstiger (und markteffizienter), NodeJS derzeit als Lösungs-Stack zu verwenden, und wir sehen (wieder, ich wiederhole mich ungern – aber nicht wirklich), dass sich dies in Organisationen für die Technologie ihrer Wahl widerspiegelt.

Fazit: Ich muss meine Angst _irgendwo_ platzieren und dieser Thread ist das Opfer. :P #tut mir leid

In Bezug auf #if defs ... igitt, ich werde hier das MvvMCross-Manifest zitieren: "# is for twitter, not code." :P

SCHLIESSLICH habe ich vergessen, @SuperJMN zu markieren, da er diesen Thread/diese Diskussion ebenfalls kennen sollte (als Autor von OmniXaml) – keine Respektlosigkeit beabsichtigt, Alter! Ich werde das Problem OmniXaml vs. Portable.Xaml in der nächsten Woche oder so persönlich angehen.

@Michael-DST ja ... Eigentlich ist das #if nur eine Möglichkeit ... Das .Net Core-Team hat den Ansatz von "Native Shims" gewählt, bei dem die reale (betriebssystemspezifische) Implementierung auf einer dünnen unteren Schicht nativen Codes abstrahiert wird. Im WF-Fall könnte es beispielsweise ein Shim für .Net Full und ein anderes für .Net Core sein ...

Ich bin kein Fan von Node.js und auch nicht von JavaScript (ich neige dazu zu denken, dass es immer noch eine Skriptsprache ist, keine Programmiersprache, aber das ist meine eigene Meinung), aber ich muss zugeben, dass heutzutage nichts damit verglichen wird in Bezug auf xplat. Microsoft selbst verwendet es für seine Build-Agenten auf VSTS (um nur einen Fall zu nennen, es gibt andere auf MS), da es beispielsweise auf jeder Plattform ausgeführt wird ...

Ich denke, WF ist ein großartiges Stück Technik, dessen aktuelle Version jedoch für Benutzer auf der Serverseite gedacht war, mit .Net Core, und kann auch perfekt auf Clients ...

@galvesribeiro ... ich bin zu 100 % bei dir. EF Core 1.0 ist genauso ... eine traditionell serverseitige Technologie, die jetzt auch auf der Clientseite verwendet werden kann. Es wäre sehr praktisch, WF auch auf diese Weise verfügbar zu haben.

Außerdem ist es gut, von den Shims zu hören. Sehr zustimmen. :)

Abschließend möchte ich den Thread hier nicht (viel) entgleisen/entführen, aber um sicher zu gehen: JavaScript: Als Skriptsprache bin ich einverstanden. Es ist jedoch auch eine sehr flexible "Sprache", die in anderen Formen verwendet werden kann, insbesondere Bytecode (ish). Wie Sie sicher gesehen haben, gibt es LVVM-Compiler-Magie für C++. Die wachsende/beliebte Forderung in der .NET-Entwicklergemeinschaft ist, dasselbe für .NET zu tun (.NET in JS auf offizieller Ebene zu transpilieren). Dies würde wirklich alle aktuellen (großen) Übel im aktuellen MSFT-Entwicklerklima korrigieren.

Wie auch immer, zurück zu Ihrem regulären geplanten Programm. :P Danke für den Dialog und die Gedanken!

Ihr sprecht einige Dinge an, mit denen ich mich seit 9 Jahren beschäftige. Es gibt etwas, das viele Leute, die mit Microsoft-Technologien arbeiten, nicht verstehen; nämlich das Konzept des verteilten Rechnens. Eine grundlegende Anforderung an unsere Software von Anfang an ist, dass sie im gelegentlich verbundenen Modus arbeitet. Im Laufe der Zeit hat Microsoft verschiedene Versuche unternommen, Tools dafür bereitzustellen, aber es wurde nie ein umfassendes Framework entwickelt. Wir haben hier ein bisschen Synchronisierungs-Framework, dort drüben eine Art LINQ-Datenbank, aber kein umfassendes Toolset, mit dem alles zusammenarbeitet.

In den letzten 9 Jahren haben wir unser eigenes gelegentlich verbundenes Framework entwickelt. Es läuft jetzt auf .Net, Silverlight und UWP. Wir haben uns sehr bemüht, Microsoft-Frameworks wie EF und WF zu nutzen, aber für diese Technologien wurde auf Client-Technologieplattformen wie Silverlight kein Support angeboten. Wir haben buchstäblich unser eigenes ORM- und Synchronisierungs-Framework für Silverlight entwickelt, das jetzt mit UWP kompatibel ist.

Als WF überhaupt viel Aufsehen erregte, war es ziemlich aufregend, weil es eine Möglichkeit bot, Geschäftslogik ohne Code zu codieren. Aber im Laufe der Zeit neigte ich immer weniger zu der Annahme, dass es jemals eine Portierung zu einer clientseitigen Technologie wie Silverlight geben würde. Ich habe zahlreiche Fragen dazu in Foren gestellt, aber die Antwort war immer dieselbe: WF ist eine serverseitige Technologie, warum sollten Sie sie in Silverlight verwenden?

Wie Galvesribeiro sagte

"Ich denke, WF ist ein großartiges Stück Technik, dessen aktuelle Version jedoch für Benutzer auf der Serverseite mit .Net Core gedacht war und auch perfekt auf Clients funktioniert ..."

Und

„Eines der Ziele, auf denen WF ausgeführt werden soll, sind Clients (insbesondere mobile und eingebettete). Wir möchten den Client-Code für lokale Geschäftsregeln reduzieren, indem wir WF hinzufügen. Mit Clients spreche ich nicht genau über UWP wie Windows-Geräte (Telefon, Tablets und IoT)"

Was die Leute verstehen müssen, ist, dass es beim Distributed Computing keine Unterscheidung zwischen Client- und Server-Technologie gibt. Denken Sie darüber nach, wie Git funktioniert. Der Code für Git ist derselbe, unabhängig davon, ob Sie sich das zentrale Repo oder irgendwo einen Knoten im Netzwerk ansehen. Der Code wird überall dupliziert. Genauso verhält es sich mit unserem Framework. Die Geschäftslogik wird auf alle Knoten dupliziert. Denn selbst wenn der Benutzer nicht mit dem Netzwerk verbunden ist, muss er dennoch der gleichen Geschäftslogik unterworfen werden. Beim verteilten Rechnen ist jeder Computer buchstäblich ein Server. Es führt buchstäblich den gleichen Code wie der Server aus.

Wir konnten WF nie nutzen, weil wir den WF-Code nicht in Silverlight ausführen konnten, und jetzt können wir ihn nicht in UWP ausführen. Es ist ermutigend zu sehen, dass EF auf UWP portiert wird. Vielleicht ist dies der Anfang von Microsoft zu verstehen, dass verteiltes Computing eine Notwendigkeit ist. Aber Microsoft muss mit Distrubeted Computing an Bord gehen und WF als Teil des gesamten verteilten Computing-Frameworks einbeziehen. Vielleicht können wir dann unser Distributed-Computing-Framework löschen, und ich muss diesen Code nicht mehr pflegen.

Wirklich tolle Perspektive und Gedanken @MelbourneDeveloper. Vielen Dank, dass Sie sie geteilt haben. Ich war auch ein riesiger Fan von Silverlight und habe seitdem daran geschnüffelt (daher meine resultierende Abstimmung und -- wirklich -- Seite oben). Außerdem bin ich neugierig, was Sie von Azure Mobile Services halten und ob Sie darüber nachgedacht haben, dies in Ihrer Offline-Story zu verwenden? Ich bin ein Newb mit verteiltem Rechnen (aber finde heraus, was du zu sagen hast), aber ich möchte wirklich nächstes Jahr darauf eingehen (ich höre auch viele Microservices, von denen ich glaube, dass sie das neueste Äquivalent dazu sind?) .

Was die Leute verstehen müssen, ist, dass es beim Distributed Computing keine Unterscheidung zwischen Client- und Server-Technologie gibt.

Wirklich guter Punkt. An dieser Stelle dreht sich alles darum, wo die Technologie gehostet wird. Das heißt, Sie sind wirklich durch den Host der Technologie eingeschränkt, die Sie zu "verteilen" versuchen, würde ich sagen (und auch hier bin ich kein Experte). Je allgegenwärtiger (oder leicht verfügbar) der Host ist, desto besser verteilt/zugänglich ist die Anwendung. Annnnnd .... Ich denke, Sie wissen, worauf ich damit hinaus will. :P

Auf jeden Fall fühlt es sich tatsächlich so an, als ob wir uns hier mit dieser Diskussion alle über _etwas_ einig sind, und das ist eine willkommene Veränderung/Errungenschaft für mich. ;)

@galvesribeiro

Denken Sie daran, dass UWP und .Net Core (zumindest jetzt) ​​nicht unter demselben Spitznamen laufen, was bedeutet, dass sie sogar dieselben APIs auf niedrigerer Ebene teilen und dieselbe API-Oberfläche haben (und .Net Core ist OSS, UWP jedoch nicht). , sie sind nicht dasselbe und nicht kompatibel. Mit anderen Worten, Sie können einer UWP-Assembly keine .Net Core-Assembly hinzufügen. Diese Unterschiede (IMHO) werden irgendwann beseitigt, aber im Moment existieren sie noch ...

Werfen Sie einen Blick auf dieses PR dotnet/corefx#5760, ich hoffe, das verdeutlicht einige Dinge.

Die .NET-Seite von UWP _ist_ .NET Core. .NET Core bietet jedoch mehrere Laufzeiten. UWP verwendet die AOT-basierte Laufzeit, sodass bestimmte Funktionen, die ein JIT erfordern, nicht unterstützt werden (z. B. LCG oder RefEmit). Sie teilen sich jedoch dieselben Assemblys und (weiterhin) dieselben NuGet-Pakete. Wir haben den Stapel speziell entwickelt, um Querverweise auf Assemblys (und Pakete) von UWP und ASP.NET Core zu ermöglichen.

Natürlich gibt es darüber hinaus VS-Tools namens Portable Class Libraries (PCL), die versuchen, Ihnen beim Erstellen von Bibliotheken zu helfen, die auf einer Reihe von Plattformen funktionieren. Im PCL-Targeting-Dialogfeld können Sie mehrere Optionen auswählen, die alle dazu führen, dass Ihre Binärdatei mit .NET Core kompatibel ist. Da die Portabilität in VS jedoch durch Betrachten der Plattformen bestimmt wird, können Sie nicht auf eine PCL von einer UWP-App verweisen, es sei denn, diese PCL gibt an, dass sie auf UWP abzielen kann. Dieses Verhalten ist beabsichtigt, da die PCL-Tools Ihnen dabei helfen sollen, nicht versehentlich Funktionen zu verwenden, die nicht überall dort unterstützt werden, wo Sie sie ausführen müssen. Umgekehrt können Sie nur PCLs von Plattformen referenzieren, auf die es angeblich abzielt.

Da Sie explizit Moniker erwähnen, lassen Sie uns auch eine Sekunde darüber sprechen. Das Design eines Monikers (TFM) besteht darin, dass er die Gesamtheit des Oberflächenbereichs darstellt. In unseren Werkzeugen gibt es zwei Spitznamen:

• TargetPlatformMoniker (TPM)
• TargetFrameworkMoniker (TFM)

Stellen Sie sich das TFM so vor, dass es die Gesamtheit des verwalteten Eingangsbereichs identifiziert, während das TPM das zugrunde liegende Betriebssystem darstellt, dh den vom Betriebssystem bereitgestellten API-Satz.

Da wir .NET Core so konzipiert haben, dass es auf mehrere Plattformen portierbar ist, macht ein traditionelles TFM nicht wirklich viel Sinn. Aus diesem Grund gibt es ein neues Konzept namens Standard Platform , früher Generationen genannt.

Hilft das?

Sie teilen sich jedoch dieselben Assemblys und (weiterhin) dieselben NuGet-Pakete.

Die meisten Assemblys verfügen über dieselbe BINARY-Implementierungs-DLL für die NuGet-Zielanwendungen „netcore50“ (Windows UWP Store App) und „dnxcore50“-NuGet-Zielanwendungen (ASP.NET v5/ASP.NET Core 1.0).

Einige NuGet-Pakete wie viele der System.Net.*-Bibliothekspakete haben jedoch unterschiedliche Implementierungen für das Ziel „netcore50“ und das Ziel „dnxcore50“. Beispielsweise verwendet die System.Net.Http-Bibliothek mit „netcore50“ die Windows.Web.Http-Implementierung von WinRT darunter. Die 'dnxcore50'-Implementierung verwendet etwas anderes (natives WinHTTP).

Einige NuGet-Pakete wie viele der System.Net.*-Bibliothekspakete haben jedoch unterschiedliche Implementierungen für das Ziel „netcore50“ und das Ziel „dnxcore50“.

Ja, das hätte ich erwähnen sollen. Ich sehe das so, dass ein NuGet-Paket einen Container bereitstellt, der es dem Erzeuger ermöglicht, verschiedene Implementierungen für verschiedene Ausführungsumgebungen bereitzustellen, während die Verbraucher dies nicht wissen müssen. In diesem Sinne sind NuGet-Pakete die neuen Assemblys.

Vielen Dank an @terrajobst und @davidsh , dass Sie diese tiefere Erklärung und dieses Referenzproblem geteilt haben, aber was ist falsch an meiner Aussage, dass „eine Assembly von einer Plattform nicht von einer anderen referenziert werden kann“?

Ich sehe das so, dass ein NuGet-Paket einen Container bereitstellt, der es dem Erzeuger ermöglicht, verschiedene Implementierungen für verschiedene Ausführungsumgebungen bereitzustellen, während die Verbraucher dies nicht wissen müssen. In diesem Sinne sind NuGet-Pakete die neuen Assemblys.

Dieses Konzept ist eigentlich nicht neu ... Die Leute erstellen bereits ein Nuget-Paket, das nichts weiter als ein Verweis auf eine Reihe anderer Pakete ist - die sogenannten "Meta-Pakete". Es gibt mehrere Möglichkeiten, eine PCL auf vielen Plattformen zum Laufen zu bringen. Die bekanntesten, die von vielen populären Bibliotheken (wie Json.Net von Newtonsoft) verwendet werden, sind Bait und Switch , wo Sie ein Nuget haben, das eine öffentliche Schnittstelle (die API-Oberfläche) und eine Assembly für jede spezifische Plattform (die tatsächliche Implementierung der API-Oberfläche) hat. die sogar unterschiedliche Abhängigkeiten voneinander haben können, und zur Laufzeit wird die richtige Assembly für diese Plattform ausgewählt. Der Unterschied besteht jetzt darin, dass wir statt mehrerer Nugets „innerhalb“ eines einzelnen Container-Nugets, wo alle auf derselben Plattform oder 1 Schnittstellen-Assembly sein sollten, die nur von der Entwicklung verwendet wird und zur Laufzeit auf die spezifische umschaltet, eine Mischung haben davon! 1 Nuget, das ein Container und gleichzeitig die öffentliche Schnittstelle für alle damit verknüpften plattformspezifischen Nugets ist.

Ich glaube wir reden vom selben, ich habe mich anfangs nur schlecht ausgedrückt :smile:

Wie auch immer, zurück zu WF ... Ich denke, es ist berüchtigt, dass Leute es auf WF portieren wollen, nicht nur "weil es cool ist", es unter Linux oder auf Nano Server laufen zu lassen. Die Leute möchten es auch auf Clients auf einfache Weise verwenden.

Nochmals, ich denke, es gibt genug Leute aus der Community, die diesen Port verwirklichen wollen ...

PS: Für diejenigen, die an verteiltem Computing interessiert sind (das echte, nicht die Offline-Client-Geschichte), werfen Sie bitte einen Blick auf unser anderes Projekt Orleans , das eigentlich ein guter Anwendungsfall für WF auf .Net Core ist und das heute große Microsoft-Dienste unterstützt wie Skype, Halo5, und die ich persönlich als meine Kerntechnologie meiner Finanztransaktionsverarbeitungsplattform verwende, die Milliarden von Transaktionen auf verteilte Weise verarbeitet ...

@galvesribeiro

Was ist falsch an dem, was ich gesagt habe, dass "1 Assembly von einer Plattform nicht von einer anderen referenziert werden kann"?

Es ist nicht so, dass Ihre Aussage falsch ist; es ist nur so, dass es auch nicht richtig ist :smile: Normalerweise bin ich nicht der Typ, der gerne pingelig ist, aber was mich abgeschreckt hat, war dieser Teil:

Mit anderen Worten, Sie können einer UWP-Assembly keine .Net Core-Assembly hinzufügen.

Ich möchte den Eindruck vermeiden, dass UWP und .NET Core unterschiedliche .NET-Plattformen sind, wie es .NET Framework und Silverlight waren. Wir haben .NET Core speziell dafür entwickelt, dass Sie Assemblys erstellen können, die auf allen Plattformen funktionieren. Zum Beispiel sind System.Collections.Immutable und so ziemlich alles von Roslyn .NET Core-Assemblys, die auch in UWP gut funktionieren.

Um es anders zu formulieren: Unser Ziel ist es, eine Plattform zu erstellen, auf der einfache MSIL-basierte Komponenten buchstäblich dieselbe Binärdatei auf allen .NET Core-basierten Plattformen verwenden können. In Fällen, in denen dies nicht möglich ist, beispielsweise aufgrund nativer Abhängigkeiten oder unterschiedlicher Implementierungen, machen wir genau das, was Paul Betts so eloquent als Bait and Switch PCLs beschrieben hat: portable Oberfläche, unterschiedliche Implementierungen pro Plattform und NuGet als Container und Wähler.

In der .NET Core-Welt sind die System -Bibliotheken nicht wirklich etwas Besonderes. Jeder kann dieselbe Technik anwenden, um sicherzustellen, dass die meisten Verbraucher ihre Codebasis nicht mit #if -Direktiven übersäten müssen.

Ich glaube wir reden vom selben, ich habe mich anfangs nur schlecht ausgedrückt :smile:

Ich denke, wir haben eine Welt geschaffen, in der es ein bisschen zu leicht ist, Menschen zu verwirren – was natürlich auch uns einschließt :smile: Deshalb bemühe ich mich so sehr, genau zu beschreiben, wie .NET Core entwickelt wurde und welche Probleme wir zu lösen versuchten.

Ja, du hast recht. Auf den Eindruck kommt es an.

Ich hoffe, dass wir eines Tages auch .Net Core auf UWP aufrufen, damit das vorbei ist ... Wir brauchen also immer noch system.xaml

Obwohl verwandt, denke ich, dass System.Xaml eine separate Komponente ist, die selbst einen Mehrwert schafft. Ich habe dotnet/corefx#5766 eingereicht, um dies separat zu verfolgen.

Danke Michael-DST

Außerdem bin ich neugierig, was Sie von Azure Mobile Services halten (https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/) und wenn Sie darüber nachgedacht haben, das in Ihrer Offline-Story zu verwenden?

Ausgezeichnete Frage. Dies führt zu einer kleinen Geschichtsstunde über die Erfahrung unseres Unternehmens mit verteiltem Computing, auch bekannt als gelegentlich verbundene Apps, und wie dies mit Azure Mobile Services und verteiltem Computing mit Microsoft-Technologie zusammenhängt.

Wenn die Leute die oben erwähnte Website noch nicht gesehen haben, empfehle ich dringend, sie sich anzusehen. Es hat ein gutes Video über Azure Mobile Services.

Vor ungefähr 8 Jahren haben wir eine App für die ursprüngliche Windows Phone-Plattform entwickelt. Die alte Schule mit .Net Compact Framework. Die Leute mögen darüber spotten, aber in einigen wichtigen Punkten war diese Plattform in Bezug auf gelegentlich verbundene Technologie fortschrittlicher als die aktuelle UWP-Plattform. Obwohl es scheint, dass UWP aufholt. Die Schlüssel für den Erfolg gelegentlich verbundener Apps auf dieser Plattform waren:

1) Vollständige Implementierung der SQL-Datenbank (SQL Server CE)
2) Sync Framework-Implementierung zwischen SQL Server (Backend) und SQL Server CE (mobiles Gerät). Dies war Sync Framework Version 1.

Diese App war erfolgreich. Wir haben eine Datenschicht geschrieben, die sich über dem obersten SQL CE und SQL Server befand, der auf dem Server bereitgestellt und auf den Geräten bereitgestellt wurde. Es hat fast den Speicher ausgeschöpft, aber es hat funktioniert. Außendienstmitarbeiter konnten Daten vor Ort erfassen, und die Daten wurden mit der zentralen Datenbank synchronisiert.

Als Windows Phone 7 veröffentlicht wurde, waren wir entsetzt, weil es ein entscheidendes Problem gab: Alle Datenbanken auf dem Markt waren Nicht-SQL-Datenbanken. Sie wurden größtenteils mit LINQ implementiert. Dies war nicht mit unserer Datenschicht kompatibel, und EF existierte nicht für Windows Phone 7. Daher konnten wir kein gelegentliches Offline-Framework für Windows Phone 7 erstellen, obwohl wir in der Lage waren, eine vollständige Lösung für das Original zu erstellen Windows Phone-Plattform.

Silverlight war ein Game Changer. Wieder stießen wir auf eine vollständige SQL-Datenbank. Aber Microsoft hatte das Synchronisierungsframework nicht für Silverlight oder für die betreffende Inline-Datenbank implementiert. Also machten wir uns daran, unser eigenes Synchronisierungsframework zu schreiben, das dem Synchronisierungsframework von Microsoft nachempfunden ist. Das Microsoft-Synchronisierungsframework basiert auf Zeitstempeln. Dies haben wir in unserem Sync-Framework implementiert. Auch hier hatten wir mit Silverlight vollen Erfolg. Außendienstmitarbeiter konnten Windows-Tablets mit in den Außendienst nehmen, Daten erfassen und sie dann wieder mit der zentralen Datenbank synchronisieren. Das Problem war, dass dies für Telefone nie verfügbar war. Die Datenbankplattform existierte für Windows Phone 7 nicht.

Wie ich bereits erwähnt habe, wollten wir Geschäftslogik mit WF implementieren, aber Silverlight wurde aufgegeben und niemand sprach auch nur von der Möglichkeit, WF auf Silverlight zu portieren.

Schließlich kommen wir bei UWP an. Für UWP wurde ein Wrapper für SQLite geschrieben, und mit ein paar Hacks am Wrapper konnte ich die Schnittstelle mit SQLite erweitern, damit wir wieder mit einer vollständigen SQL-Datenbank arbeiten können. Das bedeutet, dass unsere Datenschicht damit kompatibel ist. Unsere Datenschicht und Synchronisierungsschichten funktionieren jetzt auf .Net, Silverlight und UWP mit SQL Server, SQLite und einer anderen unbenannten Datenbankplattform.

Heute ist das erste Mal, dass ich dank Michael-DST eine Synchronisierung mit reiner Microsoft-Technologie sehe. Grundsätzlich kann ich sagen, dass die Synchronisierung von Azure Mobile Services nur ein Rebranding von Microsoft Sync Framework ist. Es hat eine etwas andere API-Schnittstelle, aber die Grundlagen sind die gleichen wie beim ursprünglichen Windows Phone-Synchronisierungsframework, das wir vor etwa 8 Jahren verwendet haben, um die Synchronisierung zum Laufen zu bringen. Ich kann sehen, dass es sogar die gleichen zwei Zeitstempelfelder verwendet, um Datenänderungen zu verfolgen. Diese wurden in SQL Server als Kernfunktion in SQL Server 2008 eingeführt. Unser Synchronisierungsframework funktioniert mehr oder weniger auf die gleiche Weise wie das Microsoft-Synchronisierungsframework.

Also, um Michaels Frage zu beantworten, ich werde diese Technologie untersuchen. Ich werde sehen, ob es unser Sync-Framework ersetzen kann. Ich würde es gerne entsorgen und jemand anderen warten lassen. Angesichts der Tatsache, dass sie erwähnt haben, dass es SQLite unterstützen wird, klingt es vielversprechend, weil es so klingt, als könnten wir den SQLite-Wrapper hacken, um weiterhin die vollständige SQL-Datenbank zu verwenden, und daher unsere Datenschicht weiterhin verwenden können. Wenn dies der Fall ist, bedeutet dies, dass mehr als 5 Jahre Synchronisierungs-Framework-Code direkt in den Papierkorb wandern.

Wie auch immer, der Punkt ist, Microsoft sieht so aus, als würden sie wieder einmal anerkennen, dass verteiltes Computing wichtig ist. Wenn es wichtig ist, sollte WF auf UWP portiert werden. UWP ist die Zukunft und damit auch die Zukunft des verteilten Rechnens mit Microsoft-Technologie. Die Zukunft der verteilten Technologie braucht WF.

Obwohl verwandt, denke ich, dass System.Xaml eine separate Komponente ist, die einen Mehrwert für sich bietet. Ich habe dotnet/corefx#5766 eingereicht, um dies separat zu verfolgen.

Vielen Dank @terrajobst! Ich bin nicht mit allem einverstanden, was Sie online/twittern, aber ich bin ein großer Fan davon, wie Sie den Dialog und die Kommunikation zwischen Entwicklern/Community erleichtern, und ich werde dem immer zustimmen. :) Das bedeutet mir persönlich wirklich viel, da es wie über ein Jahr bergauf zu skaten scheint, um irgendetwas von MSFT zu bekommen (und ja, mir ist klar, dass es keine Verpflichtung ist, aber an diesem Punkt ist alles sinnvoll).

Also, um Michaels Frage zu beantworten, ich werde diese Technologie untersuchen.

Fantastischer @MelbourneDeveloper , hilft gerne weiter! Ich habe das Gefühl, dass Azure ihre Gruppe wirklich fest im Griff hat. Zusammen mit VSO/VSTS hören sie wirklich auf ihre Entwickler und bekommen eine *_ Menge *_ erledigt. Tatsächlich scheint dies bei jeder Gruppe in MSFT der Fall zu sein, _außer_ bei der UWP-Gruppe, die wirklich nicht viel zu tun scheint und nicht einmal ihre eigene Technologie zu verstehen scheint (und lassen Sie uns nicht einmal auf ihre Definition von eingehen „XAML“).

Derzeit verwenden wir WF für mehrere unserer Kerndienste und weiten unsere Nutzung sogar noch weiter aus, da wir großartige Erfahrungen mit Workflow gemacht haben und unsere Geschäftslogik in einem so visuellen, leicht verständlichen Format haben.

Wie @MelbourneDeveloper sagte

Wie auch immer, der Punkt ist, Microsoft sieht so aus, als würden sie wieder einmal anerkennen, dass verteiltes Computing wichtig ist. Wenn es wichtig ist, sollte WF auf UWP portiert werden. UWP ist die Zukunft und damit auch die Zukunft des verteilten Rechnens mit Microsoft-Technologie. Die Zukunft der verteilten Technologie braucht WF.

WF wurde von vielen .NET-Entwicklern als Technologie unterschätzt, weil sie den Wert damals möglicherweise nicht erkannt haben (ich habe es in der Vergangenheit nicht getan, aber jetzt bin ich ein großer Fan von WF, weil ich verstehe, wie leistungsfähig es sein kann sein!), aber im Zeitalter des verteilten Rechnens kann WF jetzt mehr denn je wirklich glänzen, und ich hoffe, dass es endlich portiert wird.

Ich denke, es gibt wenig Raum für Meinungsverschiedenheiten zu diesem Thema.

Es lässt sich sicherlich argumentieren, dass deklarative, visuelle Programmierung wie WF nicht so effizient ist wie das Schreiben von Code. Dem würde ich sogar eher zustimmen. Aber WF als Tool im Toolkit zu haben, um eine konfigurierbare Plattform abzurunden, wäre sicherlich eine gute Sache. Kunden *_DO *_ möchten visuelle Workflows sehen, und es ist sicherlich eine gute Sache, Kunden die Möglichkeit zu geben, ihre eigenen Workflows zu ändern.

Zeit, dies zu erledigen!

Ich denke, es gibt wenig Raum für Meinungsverschiedenheiten zu diesem Thema.

Haha @MelbourneDeveloper hast du jemals einen Softwareentwickler getroffen? Oder wirklich die Menschheit? ;P

Ich persönlich bin der Meinung, dass der visuelle WF-Designer und vorhandene Tools XAML einen schlechten Dienst erwiesen haben, da die übermäßig ausführlichen Dateien, die für MSBuild-Workflows generiert wurden, Xaml in dieser Hinsicht wirklich einen schlechten Ruf eingebracht haben. Das ist wirklich das, was Entwickler mit Xaml („aufgeblähte Dateien“) assoziieren und dazu beigetragen haben, die Flucht hin zu „einfacheren“ JSON-Dateien und „gescripteten“ Build-Dateien auszulösen. Ganz zu schweigen von dem ganzen geheimnisvollen, schwierigen und umständlichen Prozess (ich kann ihn immer noch nicht einmal in meinen Projekten vollständig zum Laufen bringen), um überhaupt ein Projekt zu erstellen, um die Xaml-Datei überhaupt anzuzeigen.

Dabei war die Arbeitsweise von WF die ganze Zeit über der "richtige Weg". Seine eigentliche Krankheit lag in seiner Werkzeugausstattung.

Wenn das Designer-Tool als solches etwas benutzerfreundlicher wäre (und vielleicht bessere Arbeit beim Serialisieren von Dateien in einer organisierteren/kompartimentierteren Weise geleistet hätte), wäre dies kein Problem (oder weniger ein Problem).

Ich bin ein großer Fan des Weges, den WF angestrebt hat, aber er muss ein wenig gestrafft und seine Werkzeuge angegangen und verbessert werden. Wirklich, am Ende des Tages ist eine Technologie nur so gut wie ihre unterstützenden Tools – Designer und alle anderen. Je besser die Tools/Designer, desto zugänglicher/verständlicher, je besser die Technologie, desto besser die Akzeptanz.

Ich würde auf jeden Fall gerne sehen, dass WF mehr wie EF wird und in jedem .NET-Szenario zugänglich ist, und dass die Tools verbessert werden, um genau dies zu ermöglichen.

Mein Verständnis ist, dass eine der ursprünglichen Visionen für WF darin bestand, mehrere Dateitypen für Workflows zu unterstützen, nicht nur XAML. Abgesehen von einigen Macken hier und da hatte ich insgesamt keine Probleme mit XAML. Es hat nur eine Weile gedauert, bis ich mich damit beschäftigt hatte und mich daran gewöhnt hatte, es bei Bedarf manuell zu bearbeiten, was sicherlich für viele Menschen eine Eintrittsbarriere darstellt. Obwohl ich denke, dass XAML aus Gründen der Abwärtskompatibilität (zumindest kurzfristig) beibehalten werden muss, würde ich wirklich gerne sehen, wie andere Workflow-Dateitypen mit der Entwicklung beginnen (wie JSON). Ich könnte einige coole Community-Beiträge an dieser Front sehen! (Workflows in Whitespace geschrieben jemand? :smile: )

@Michael-DST Ich stimme dir vollkommen zu. Kürzlich haben mein Team und ich Vorlieben/Abneigungen/Wünsche für Workflow überprüft und fast alles, was wir verbessert sehen wollten, betraf den Designer und nicht unbedingt den Kern von WF selbst. Ich denke, Microsoft hat mit dem, was sie in WF eingebaut haben, fantastische Arbeit geleistet, und ich denke, mit ein paar Verbesserungen und etwas Evangelisation könnten wir sehen, wie ihm neues Leben eingehaucht wird. Ich denke, es ist ein Werkzeug, das existieren MUSS, und ich habe eine Menge Wert aus WF gezogen, und ich möchte, dass es für eine LANGE, LANGE Zeit weitergeführt wird.

Unser Unternehmen hat beträchtliche Investitionen in WF getätigt und ist jetzt eine Schlüsseltechnologie für unser Geschäft. Angesichts des jüngsten Engagements von Microsoft für Open Source und .NET Core scheint die Portierung von WF der beste nächste Schritt für diese Technologie zu sein. Wir brauchen das!

Workflow war ein Werkzeug mit vielen Vorteilen für uns als Entwickler in unserer Organisation. Wenn Microsoft seine Frameworks vereinheitlicht, würde es unser Leben einfacher machen, WF im Kernframework zu haben.

Haha @MelbourneDeveloper hast du jemals einen Softwareentwickler getroffen? Oder wirklich die Menschheit? ;P

Haha, ich bin Softwareentwickler. Die Menschheit ist für mich belanglos.

Michael-DST

Ich persönlich bin der Meinung, dass der visuelle WF-Designer und vorhandene Tools XAML einen schlechten Dienst erwiesen haben, da die übermäßig ausführlichen Dateien, die für MSBuild-Workflows generiert wurden, Xaml in dieser Hinsicht wirklich einen schlechten Ruf eingebracht haben. Das ist wirklich das, was Entwickler mit Xaml („aufgeblähte Dateien“) assoziieren und dazu beigetragen haben, die Flucht hin zu „einfacheren“ JSON-Dateien und „gescripteten“ Build-Dateien auszulösen

Du hast vermutlich recht. Aber ich persönlich denke, dass hier zu viel Wert auf Xaml gelegt wird. Als ich WF getestet habe (bevor ich feststellte, dass wir es nicht verwenden konnten, weil es auf Silverlight nicht existiert), habe ich eine WPF-App erstellt. Diese App hat sich mit unseren WCF-Diensten verbunden und das Xaml für die WF in einer Tabelle in unserer Datenbank gespeichert. So haben wir die Soft-Codierung von WF erreicht.

Das Xaml wurde jedoch vollständig mit dem WPF WF-Designertool manipuliert. Der Benutzer hat das Xaml nie gesehen. Das xaml war für den Benutzer irrelevant. Stellen Sie es sich wie das HTML-Markup hinter einer Webseite vor. Es könnte sehr kompliziert sein, aber solange dem Endbenutzer die Webseite gefällt, spielt es keine Rolle. Ich denke, wenn Sie das Xaml direkt als Text manipulieren, verwenden Sie WF sowieso nicht auf die beabsichtigte Weise ...

Die Menschheit ist für mich belanglos.

Schön. B)

Das Xaml wurde jedoch vollständig mit dem WPF WF-Designertool manipuliert. Der Benutzer hat das Xaml nie gesehen.

Richtig. Genau so funktioniert MSBuild und Endbenutzer hassen es wegen der Größe der generierten Dateien (besonders wenn man sie mit einfachen „Skript“-Dateien vergleicht, die sehr einfach und linear sind). Ich stimme Ihnen zu, dass dies ein Tooling/Designer-Problem ist, und ich würde auch sagen, dass das Tooling/Designer mit WF erheblich verbessert werden könnte.

Typisches Beispiel: Blogposts und Kopieren/Einfügen von Code (oder wirklich, Kopieren/Einfügen von _workflow_ :smile:). Ich habe mehrmals online nach WF gesucht und bin auf einen netten Blogbeitrag gestoßen, der einige Schritte zum Einfügen einer Workflow-Komponente (höchstwahrscheinlich für MSBuild) zeigt. Nun, um dies zu tun, musste ich im Grunde eine Reihe von Schritten duplizieren. Normalerweise ist der Code in einem Codierungs-Blogpost zum einfachen Kopieren/Einfügen verfügbar. Nicht so bei WF. Sie müssen es Schritt für Schritt tun, bis es auf Ihrem Computer genau so aussieht, wie es auf dem Blog-Beitrag aussieht. Dies ist offensichtlich sehr mühsam und fehleranfällig (und fühlt sich aus C#-Perspektive wie ein Schritt zurück an).

Das andere Problem, auf das wir bei MSBuild gestoßen sind, ist die Größe der Datei, nicht nur in Bytes, sondern auch im Designer selbst: Es war wirklich schwierig, durch einen komplexen Workflow zu navigieren. Dies scheint etwas zu sein, das auf sehr umfassende (und intuitive) Weise berücksichtigt werden sollte.

Abschließend möchte ich die Sache mit der Dateigröße abschließen. Ich bin mir nicht sicher, ob Sie WordML und/oder MSFT Frontpage von damals kennen. Aber es würde das aufgeblähteste HTML der Welt erzeugen. Obwohl Benutzer im Allgemeinen nicht ihre Hände in das resultierende Markup stecken, stecken sie gerne ihre Nase hinein, um ein Gefühl dafür zu bekommen, wie "sauber" es ist. Als erstes schauen sie sich die Größe auf der Festplatte an und zweitens öffnen sie die Datei, um zu sehen, wie sie formatiert ist usw.

Auch hier stimme ich zu, dass die Art und Weise, wie diese Dateien erstellt werden, ausschließlich ein Tooling-/Designerproblem ist, aber Entwickler werden neugierig und dies sollte ebenfalls berücksichtigt werden. :)

Ja. Alles gute Punkte. Ich denke, dass der Designer bereinigt werden müsste, damit er kein so ausführliches Xaml erstellt.

Wer hat eigentlich die Macht darüber zu entscheiden, ob WF auf .Net Core oder UWP portiert wird? Ist es nur so, dass ein Entwickler irgendwo den Code schreibt und diesen Patch dann an die Administratoren des .Net Core-Codebasis-Repositorys übermittelt? Was ist die Politik dazu? Gibt es nicht ein Kernteam von Entwicklern, die von Microsoft beeinflusst werden? Sind Microsoft-Mitarbeiter? Ich habe immer noch nicht wirklich das ganze Setup. Wen müssen wir überzeugen?

Eigentlich @MelbourneDeveloper helfen Sie nur durch die Teilnahme an diesem Thread, die Argumentation zu vertreten. Es gibt ein Team bei MS, das WF besitzt, derzeit meines, aber wir treffen nicht die Entscheidung, WF auf Core zu veröffentlichen. Wir müssen den Business Case machen. Die Diskussion hier hilft mir dabei.

Es ist wirklich beeindruckend, wie die Leute 2016 angefangen haben, diesen Thread zu unterstützen :)

Auch die https://github.com/dotnet/corefx/issues/5766 von @terrajobst ist heutzutage viel beschäftigter :)

@dmetzgar Ich hoffe, Sie erhalten so viel Feedback wie Sie können / brauchen aus diesen Diskussionen, damit Sie genügend Fälle haben, um es zu OSSen.

Ich bin mir ziemlich sicher, wenn ein Dotnet/WF-Repo geöffnet oder zu Corefx hinzugefügt wird, werden die Leute es definitiv sehr schnell wachsen lassen.

Eigentlich @MelbourneDeveloper helfen Sie nur durch die Teilnahme an diesem Thread, die Argumentation zu vertreten

Das macht mich warm und flaumig.

Nur zu Ihrer Information, dmetzgar – ich bin mehr als glücklich, unsere Erfahrungen zu dokumentieren und überzeugende Argumente vorzubringen, um Beweise für den Hafen-Business-Case zu liefern.

Ich bin seit 2000 knietief in der Microsoft-Technologie. Ich habe beobachtet, wie sich alle wichtigen Technologien, die für diesen Thread relevant sind, entwickeln und wieder verschwinden. Obwohl ich in die Microsoft-Technologie eingetaucht bin, sehe ich sie immer noch von einem objektiven Standpunkt aus und denke, dass WF eine der Schlüsseltechnologien ist, die dazu beitragen würden, Unternehmen/Regierungen für die .Net Core- und Windows UWP-Plattformen einzukaufen.

Nichts begeistert einen Kunden mehr als Flussdiagramme! Gar nichts!

Ich sollte auch sagen, dass die Microsoft-Technologie an der Schwelle zu etwas Großem steht.

So viele Jahre lang habe ich den Aufstieg und Fall guter Technologie beobachtet. Der Hauptgrund, warum die Technologie auf der Strecke geblieben ist, liegt in der sich ändernden Gerätelandschaft. In der Vergangenheit bestand die Strategie darin, für jede Gerätefamilie eine Plattform aufzubauen. An diesem Ansatz war nichts grundsätzlich falsch. Aber es bedeutet, Technologien zwischen Plattformen zu portieren. Das ist lästig, und nicht selten bleiben Technologien auf der Strecke, weil eine Plattform plötzlich ungenießbar wird (hust - Silverlight).

Microsoft tritt jetzt hinter .Net Core und UWP zurück. Obwohl ich denke, dass diese beiden Plattformen ein und dieselbe sein sollten, bin ich dennoch sehr optimistisch, dass eine bestimmte Technologie, wenn sie entwickelt oder gepflegt wird, auf vielen Plattformen funktionieren wird. Xamarin verstärkt meinen Optimismus weiter.

Es scheint wirklich, dass wir zum ersten Mal in der Geschichte direkt auf eine Sammlung von Technologien starren, die auf einer sehr breiten Palette von CPUs und Betriebsumgebungen funktionieren. Wenn Microsoft dies vorantreibt, wird WF ein Teil davon sein.

Das macht mich warm und flaumig.

:+1: dazu @MelbourneDeveloper und @dmetzgar. Dies ist die Art von Engagement und Dialog, die ich persönlich gerne bei MSFT sehe, anstatt die ignorierten Bitten und unbeantworteten Anrufe seiner leidenschaftlichen Basis ( das ist einfach gemein, das ist gemein, Mann ).

Eine zufällige Nebenbemerkung hier: zu meinem Punkt, dass NodeJS der einzige Geschäftsfall/die einzige Bedrohung ist, die Sie brauchen, ein zufälliger Artikel, auf den ich in letzter Zeit gestoßen bin.

Abschließend zu meinem Punkt "Wenn .NET Core gut genug für EF ist, sollte es gut genug für WF sein" ... wenn WF zu .NET Core gewechselt ist, gibt es eine Möglichkeit, es in EF zu integrieren, damit EF funktioniert? irgendwie als Backend? Das ist ein zwingender Fall genau dort, wenn ja. Wenn nicht, lohnt es sich trotzdem, darüber nachzudenken (siehe: Diskussion/Dialog/Brainstorming/etc). :)

Abschließend zu meinem Punkt "Wenn .NET Core gut genug für EF ist, sollte es gut genug für WF sein" ... wenn WF zu .NET Core gewechselt ist, gibt es eine Möglichkeit, es in EF zu integrieren, damit EF funktioniert? irgendwie als Backend? Das ist ein zwingender Fall genau dort, wenn ja. Wenn nicht, lohnt es sich trotzdem, darüber nachzudenken (siehe: Diskussion/Dialog/Brainstorming/etc). :)

Das ist ein interessanter Gedanke. Was ist Ihr Anwendungsfall für die Integration von EF und WF? Kannst du ein Beispiel geben? Ist das für Ausdauer?

Kannst du ein Beispiel geben? Ist das für Ausdauer?

Zumindest könnte es als Sicherungsmodell verwendet werden, mit dem der Workflow in der Anwendungsdomäne arbeitet. Es könnte höchstens als Speichermechanismus für den Workflow selbst dienen (aber ich würde das nicht empfehlen – Xaml ist dafür viel besser geeignet).

Ich sehe hier ein WPF-ähnliches Paradigma, in dem Sie Workflows in Xaml definieren und sie dann an Eigenschaften von Workflow-Elementen binden können, indem Sie Daten aus Modellentitäten verwenden, die in EF definiert, geändert und gespeichert werden.

Zugegeben, meine Erfahrung mit WF ist hier begrenzt (diejenigen mit umfangreicher Erfahrung könnten sich hier einschalten). Aber wenn es für WPF funktioniert hat, könnte es auch für WF funktionieren. Tatsächlich verwende ich dasselbe Paradigma (d. h. WPF-ähnliche Xaml-basierte Entwicklung) für eine Konsolenanwendung, die ich für mein aktuelles Projekt verwende . Zugegeben, es werden (noch) keine Datenbindungen verwendet, wie ich vorschlage, aber diese lassen sich leicht erstellen, wie uns OmniXaml/Perspex gezeigt hat. :Sonnenbrille:

@Michael-DST Ich würde es vorziehen, zu viele Integrationen zu vermeiden. WF sollte ein eigenständiges NuGet-Paket sein. Die gemeinsame Integration von WF und EF sollte ein separates Projekt sein. Fangen Sie an, zu viele Dinge zu kombinieren, und Sie könnten bei Oslo landen.

Ich stimme @dmetzgar zu :+1:

EF ist ein Speicher-/Persistenzanbieter. Es sollte ein Diff-NuGet-Paket sein und zur Laufzeit injiziert werden. WF muss nur eine Reihe von Schnittstellen bereitstellen und das ist alles.

Wir haben es mit den Speicheranbietern auf Microsoft Orleans ziemlich gut hinbekommen.

@dmetzgar (und @galvesribeiro) stimmten zu. Ich schlage keine erforderliche Integration vor, sondern einen möglichen Anwendungsfall/ein Wertversprechen. (Siehe: Brainstorming. :smile:)

Was ist Ihr Anwendungsfall für die Integration von EF und WF? Kannst du ein Beispiel geben? Ist das für Ausdauer?

Dem möchte ich mich anschließen! Auch dies bezieht sich auf die Erfahrung meines Unternehmens. Letztendlich möchten wir EF für die Persistenz von Daten in Inline-Datenbanken wie SQLite für gelegentlich verbundene Apps verwenden. Letztendlich würden bei UWP/.Net Core EF, SQLite, Azure Mobile Services und WF harmonisch zusammenarbeiten. Ich würde mich wiederholen, wenn ich erklären würde, warum wir das wollen, aber ich kann erklären, warum EF und WF gut zusammenarbeiten würden. Obwohl wir eine Einschränkung in EF gefunden haben, die uns in der Vergangenheit aufgehalten hat – und das ist der andere Grund, warum wir unser eigenes ORM erstellen mussten.

Wir haben ein System, in dem der Datenzugriff Ereignisse wie „BeforeLoad“, „BeforeSave“ usw. auslöst. Wir hinterlassen Haken in diesen Ereignissen, damit wir beim Speichern eines bestimmten Datensatztyps benutzerdefinierte Geschäftslogik einfügen können. Derzeit haben wir dies durch die Verknüpfung mit benutzerdefinierten Geschäftslogik-DLLs erreicht. Jeder Kunde hat seinen eigenen Satz benutzerdefinierter Ereignisse. Wir haben auch Aufrufe an WF implementiert. So könnten wir beispielsweise beim BeforeSave-Ereignis eine Validierung vornehmen, indem wir WF aufrufen, das die obligatorischen Felder validiert. Auf diese Weise wurde die Validierungslogik für einen bestimmten Kunden weich codiert. Auf WF mussten wir für diesen Zweck auf lange Sicht verzichten, da es nie auf Silverlight implementiert wurde, aber es wäre schön gewesen, es dort als Option zu haben.

Wie auch immer, ich denke, dass dies eine ziemlich universelle Anforderung für jede App ist. Im Allgemeinen möchten Sie immer eine Schicht direkt über der Datenschicht, die die in die Datenbank eingehenden Daten validiert oder die allgemeine Geschäftslogik ausführt. Beispielsweise haben wir Geschäftslogik für einige Kunden, die E-Mails versenden, wenn ein Datensatz eines bestimmten Typs zur Datenbank hinzugefügt wird. Dies könnte in WF erfolgen. Es wäre großartig, so etwas zu implementieren, wenn EF und WF harmonisch zusammenarbeiten.

Leider habe ich nie eine Möglichkeit gefunden, dies mit EF zu tun, selbst auf .Net. Das Problem, das ich gefunden habe, war, dass EF Ihnen nicht mitteilt, wann ein Datensatz eines bestimmten Typs gespeichert werden soll. Wenn Sie also beispielsweise ein neues „Task“-Objekt erstellen und dieses mit EF in der Datenbank speichern, wird kein von EF ausgelöstes Ereignis mit etwas wie „RecordInserted". Dies würde es uns ermöglichen, Hooks in den Datenzugriff einzubauen, sodass benutzerdefinierte Geschäfte eingefügt werden könnten. Das ist also einer der Gründe, warum wir uns nie für EF entschieden haben. Schade, denn die Entwicklung unseres eigenen ORM hat Jahre gedauert, um es zu verfeinern.

Apropos „Business Case“ von NodeJS: Wie NodeJS .NET in 3 einfachen Diagrammen dominiert

Geduldiges Warten auf dieses GitHub-Repo. Ich habe gerade erst festgestellt, dass WF nicht auf .NET Core portiert wurde, was seine Lebensfähigkeit für unser Produkt ziemlich zerstört hat. Was schade ist, da wir die Änderungen an ASP.NET Core und die gesamte plattformübergreifende, abgespeckte, modulare Idee von .NET Core lieben, aber wir brauchen WF, da es die Grundlage unseres gesamten Produkts ist.

Ich denke, es ist mir ehrlich gesagt egal, ob dies der WWF ist oder ob es sich um eine andere gut unterstützte Workflow-Engine handelt, aber ich denke, aus Gründen der Erweiterbarkeit könnte ein Workflow absolut riesig sein.

+1

Wir haben die dynamische Generierung (basierend auf importierten externen Regeln) und das Laden von Workflows als WCF-Dienste verwendet. Es wäre super, wenn wir ein solches Modell in .net Core verwenden könnten!
Übrigens - was ist das Problem beim Importieren von Assemblys von Full .Net? Wenn es sich hauptsächlich um IL-Code handelt, warum läuft es dann nicht in .net Core?

+1

@dmetzgar Es ist unglaublich spannend, https://github.com/dmetzgar/corewf zu sehen! Aus der Readme-Datei war ich überrascht zu sehen, dass eine Portierung des WF-Teams nicht viel Anklang fand. Vor allem angesichts der jüngsten Powershell-Portierung mit Powershell-Workflow, der auf das vollständige Framework beschränkt sein wird – Linux und Mac sind offensichtlich keine großen Ziele, aber Nano-Server würde ich mir vorstellen, dass sie für Powershell enorm wichtig sind. Dort wird auch erwähnt, dass Sie Alternativen zu XAML untersuchen, die andere Xaml-Implementierungen enthalten, wie z. B. Portable.Xaml unterstützt beispielsweise bereits Profile 259, das mit CoreCLR kompatibel ist?

@watertree Portable.Xaml und andere XAML-Implementierungen mit .NET Core-Unterstützung, die ich bisher gesehen habe, haben alle ein fehlendes Feature. Sie implementieren das Attribut x:Class="" nicht. Es ist für WPF unnötig, aber für WF von entscheidender Bedeutung. Ein XAML-Workflow hat normalerweise

PowerShell Workflow bietet eine wirklich gute Möglichkeit, Workflows in Skripten zu definieren. Es ist viel sauberer, als dasselbe in XAML oder C# zu schreiben. PSWF konvertiert dieses Skript jedoch im Hintergrund in eine XAML-Datei. Damit PSWF auf Nano funktioniert, müssten sie ihre vorhandene Pipeline und WF-Laufzeit ersetzen, damit XAML nicht verwendet wird. Und es gibt wirklich nicht genug Druck von Kunden, PSWF auf Nano zu haben.

In Bezug auf Alternativen zu XAML habe ich viele Meinungen dazu. Mein Problem mit XAML ist, dass es in WF eingebettet ist. Mit dem alten WF, das in .NET 3.5 veröffentlicht wurde, gab es mehr Ermutigung vom WF-Team, jedes gewünschte Format in einen Workflow zu konvertieren. Sie verwendeten das Beispiel der Konvertierung von Visio-Diagrammen in Workflows. Aber als die neue WF 4.0 kam, konzentrierte sich alles auf XAML. Haben Sie schon einmal versucht, einen Workflow in XAML von Hand zu schreiben? Passiert nicht. Dann gibt es Debug-Symbole und Viewstate. Und versuchen Sie, eine Version eines XAML mit einem Vergleichstool mit einer anderen zu vergleichen.

Ich denke wirklich, dass die Verwendung von XAML zum Definieren von Workflows eine Frage des Einbindens eines NuGet-Pakets sein sollte. Es sollte empfohlen werden, andere Möglichkeiten zum Speichern von Workflow-Definitionen zu schaffen. Vielleicht brauchen Sie etwas, das gut komprimiert. Vielleicht brauchen Sie Sicherheit und erlauben nur eine begrenzte Anzahl von Aktivitäten. Ich habe lieber Optionen.

Sie implementieren das Attribut x:Class="" nicht

Tatsächlich hat kompiliertes Xaml (baml?) in allen Xaml-Varianten, die ich gesehen habe, auffallend gefehlt. Ich habe darüber nachgedacht, mich in meiner Freizeit damit zu beschäftigen, aber ich habe das Gefühl, dass es bald, vielleicht im nächsten Jahr, in irgendeiner Form verfügbar sein wird. Auch das XAML-System von Xamarin unterstützt dies, aber es ist geschlossen und überhaupt nicht erweiterbar/zugänglich.

Haben Sie schon einmal versucht, einen Workflow in XAML von Hand zu schreiben? Passiert nicht.

Wahr. Ironischerweise ist WF der umfassendste Wohltäter (bei weitem) jeder Xaml-Integration. Zu einem Fehler vielleicht. Es ist eine Schande, dass Xaml so entwickelt wurde, dass es extrem Designer-freundlich ist, aber die Tools rund um WF sind für handgeschriebene Szenarien und sogar für den Designer selbst etwas unerschwinglich. Es scheint, dass sie wirklich darauf abzielten, es zu einer visuellen Programmiersprache zu machen, aber ohne die erhebliche Menge an Unterstützung/Ressourcen, die es zum Erfolg benötigen würde.

Ich denke wirklich, dass die Verwendung von XAML zum Definieren von Workflows eine Frage des Einbindens eines NuGet-Pakets sein sollte.

Ich mag wie Du denkst! 👍

Übrigens, wenn Sie dies noch nicht getan haben, springen Sie bitte zur System.Xaml-Portierungsanforderung / -ausgabe und stimmen Sie die Ausgabe ab, wenn Sie können. Ich für meinen Teil würde wirklich gerne ein neues quelloffenes, plattformübergreifendes Xaml-System sehen, das das Beste aller bekannten Systeme nimmt und es als eine offizielle und maßgebliche Variante bereitstellt. Wäre das nicht schön? 😛

Wie auch immer, es sind jetzt bis zu 74 Stimmen. Was ziemlich krass ist, wenn man bedenkt, dass die Abstimmung begann, bevor GitHub-Reaktionen verfügbar waren:
https://github.com/dotnet/corefx/issues/5766

17 Herzen sind auch ziemlich cool. :)

Vielen Dank für jede Unterstützung (und fortgesetztes Feedback)!

@dmetzgar Danke für deine Bemühungen! Kommentieren Sie einfach XAML -- Früher hatte ich eine sehr negative Sicht auf XAML, weil die meisten Dateien, mit denen ich mich befasste, mit visuellen Designer-First-Dialekten von XAML erstellt wurden.

Das änderte sich, als ich anfing, mit Xamarin.Forms zu programmieren, das neben XAML auch eine sehr schöne deklarative C#-API hat. Es gibt keinen visuellen Designer (nur eine Vorschau, die viel später als die XF-Version kam). Überraschenderweise arbeite ich viel lieber an ihrem XAML-Dialekt als an C#-Code! Sie haben einen großartigen Job gemacht, und Sie haben nicht eine Menge Designer-Metadaten, die die Bedeutung des Markups verunreinigen. Unterstützende Frameworks wie Prism.Forms tragen auch dazu bei, die Waage drastisch in Richtung XAML zu kippen, da es sehr einfach ist, Code ohne Code-Behind zu schreiben.

Ich glaube also nicht, dass XAML per se das Problem ist, sondern Dialekte, die zuerst zur Unterstützung von Designern entwickelt wurden – XF ist für mich ein ziemlich überzeugender Beweis.

Irgendwelche Neuigkeiten zu diesem Thema?

Nun, CoreWF lebt und existiert unter https://github.com/dmetzgar/corewf

Es bleibt abzuwarten, ob DynamicActivity nun mit den neuen Composition APIs portiert werden kann, die dem Kern und dem .net-Standard 2.0 hinzugefügt wurden.

Wäre toll, wenn wir vom WF-Team hören würden.

Zu diesem Thema wurden viele interessante und nützliche Kommentare abgegeben. Ich für meinen Teil glaube, dass nur die WF-Laufzeit und die Ereignisverfolgung (d. h. ohne XAML, Transaktionen oder WCF-Bits) auf .NET Core portiert werden, und ich bin froh, dass dies (irgendwie) getan wurde.

Ich stimme zu, dass WF.Core offiziell existieren muss. Wenn es die Möglichkeit gäbe, eine flexiblere Methode zum Definieren der für Entwickler funktionierenden Workflows zu schaffen, wäre dies meiner Meinung nach der beste Ansatz. Ich stimme zu, dass XAML eine harte Nuss zu knacken ist, wenn MS sagt, dass sie System.XAML nicht portieren werden, aber ich möchte WF.Core wirklich in meinen .NET Core-Web-API-Projekten sehen.

Ich denke, der große Elefant im Raum hier ist, dass es nicht genug Traktion gibt, um dieses Projekt auf den Weg zu bringen, weil MS und andere sehr schweigsam gegenüber Informationen über WF waren. Sicher, es gibt einige Beispiele auf MSDN, aber es gibt sehr wenige Informationen in Form von Büchern oder anderen soliden (geprüften) Materialien.

Ich bin auf jeden Fall bereit, Zeit zu investieren, um zu helfen, dies zum Leben zu erwecken.

Daher sollte OmniXAMLv2 (es befindet sich in einem Zweig im Github-Repo), das sich noch in der Entwicklung befindet, x:Class-Attribute unterstützen (https://github.com/SuperJMN/OmniXAML/issues/12). Vielleicht können wir es für (Core)WF verwenden?

@ewinnington Danke für den Hinweis!
Das ist definitiv ein großer Teil davon. Außerdem verfügt .NET Standard 2.0 über eine Reihe von System.ComponentModel-Typen, die von WF verwendet werden. System.Transactions ist bereits in Corefx enthalten. Das einzige, was fehlt, ist WCF ServiceHost.

WCF ServiceHost kann IMHO warten. Das Hosting-Modell sollte wie alles andere in der .Net Core/Asp.Net-Welt agnostisch sein, denke ich ...

@galvesribeiro Ich stimme dem zu, angesichts der Tatsache, dass es viele andere Möglichkeiten gibt, wie WF in einer .NET Core-Welt arbeiten kann, einschließlich Web-API.

Jep. Ich stimme jedoch @dmetzgar zu, dass es eine Reihe von Kunden gibt, die heute WCF verwenden, daher ist die Unterstützung ein Muss, aber auch hier kann es zu Verzögerungen kommen ...

Tatsächlich sollten das Hosting und die "Designsprache" von der Kernlaufzeit abstrahiert werden ...

Wir verwenden WCF mit WF, würden aber gerne zu etwas wie WebAPI wechseln, wenn WF in Core wäre. Tatsächlich haben wir weitergemacht und unabhängig davon von WCF zu einer RESTful-Alternative gewechselt. Wir ziehen eine Menge Wert aus Workflow und es ist eine meiner bevorzugten .NET-Technologien!

Ich denke auch, dass WF im Kern weder von xaml noch von wcf abhängig sein sollte, es wäre sehr wertvoll, nur die wf-Engine und das Objektmodell zu haben. Sie würden das dann als Middleware auf dem Kern von asp.net ausführen, insbesondere mit der neuen Pipeline-/Nicht-http-Arbeit, die für Kestrel kommt.

+1 für das Vorhandensein und die Unterstützung von WF-Engine und Objektmodell in Core. Wir können auch XAML und WCF umgehen.

XAML ist cool – es lässt Sie dynamische Konfigurationen vornehmen – in einem Projekt laden wir XAML-Workflows aus Dateien und sie werden als WCF-Endpunkte dargestellt. Und diese XAML-Dateien werden automatisch aus der Registrierung verfügbarer Dienste generiert. Die WCF-Dienste erhalten also Endpunkte:
https://[base]/wcf/[service_id1]
https://[base]/wcf/[service_id2] ...
Wäre schön, solche Funktionen in .Net Core zu haben :)
Oh ... ich habe es hier schon einmal geschrieben ... :)))

Ja, da ich mich hier mit dem Land vertrauter gemacht habe, ist die Xaml-Unterstützung in WF per se nicht so wichtig, sondern es ist wirklich wichtig, System.Xaml zu portieren, das ist der wichtige Teil. Da dies eindeutig in einem anderen -- und ich freue mich sehr, sagen zu können, dass es ziemlich beliebt ist (aber lass dich davon nicht davon abhalten, @freerider7777! :smile:) -- zu stimmen, bin ich dafür, WF als Abhängigkeit zu machen kostenlos wie möglich, um sicherzustellen, dass es in .NET Core aufgenommen wird. 👍

@Mike-EEE Ich habe dort vor langer Zeit hochgestimmt!! :)

Da Workflows durch Code erstellt werden können, wäre die Verwendung einer Fluent-API ähnlich wie EF Core eine gültige Option, um WF Core zum Leben zu erwecken? Dann könnte die Serialisierung/Deserialisierung für die Laufzeit nachträglich konstruiert und viel einfacher zu implementieren sein?

FluentAPIs ... so heiß im Moment. Oder zumindest, seit sie gegründet wurden. 😄

FluentAPIs, Builder Pattern, beide sind im Wesentlichen gleich. Die Bereitstellung einer codebasierten Methode, die verkettebar und einfach zu verwenden ist, sollte meines Erachtens ein solides Prinzip dahinter sein.

Ohne einen Designer ist alles nutzlos. Natürlich können wir alles selbst codieren – die ganze Logik, alle Ketten und so weiter (mit oder ohne fließend). Aber was ist cool in WF - Sie können den Verarbeitungsfluss visuell sehen. Es ist das Bindeglied zwischen Managern (und anderen „Stakeholdern“) und Entwicklern! Manager verstehen den Code nicht, aber diese High-Level-Diagramme sind für alle verständlich. Mit WF benötigen Sie keine separaten Diagramme (Visio oder andere), wenn sie getrennt sind - sie sind normalerweise nicht mit echtem Code synchron :)

@ freerider7777 Die Serialisierung von WF-Definitionen ist nicht auf xaml beschränkt (siehe https://github.com/dmetzgar/corewf von @dmetzgar ). Es könnte auch für JSON implementiert werden.. und dies würde die Möglichkeit eröffnen, bestehende Projekte wie NodeRed http://nodered.org/ zu integrieren/forken, das in vielerlei Hinsicht den WF Designer-Funktionen und UX ähnelt (+ es würde auch laufen in einem Webbrowser, Erschließung neuer Anwendungsfälle für WF)

Ich denke, es ist am besten, WF auf den .NET-Standard zu portieren und nicht nur auf .NET Core. Die zuvor verlinkte WF-Laufzeit funktioniert bereits auf .NET Standard 1.3 (wir können niedriger gehen, wenn wir die WriteLine-Aktivität löschen). Mit dem bald erscheinenden 2.0-Standard haben wir die Möglichkeit, viele Funktionslücken wie automatische Cache-Metadaten, DynamicActivity und Transaktionsbereiche zu schließen. Wir sollten Komponenten in verschiedene Pakete aufteilen, damit es ein Pay-for-Play-Modell gibt: Wenn Sie nur Laufzeit wollen, können Sie beim 1.3-Standard bleiben, aber wenn Sie DynamicActivity wollen, brauchen Sie 2.0-Standard und Sie schränken Ihre Plattformen ein.

Es gibt definitiv viel Raum für Verbesserungen im WF-Laufzeitcode. Beispielsweise würde ich Aktivitätserweiterungen durch Abhängigkeitsinjektion ersetzen. Fluent API wäre interessant, um Workflows in Code zu schreiben (und schauen Sie sich in diesem Sinne https://github.com/knat/Metah von @knat an), aber ich stimme @ freerider7777 zu, dass die Möglichkeit besteht, mit Ihrem Management und Ihren BAs mithilfe von Diagrammen zu kommunizieren was tatsächlich in der Produktion verwendet wird, ist ein großes Plus. @helmsb hat viel Erfahrung damit (siehe http://dotnetrocks.com/?show=1236).

Ein neuer Designer müsste eine Webanwendung sein. Die Ausrichtung auf WPF oder UWP würde die Zielgruppe einschränken. Wenn sich OmniXAML durchsetzt, können Benutzer Workflows mit den gleichen Tools erstellen/bearbeiten wie heute (VS oder neu gehostete Lösung). Das Problem besteht darin, dass, da der aktuelle Designer in .NET Framework integriert ist, alle Funktionen oder Korrekturen auf eine .NET Framework-Version warten müssten. Es ist gut genug für den Anfang, aber keine langfristige Lösung. @erikcai8 hat einige Experimente mit einem Webdesigner gemacht, ähnlich wie nodered. Ich werde sehen, ob ich ihn zum Teilen überreden kann.

Für das Workflow-Designer-Frontend gibt es einen ersten Versuch auf Github: https://github.com/gary-b/WF4JSDesigner und Sie können es live verwenden http://gary-b.github.io/WF4JSDesigner/

So sieht es schon aus:

@ewinnington : Schön, den Web-Workflow-Designer POC zu sehen. Ich habe auch eine andere gebaut, wie unten im Screenshot gezeigt.

AWWWW SCHNAPP!!! ES IST ein WF POC-OFF!!! 🎉

Hehehe. Hey @erikcai8 wo ist der Export nach Xaml??? Ha ha. Nur umdrehen Sie Trauer. Sortiert. 👼

Beide Versuche sehen toll aus. Gut, die beiden zu sehen. Das erscheint jetzt irgendwie offensichtlich, aber wie großartig wäre es gewesen, einen webbasierten visuellen Designer in der ursprünglichen WF zu haben? Alles ist gesperrt und geladen, bereit zu gehen, Sie besuchen einfach eine URL. Ich denke, das hätte beim Branding und der Adoption wirklich geholfen. Leider scheint jeder auf dem TFS-basierten Editor gelandet zu sein, der sehr schwierig einzurichten war und zu sehr ausführlichem Xaml führte. Dies war eine schlechte Erfahrung für den typischen Entwickler, der sich damit befassen musste, und gab allem, was mit der Erfahrung (WF oder Xaml) zu tun hatte, einen schlechten Ruf.

Das, OTOH, scheint ein großartiger Ansatz zu sein. Lassen Sie die Renaissance beginnen!

@Mike-EEE Mein E2E-Experiment hat die Workflow Core Engine verbessert, um den JSON-Workflow nativ zu laden, sodass das XAML-Format nicht erforderlich ist. Der XAML-Workflow konnte jedoch aus der Workflow-Engine exportiert werden, sobald der JSON-Workflow geladen wurde.

Das ist der Punkt. Wir sollten die Laufzeit und ihr Objektmodell nicht an den Designer und das serialisierte Format binden, wie es in WF 4.5 war ...

@galvesribeiro Habe den Punkt verstanden. Das Experiment ging jedoch davon aus, dass das JSON-Format als weitere Option für Workflow Core unterstützt wurde. Wie oben besprochen, ist XAML noch nicht für die neuesten Webtechnologien geeignet.

Wir lieben WF, bitte portieren Sie es auf .NetCore.

Wir brauchen einen webbasierten Workflow-Designer. Die Unterstützung für .NET Core zum Ausführen der Workflows wäre doppelt großartig. Los Los

Daniel Gerlag arbeitet hier an einer wirklich netten, leichten, Core-kompatiblen Workflow-Engine:

https://github.com/danielgerlag/workflow-core

Daniel hat in sehr kurzer Zeit einen langen Weg zurückgelegt. Ich möchte Sie nachdrücklich dazu ermutigen, es sich anzusehen und an diesem Projekt teilzunehmen, wenn Sie darin Verdienste finden.

Warum bauen Sie bei all diesem Interesse nicht einfach eine Net Core-kompatible Engine von Grund auf neu?

@ccpony Weil Sie CoreWF jetzt auf dot net core verwenden können -> https://github.com/dmetzgar/corewf . Die zentralen Komponenten sind portiert und funktionieren. Auf den .net Standard 2.0 warten einige Dinge.

@ewinnington Danke für die Antwort, aber ich verstehe das nicht. WF war kein erfolgreiches MS-Produkt und MS hat jahrelang nichts unternommen, um es zu verbessern. Die Community ist voll von Zeugnissen von erprobten und fehlgeschlagenen Implementierungen. Es ist im Unternehmen nicht weit verbreitet. Es ist unhandlich, überfunktioniert, schwer zu erlernen und (noch) fehlerhaft. Seine Schnittstelle ist weithin verleumdet. Es scheiterte, eine endbenutzerfreundliche Technologie zu werden. Seine Interna sind im Wesentlichen eine Blackbox, die nicht einfach verbessert werden kann. Es ist LANGSAM mit allem anderen als einfachen Workflows. Es ist sehr schwer zu testen. Es basiert auf alten Technologien (WCF, XAML). Seit Ron Jacobs krank wurde, hat WF gelitten und hat keinen Freund bei MS.

Meiner Einschätzung nach hat WF versucht, alles für alle zu sein und hat sich tatsächlich als wenig für alle herausgestellt. Microsoft hat es so gut wie fallen gelassen. Warum sollten wir so etwas wiederbeleben wollen? Wenn irgendeine wichtige Technologie ein Umdenken und Neuschreiben erfordert, DAS IST ES.

Schauen Sie sich das junge Projekt von Daniel Gerlag an. Es ist neu und unreif. Aber es erfordert einen modernen Ansatz für den Workflow, der leicht zu verbessern wäre. Wenn jeder hier aufhören würde, ein komplexes, veraltetes und ehrlich gesagt übertechnisiertes Projekt nachzurüsten, und sich stattdessen auf etwas Neues und Besseres konzentrierte, dann hätten wir eine Chance, an einem lohnenden Ort zu landen - - schrittweise zu bauen eine Weltklasse-Workflow-Engine, anstatt zu versuchen, einen Giganten von Anfang an neu zu schreiben. Ehrlich gesagt bewundere ich jeden hier, der sich SEHR lohnenswert anstrengen möchte - - ENDLICH ein ausgereiftes, funktionales, leichtes, von Osten zu lernendes, plattformübergreifendes Workflow-Tool (Zustandsmaschine?) Zu erstellen. Aber es tut mir leid, das sagen zu müssen, wenn Sie alle diesen Weg weitergehen, werden all Ihre Bemühungen einfach ins Nichts verblassen. MHO.

@ccpony Danke, dass du deine Meinung geteilt hast. Würden Sie bitte erläutern, auf welche Fehler Sie sich beziehen? Wenn wir etwas tun können, um Probleme in .NET Framework zu beheben, würde ich mich über eine Nachricht freuen.

@dmetzgar Danke für die Antwort, Dustin. Während der Zeit, in der ich versuchte, WF-Anwendungen zu entwickeln, bin ich auf Fehler gestoßen. Nicht nur unerwartetes Verhalten, sondern es kam mehrfach vor, dass eine komplexe WF „explodierte“ und Fehler in der XAML-Benutzeroberfläche generierte, die im XAML-Code schwer zu beheben waren. Ich habe nie wirklich großes Vertrauen in die WF-Technologie entwickelt. Wirklich, es kam gerade zu dem Punkt, an dem ich das Gefühl hatte, mit einem 800-Pfund-Gorilla zu ringen – für jeden Schritt nach vorne würde ich am Ende zwei Schritte zurückgeworfen werden.

Ich weiß, das ist nicht das, wonach Sie in Ihrer freundlichen Bitte suchen, dass ich näher auf Fehler eingehe. Ehrlich gesagt könnte ich diese Fehler umgehen. Aber ich habe WF schließlich aus all den anderen Gründen aufgegeben, die ich in meinem vorherigen Beitrag erwähnt habe.

Sie führen diese Bemühungen an und ich begrüße Sie dafür. Aber sicherlich kommt der Punkt, an dem der Versuch, eine komplexe Technologie nachzurüsten, kontraproduktiv wird. Wenn ich diesem ganzen Thread folge, kann ich einfach nicht anders, als das Gefühl zu haben, dass der Fortschritt sehr langsam ist - - wenn überhaupt - - und schließlich nichts von all dem zu sehen sein wird. Ich halte es für sehr unwahrscheinlich, dass alte Workflows auf das portiert werden können, was hier produziert wird. Die Leute in diesem Thread sprechen über Client-basierten Workflow (dh JavaScript), REST-Kompatibilität, Reduzierung von Abhängigkeiten, Cross-Plattform usw. Zum Beispiel ist XAML ein so wichtiger Teil der alten WF-Technologie, was es nützt, WF auf Core zu portieren XAML wird nicht dabei sein?

Also, Dustin, ich muss Sie Folgendes fragen: Hier sind wir 18 Monate in diesem Projekt und es scheint einfach keinen Konsens darüber zu geben, dass wirkliche Fortschritte gemacht werden. Ich respektiere Ihre Bemühungen und kann sehen, dass Sie ein großartiger Programmierer sind - - aber hier ist meine Frage: Wäre es nicht VIEL sinnvoller, all diese Energie und Begeisterung zu sammeln und etwas Neues zu schaffen?

@ccpony Die Diskussion in diesem Thema dient der Unterstützung von WF .Net Standard und nicht umgekehrt.

Nur neugierig... Haben Sie jemals eine Sharepoint-Bereitstellung in Aktion verwendet oder gesehen? Wenn Sie dies tun, werden Sie sehen, dass es wirklich stark auf WF lastet. Haben Sie jemals eine BizTalk-Bereitstellung gesehen? Das gleiche.

Dies sind wichtige MSFT-Produkte in der Unternehmenswelt, also ja, es gibt Benutzer, die sich für WF interessieren, und es wird dafür verwendet. Es ist kein aufgegebenes/aufgegebenes Projekt, wie Sie sagten.

Wenn Sie sich das @dmetzgar- Repo ansehen, werden Sie feststellen, dass einige Dinge ähnlich sind oder einige Verhaltensweisen von der alten Inkarnation von WF erben, Sie werden jedoch auch feststellen, dass es neu gestaltet wurde, um leicht zu sein. Die Persistenz ist entkoppelt und die Leute können leicht neue erstellen. Der Designer ist entkoppelt und die Leute haben bereits mehrere Tests erstellt.

Ich verstehe Ihre Frustration, etwas Neues zu wollen. Glaub mir, ich will das auch. Aber man muss @dmetzgar und sein Team verstehen. Dies hat keine Priorität, da 95 % der Kunden Benutzer des alten WF sind, das im Wesentlichen auf BizTalk und Sharepoint läuft, wie ich bereits erwähnt habe. Ich habe die alte WF jahrelang in einer Umgebung mit sehr hohen TPS (Bank- und Finanztransaktionen) verwendet und sie hat mir sehr gute Dienste geleistet.

Meine neue Technologie funktioniert mit .Net Core, und der einzige Grund, warum ich sie jetzt nicht wieder verwende, ist, dass wir sie noch nicht für .Net Core haben.

Was ich @dmetzgar bereits vorgeschlagen habe, ist, WF Repo zu .Net Foundation zu bringen, Meilensteine ​​zu definieren, den Code dort abzulegen und Aufgaben als Issues hinzuzufügen und als up-for-grabs zu markieren, damit die Community damit beginnt. Das erfordert jedoch noch etwas Zeit von seinem Team, um diese Arbeit zu erledigen, und diese Zeit haben sie möglicherweise (noch) nicht zur Verfügung.

@galvesribeiro Ich verstehe deinen Punkt. Ja, ich habe SharePoint-Bereitstellungen geschrieben. Und ich HABE BizTalk-Bereitstellungen in Aktion gesehen ( * Shutter *). Ich verstehe die Beziehung zwischen SharePoint und WF. (Ich weiß nicht, was Sie meinen, wenn Sie vorschlagen, dass BizTalk irgendwie auf WF angewiesen ist. Dies ist nicht der Fall.)

Aber ich muss dir in einem wichtigen Punkt widersprechen: WF IST ein aufgegebenes/aufgegebenes Projekt. Ich verstehe die Bedenken der SharePoint-Entwickler an dieser Stelle wirklich. Es gibt keinen Grund zu der Annahme, dass MS die Fähigkeiten von WF in SharePoint verbessern wird. Ich verstehe nicht, warum Sie glauben, dass die Bemühungen von @dmetzgar irgendetwas mit der Zukunft von SharePoint (oder BizTalk) zu tun haben werden. Es ist nicht so, als würde MS SharePoint mit dem Code von @dmetzgar nachrüsten. Entschuldigung, aber die Zukunft von SharePoint hat nichts mit den Bemühungen zu tun, die hier unternommen werden.

Es kommt also nur darauf an, ob aus all dem eine gute Workflow-Engine entsteht. Und ich behaupte, dass der Versuch, einen Giganten wie WF in die Zukunft zu zwingen, nicht die beste Vorgehensweise ist. Besser von Grund auf neu bauen.

@ccpony Ich möchte Sie daran erinnern, dass es hier zahlreiche Menschen gibt, die aktiv versuchen, dieses Projekt zum Leben zu erwecken, und einige investieren tatsächlich Zeit, um es zu verwirklichen. Während Sie persönlich WF als ein gescheitertes Produkt von Microsoft betrachten, bleibt es weiterhin ein Teil von .NET und wird nicht nur von uns hier verwendet.

Dieser Thread sollte für konstruktive Kritik und Beiträge sein, um den Übergang Wirklichkeit werden zu lassen, und nicht für einen Schlag auf andere oder das Produkt selbst. Obwohl Ihre Ansichten respektiert werden, beachten Sie, dass es Ihre eigenen sind und dass andere möglicherweise anders darüber denken, wie wichtig WF ​​für sie ist.

Wir freuen uns sehr über Ihren Beitrag zur Verbesserung des Produkts und darüber, wie Sie denjenigen, die sich aktiv an dem Versuch beteiligen, am besten helfen können.

Danke =^_^=

@ccpony

(Ich weiß nicht, was Sie meinen, wenn Sie vorschlagen, dass BizTalk irgendwie auf WF angewiesen ist. Dies ist nicht der Fall.)

Entschuldigung, ich drücke mich schlecht aus (ich bin auf dem Handy). Ich hatte eine Anwendung, die beide zusammen verwendet, und ich kenne viele andere, die das auch tun.

Es gibt keinen Grund zu der Annahme, dass MS die Fähigkeiten von WF in SharePoint verbessern wird.

Ich sage nicht, dass es das wird. Ich sage, dass das Team, das mit WF Today arbeitet, sich vollständig auf die Unterstützung von Sharepoint-Bereitstellungen konzentriert. Sogar die neueste Version von Sharepoint verwendet dieselbe/aktuelle Version von WF.

Ich verstehe nicht, warum Sie glauben, dass die Bemühungen von @dmetzgar irgendetwas mit der Zukunft von SharePoint (oder BizTalk) zu tun haben werden.

Ich sage nicht, dass es die Zukunft von Sharepoint beeinflussen wird. Ich sage, das Team ist damit beschäftigt, Sharepoint zu unterstützen, wenn ich das richtig verstanden habe. ( @dmetzgar kann mich korrigieren, wenn ich falsch liege)

Es ist nicht so, als würde MS SharePoint mit dem Code von @dmetzgar nachrüsten. Entschuldigung, aber die Zukunft von SharePoint hat nichts mit den Bemühungen zu tun, die hier unternommen werden

Ob MS WF vNext auf Sharepoint vNext verwenden wird oder nicht, können nur sie mit Sicherheit sagen. Auch hier besteht das Problem darin, dass das WF-Team nicht in der Lage ist, mit beiden umzugehen.

Es kommt also nur darauf an, ob aus all dem eine gute Workflow-Engine entsteht. Und ich behaupte, dass der Versuch, einen Giganten wie WF in die Zukunft zu zwingen, nicht die beste Vorgehensweise ist. Besser von Grund auf neu bauen.

Niemand portiert es so wie es ist. Das Repo von @dmetzgar ist ein Beweis dafür, dass es von Grund auf neu gestaltet wird. Auch hier ist das Problem der Rückstand und die Bandbreite, die das Team mit beiden Dingen bewältigen muss. Aus diesem Grund habe ich vorgeschlagen, es auf der dotnet Foundation zu „öffnen“ und es zu einer großen Community-getriebenen Anstrengung mit Anleitung und Kuration des WF-Teams zu machen, damit wir versuchen, ihre Zeitpläne so wenig wie möglich zu beeinflussen.

Nochmals, wie @InariTheFox und ich selbst erwähnt haben, ist dieser Thread ein Vorstoß für die Portierung, was nicht unbedingt bedeutet, dass die alte Fersion mit all diesen Funktionen zwangsweise auf die neue Version übertragen werden muss. Es ist jedoch wichtig zu verstehen, dass die Leute viel Mühe (und Geld) in ihre aktuellen WF-basierten Produkte investieren, daher ist @dmetzgar darauf bedacht, so viel Kompatibilität wie möglich mit den alten Workflows zu gewährleisten, ist in der Tat etwas, worauf man achten muss.

In Ordnung. Ich sehe die Leidenschaften hier. Wenn es einen guten Ersatz für WF gäbe, der all die zuvor erwähnten Probleme angeht, würden wir dieses Gespräch nicht führen. Fürs Protokoll, viele von uns haben sich von WF verabschiedet und haben sehnsüchtig auf das nächste Ding gewartet. Das tat es nie. Nach meinem besten Wissen gibt es KEINE aktuelle, unterstützte, funktionale, .Net-basierte Workflow-/State-Machine-Lösung, die weithin angesehen ist. Bitte haben Sie Verständnis dafür: Ich stehe zu meiner Behauptung, dass WF aus Sicht von Microsoft eine tote Technologie ist.

Aber, nachdem ich das gesagt habe, hilf mir bitte zu verstehen. Funktioniert das Repo von @dmetzgar so wie es ist? Wie schreibt man damit Workflows? Ich sehe keinen Beispielcode und es gibt keine Dokumentation. Wie würde ich vorgehen?

Ich denke, dass es viele Produkte / Unternehmen gibt, die WF zu einem zentralen Bestandteil ihrer Produktstrategie gemacht haben, es ist nicht nur eine Sharepoint-Abhängigkeit im Support-Modus: In meinem derzeitigen Unternehmen haben wir eine Automatisierungsplattform entwickelt, bei der WF die zentrale Technologie ist (und ich weiß andere 2 Wettbewerber aus diesem Markt, die ebenfalls WF in ihren Produkten verwenden); Ich habe auch mit Leuten gesprochen, die es in der Insurtech verwenden. Ich bin also fest davon überzeugt, dass das Publikum für WF immer noch da ist.

Abgesehen davon scheint .net Core einer der Schwerpunktbereiche von Microsoft zu sein, und in der nächsten Zeit werden viele technische Innovationen hineinfließen; Ich denke, es wäre ein großer Verlust, WF nicht dabei zu haben.

Aus meiner Sicht besteht der richtige Weg, dies zu erreichen, darin, den WF-Kern von xaml unabhängig zu machen und die (De-)Serialisierung von Workflows auch in anderen Formaten (z. B. json) zu erleichtern. Dies würde auch die Implementierung von Szenarien wie Workflow-Designern vereinfachen, die in Webbrowsern gehostet werden. Und mit dem https://github.com/dmetzgar/corewf Repo haben wir einen Ansatzpunkt.

Für diejenigen, die an einem Überblick über den aktuellen Stand von WF interessiert sind (den ich nicht als von MS aufgegeben sehe), habe ich vor einiger Zeit die verfügbaren Informationen zu WF in einem Beitrag und einer Präsentation http://andreioros.com/blog zentralisiert

Wir und unsere Kunden vertrauen auf WF und würden es sehr lieben, wenn es sowohl auf dem Client als auch auf dem Server funktioniert. Eine von XAML und anderen Abhängigkeiten freie WF, die leichtgewichtig ist, aber die Ausdruckskraft der bestehenden WF hat, die auch von der Community mit MS unterstützt wird, wäre in der Tat ein aufregendes und wertvolles Produkt.

Erlauben Sie mir bitte noch einmal zu fragen: Was macht man mit @dmetzgar 's Port, um es zum Laufen zu bringen? Wie ist der aktuelle Stand?

Ich wusste nicht, dass der Port von @dmetzgar in seiner aktuellen Inkarnation tatsächlich verwendbar ist ...

Von @ewinnington oben:

"Denn Sie können CoreWF jetzt auf dot net core verwenden -> https://github.com/dmetzgar/corewf . Die zentralen Komponenten sind portiert und funktionieren. Ein paar Dinge warten auf .net Standard 2.0."

In diesem Fall würde ich auch gerne von seiner Verwendung hören ...

Ja, es ist das Barebone der Kernfunktionalität. Sie können codebasierte Workflows ausführen. Die fehlenden Funktionen von netstandard2.0 beziehen sich hauptsächlich auf die Transaktionsunterstützung.

Das ist eher ein Grund, warum ich immer noch vorschlage, es offen zu starten und die Leute dazu zu bringen, an einem zentralen Ort mitzuwirken. Wenn es verbreitet ist, wird es noch schwieriger, eines Tages in der Zukunft ein Endprodukt zu erreichen.

Stimmen Sie für die Neufassung von WF mit Tests und Unterstützung für moderne Roslyn-Funktionen als Teil von Core. Ich würde gerne sehen, wie Serverless und Container die Architektur beeinflussen könnten, insbesondere die Bereitstellung und Skalierung von Regelsätzen innerhalb bestimmter Domänenkontexte und Geschäftsprozesse. Ich persönlich würde ein prägnantes DSL einem WYSIWYG-Designer vorziehen. Ich persönlich habe den Designer geliebt, aber er fühlte sich fast die ganze Zeit skurril an. WF selbst hatte das Potenzial, extrem solide zu sein, erforderte jedoch tiefes Fachwissen. Tatsächlich erforderte eine große Einführung von WF, die WF Manager und persistente Flows in SQL Server umfasste, MS-Beratung und Fehlerbehebungen. Obwohl ich jetzt seit einigen Jahren Java-Teams unterstütze, behalte ich .NET gerne im Auge, nachdem ich mich etwas mehr als 15 Jahre lang hauptsächlich auf MS-Technologie konzentriert habe. Ich las „Code Generation with Roslyn“ von Nick Harrison (ich habe keine Verbindungen zu ihm oder dem Buch) und fragte mich, ob ich mich noch einmal dem Bereich der Business Rule Engine nähern sollte, was mich dazu veranlasste, mich erneut über das Schicksal von WF zu wundern … Ehrlich gesagt würde ich denken, dass Azure Functions sowohl mit MS-Ressourcen als auch mit der allgemeinen Bereitschaft der Unternehmen konkurriert, umfassende Investitionen in WF überall zu unterstützen. Es scheint offensichtlich, dass sie möchten, dass Sie das verwenden ... also besteht die Lösung vielleicht darin, sich stattdessen auf eine Open-Source-.NET-Version von OpenWhisk zu konzentrieren. Aber in einer containerisierten Welt ... kann ich OpenWhisk einfach als Dienst verwenden. So...

PS Die einfache Unterstützung einer robusten Methode zum Importieren von externalisierten Ausdrücken könnte 60 % der App-Anforderungen da draußen erfüllen, die glauben, dass sie WF benötigen könnten. War es CSharpScript? Eine einfache Methode zum Importieren grundlegender Geschäftsregelkonfigurationen mit einer geradlinigen API würde viel bewirken (verschiedene Persistenz-, Abruf- und Caching-Optionen). Mit verfügbarer virtueller Infrastruktur (Automatisierung über Infrastructure-, Container- und Platform-as-a-Service) könnte sich WF vNext auf die Bereitstellung von Versionsänderungen als Dienst konzentrieren, anstatt zu versuchen, sie in Apps einzufügen (d. h. eine bessere Lösung für WF auf WCF)

Ich interessiere mich sehr für dieses Gespräch. Mein Team hat sich auch mit der Frustration von XAML auseinandergesetzt. Unser Dilemma besteht darin, dass wir unseren eigenen UI-Designer erstellen, damit unsere Kunden ihre eigenen Workflows erstellen können, ohne Visual Studio oder den neu gehosteten Designer zu benötigen. Wir brauchen die Möglichkeit, XAML-Blöcke in wiederverwendbare Bits zu speichern, damit der Kunde diese Bits nicht immer neu schreiben muss (stellen Sie sich das als Workflow-Funktionen vor). Dazu müssen wir wissen, wie XAML-Blöcke zusammengeführt werden, was, wie wir gelernt haben, äußerst frustrierend ist. Wir beabsichtigen, eine Abstraktion zu schaffen, bei der wir uns einfach auf ein Datenbankmodell unserer verschiedenen Aktivitäten und deren Verknüpfungen verlassen und XAML insgesamt ignorieren. Wir werden dann die Aktivitäten usw. jedes Mal programmatisch erstellen, wenn ein Workflow ausgeführt wird. Bei der Recherche zu diesem Ansatz bin ich auf diesen Thread gestoßen. Bleiben Sie im Gespräch, ich bin sehr daran interessiert, die Meinungen anderer zu hören.

@erikcai8 Workflow-Designer ist eine sehr schöne Idee. Kann ich die Quelle Ihres Workflow-Designers bekommen?

Ich benutze WF jetzt seit mehr als 5 Jahren in meinen Automatisierungsprojekten und es war wunderbar. Ich hoffe, dass viele Entwickler diese Anfrage unterstützen und verwirklichen werden. Ich habe immer .Net-Technologie verwendet, seit ich angefangen habe zu arbeiten, und würde dies auch weiterhin tun wollen. Die Möglichkeit, plattformübergreifend zu unterstützen, ist jedoch die Richtung des Unternehmens, daher freue ich mich sehr darauf, die vollständige WF in .Net Core zu sehen.

Mit der Einführung von net standard 2.0 wäre es großartig, ein Update zu den Problemen von corewf zu haben:

@dmetzgar
https://github.com/dmetzgar/corewf/issues/3
https://github.com/dmetzgar/corewf/issues/4

Wie hat die hinzugefügte API den Portierungsprozess entsperrt und was können wir tun, um zu helfen?

Ich denke, unabhängig von netstandard2.0 , dieser Port sollte so laufen, wie er IMHO lief ... Mit einer Neufassung ... Er ist für externe Aufgabenplaner, async/await/Task und andere moderne Dinge geeignet. So sehr ich WF auch liebe, die aktuelle Version ist ziemlich veraltet...

Ich meine das ganz ohne Respektlosigkeit. Ganz ehrlich. Aber bin ich der einzige hier, der versteht, dass dieses Projekt aussichtslos ist? Wir brauchen dringend eine gute Workflow-Engine für .Net, aber das ist es einfach nicht. Sollten wir hier nicht das Gespräch ändern?

Ich bin offen für eine neue, bessere Workflow-Engine. Unterm Strich brauchen wir einen in .NET Core. Wir verwenden WF seit Jahren und es hat wirklich gut für uns funktioniert, also ist es besser als nichts, wenn das die Alternative ist.

@kalokamgit , die Quelle ist unter Referenzquelle verfügbar. Es ist in zwei Baugruppen:
System.Activities.Presentation und System.Activities.Core.Presentation .

Leider macht das Tool, das die Referenzquelle veröffentlicht, nur den C#-Code. Es enthält keine der XAML-Dateien. Sie können Feedback dazu an [email protected] senden und/oder über das Problem mit der Benutzerstimme abstimmen .

Der Code befindet sich im .NET Framework, sodass Sie ihn in Ihren eigenen Tools verwenden können. Einige Beispiele sind das Projekt von @orosandrei und ein Beispielprojekt hier .

Ich meine das ganz ohne Respektlosigkeit. Ganz ehrlich. Aber bin ich der einzige hier, der versteht, dass dieses Projekt aussichtslos ist? Wir brauchen dringend eine gute Workflow-Engine für .Net, aber das ist es einfach nicht. Sollten wir hier nicht das Gespräch ändern?

Nun, wenn Sie _wirklich_ keine Respektlosigkeit meinen. :) Ich bin neugierig, was alle über Flow denken ? Daran denke ich, wenn ich an „Workflow“ für die „moderne Zeit“ denke … auch an das, was Azure heutzutage ziemlich hausieren lässt.

Ich meine es wirklich ernst :)

Guess Flow ist die Antwort auf wachsendes Zapier? Ich sehe nicht, wie es den WWF in irgendeiner Weise ersetzen würde.

Wird WF eingestellt oder übersehe ich hier etwas? Das wäre sehr schade!

Wo kann ich für WF abstimmen?

Top-Post dieser Ausgabe ist der beste Ort.

Ich frage mich, was @rjacobs (WF-Guru) von dieser Angelegenheit hält.

Meinst du @ronljacobs?

@dmetzgar Wahrscheinlich ja. Er ist der wahre WF-Held

Dies ist meine Antwort
https://github.com/danielgerlag/workflow-core

Ron Jacobs war der Typ, der jahrelang sein Herz und seine Seele in WF gesteckt hat. Er erkrankte an der Dercum-Krankheit und verließ Microsoft im Jahr 2013. (hier) Als er ging, war es das für WF. Noch einmal und hoffentlich zum letzten Mal: ​​WF IS DEAD.

Und noch einmal - - Ich möchte jeden ermutigen, sich Dan Gerlags Projekt oben anzusehen. Es ist eloquent, schön konzipiert und läuft auf Core. Wer zu einer tragfähigen Workflow-Lösung beitragen will, muss hinschauen.

Bitte werfen Sie auch einen Blick auf das Durable Task Framework . Dies wird zu Azure Functions hinzugefügt, siehe Durable Functions .

@dmetzgar Dieser Rahmen ist bei Windeln als Alternative zu WF anzusehen. Ich denke nicht, dass es ernst gemeint ist, dass Microsoft so etwas vorschlägt. Wäre es nicht viel besser, anstatt das Rad neu zu erfinden, WF auf .NET Core zu migrieren und als Basis in allen Microsoft-Projekten wiederzuverwenden? Entschuldigen Sie die Härte meiner Worte, aber ich denke, sie repräsentieren die Stimmung vieler Menschen, die von der aktuellen Situation von WF sehr enttäuscht sind.

@Suriman , fairer Punkt

Ich habe die Readme-Datei im Corewf -Repository aktualisiert, um eine bessere Beschreibung dessen zu erhalten, was mit der Portierung von WF auf .NET Core zu tun hat. Würden Sie gerne einen Blick darauf werfen?

@dmetzgar Vielen Dank für die Erläuterungen und dafür, dass Sie den Weg zur Portierung von WF auf .NET Core klar aufgezeigt haben. Ich verstehe aus dem, was Sie sagen, dass Microsoft nicht all diese Migrationsarbeit leisten wird und dass es hofft, dass die Community dies tut, oder? Die Antwort auf diese Frage ist der Schlüssel, je nach Antwort können sich Unternehmen für einen alternativen Weg entscheiden oder die Arbeit erledigen, die Microsoft tun sollte.

Microsoft wird keine offizielle Portierung von WF auf .NET Core durchführen. Mein Team und ich werden in unserer Freizeit daran arbeiten, aber nicht in offizieller Funktion oder mit geplanten Veröffentlichungen. Alle aufgeführten Probleme sind zu gewinnen. Es gibt Verwendungen für einen solchen Port für einige der Projekte, die wir durchführen. Von dort werden die meisten unserer Beiträge kommen. Ich denke, es ist fair, dieses Thema vorerst zu schließen und die Leute auf das Corewf-Repo zu verweisen, um die neuesten Arbeiten zu verfolgen.

Hallo,
Bedeutet der Wechsel von Future Milestone zu 2.1, dass Microsoft WF auf .NET Core portieren wird?

Die Meilensteinänderung für geschlossene Probleme spiegelt nur wider, in welcher Version das Problem geschlossen wurde.
Dieses spezielle Problem wurde grundsätzlich als "Won't Fix" geschlossen - siehe Erklärung oben https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275

@karelz Schade. Für einen Moment sah es aus, als hätte uns das Lotto getroffen.

Wir haben eine Lösung, die auf WF basiert. Wir erstellen Schritte von Aktivitäten mit WF und dieser Workflow wird an alle Abonnenten geliefert und sie werden die Aktionen basierend auf WF verarbeiten. Wir lieben WF zu sehr. Die Unterstützung von Cross-Plattform ist unsere Unternehmensrichtung. Wir sind sehr daran interessiert, WF auf .NET CORE zu haben.

Es gibt CoreWF , bei dem es sich um den Code von Workflow Foundation handelt, der teilweise auf .net Core portiert wurde. Sie können Workflow Foundation jetzt plattformübergreifend verwenden. Sie können derzeit keine XAML-basierten Workflows verwenden.

Ich habe einen Zweig, in dem ich daran gearbeitet habe, Unterstützung für dynamische Aktivität zusätzlich zu Net Standard 2.0 hinzuzufügen.

Der XAML-Analyseprozess erfordert, dass Microsoft System.XAML ausreichend öffnet, damit wir Fortschritte beim korrekten Analysieren der Dateien machen können.

Sie können den Fortschritt zu diesem Problem hier verfolgen: https://github.com/dmetzgar/corewf/issues/6 und in meinen verschiedenen Versuchen, auf dieses Problem aufmerksam zu machen:
Auf CoreFX
Auf ReferenceSource

Das .Net-Kompatibilitätspaket hat ein „Vielleicht“ auf der Vorderseite von System.XAML. Es sind jedoch keine Nachrichten über seine Aufnahme gefiltert worden. Das Problem Ship .Net Framework Compatibility Pack listet derzeit „keine Pläne“ für System.XAML auf.

Vielleicht könnte auch das Thema Customer Adoption Epic verwendet werden, um Ihre Geschichte zu erzählen, wie das Hinzufügen von Workflow Foundation (und System.Xaml) es Ihrem Unternehmen ermöglichen würde, ein Produkt auszuliefern.

Mein Unternehmen investiert auch in WF: Wir haben ein Produkt für Energieunternehmen, bei dem unsere Kunden Workflows mit Workflow Foundation erstellen.

Danke für Ihre Antwort.
es war sehr nützlich, es zu schätzen.

Am 2. November 2017 um 18:22 Uhr schrieb „Eric Winnington“ [email protected] :

Es gibt CoreWF https://github.com/dmetzgar/corewf , das ist der Code von
Workflow Foundation teilweise auf .net Core portiert. Sie können Arbeitsablauf verwenden
Foundation Cross-Plattform jetzt . Sie können einfach keine XAML-basierten Workflows verwenden
in diesem Moment.

Ich habe einen Zweig, in dem ich daran gearbeitet habe, Unterstützung für dynamische Aktivitäten hinzuzufügen
auf Net Standard 2.0 https://github.com/ewinnington/corewf .

Für den XAML-Analyseprozess muss Microsoft System.XAML öffnen
ausreichend, damit wir beim korrekten Analysieren der Dateien Fortschritte erzielen können.

Sie können den Fortschritt des Problems hier verfolgen: dmetzgar/corewf#6
https://github.com/dmetzgar/corewf/issues/6 und in meinen verschiedenen Versuchen
um auf dieses Problem aufmerksam zu machen:
Auf CoreFX
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
Auf ReferenceSource
https://github.com/Microsoft/referencesource/issues/39

Das .Net-Kompatibilitätspaket
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
hat ein "Vielleicht" auf der Vorderseite von System.XAML. Aber es sind keine Nachrichten darüber eingedrungen
Aufnahme. Das Problem Ship .Net Framework Compatibility Pack
https://github.com/dotnet/corefx/issues/24909 listet derzeit „no
Pläne" für System.XAML.

Vielleicht auch das Thema Customer Adoption Epic
https://github.com/dotnet/corefx/issues/24751 könnte dazu verwendet werden
Ihre Geschichte, wie das Hinzufügen von Workflow Foundation (und System.Xaml) dies ermöglichen würde
Ihr Unternehmen, ein Produkt zu versenden.

Mein Unternehmen ist auch in WF investiert: Wir haben ein Produkt für Energieunternehmen
wo unsere Kunden Workflows mit Workflow Foundation erstellen.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

Hallo,
Dies ist eine Welt der Microservices und das ganze Zeug wird in Komponenten zerlegt. Wenn wir es jetzt orchestrieren müssen, müssen wir uns auf Azure-Logik-Apps oder einen anderen externen Anbieter verlassen, der eine Prämie für einen Workflow berechnet. Obwohl es nur sehr wenige Nicht-.NET-WF-Produkte wie Netflix Conductor gibt, würden wir gerne eines in einer reinen .NET-Core-Version haben. Sie können die Hinweise von Netflix Conductor unter https://github.com/Netflix/conductor nehmen und von dort aus einen erstellen. Dies ist ein großer Segen für Private-Cloud-Entwickler, die keinen Zugriff auf Azure Stack haben und Logic Apps nicht verwenden können.

Ich dachte, ich würde hier aus Gründen der Sensibilisierung posten. Ich habe mir die folgende Dokumentation durchgelesen und bin dabei auf diesen Thread gekommen:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

Sieht so aus, als ob Dynamics365 und PowerApps eine Gedankenverschmelzung vornehmen und Windows Workflow jetzt in gewisser Weise für die Workflow-Handhabung verwenden. Dies ist natürlich alles nur für Windows, aber in der neuen Ära der plattformübergreifenden usw. ... wie lange wird das dauern?

Ich weiß nicht, was ich verwenden soll. Ich wünschte, MSFT würde dies tun. Bringen Sie Klarheit Microsoft.

@VenkateshSrini , du solltest dir auch Cadence ansehen: https://github.com/uber/cadence
Das Modell ähnelt eher dem SWF von Amazon, ist aber Open Source. Noch kein .NET-Client.

Ausschau halten nach. Net-Core-Version

Das wird nicht passieren.

Von: VenkateshSrini [email protected]
Gesendet: Mittwoch, 26. September 2018 00:30 Uhr
An: dotnet/corefx [email protected]
Cc: Jeffrey Michelson [email protected] ; Erwähnen Sie erwä[email protected]
Betreff: Betreff: [dotnet/corefx] Workflow Foundation auf .NET Core portieren (#2394)

Ausschau halten nach. Net-Core-Version

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5uewLNgaJpZM4FaQMY .

Schade

Was bietet Microsoft also für ifttt oder Workflow in einem Nicht-Azure-Ökosystem an? Wenn sie Dinge wie ml aus Azure heraus ermöglichen möchten, warum nicht Workflows

Schauen Sie sich die Arbeit von Dan Gerlag an.

https://github.com/danielgerlag/workflow-core

Von: VenkateshSrini [email protected]
Gesendet: Mittwoch, 26. September 2018 8:34 Uhr
An: dotnet/corefx [email protected]
Cc: Jeffrey Michelson [email protected] ; Erwähnen Sie erwä[email protected]
Betreff: Betreff: [dotnet/corefx] Workflow Foundation auf .NET Core portieren (#2394)

Was bietet Microsoft also für ifttt oder Workflow in einem Nicht-Azure-Ökosystem an? Wenn sie Dinge wie ml aus Azure heraus ermöglichen möchten, warum nicht Workflows

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, sehen Sie sie auf GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY .

Es gibt CoreWF , eine Portierung der Workflow Foundation auf .net Core. Dieser Port schreitet voran. Wir suchen Menschen, die helfen.

Der nächste wichtige Schritt ist das Kompilieren geladener Workflows mit Roslyn, damit wir Code in den Workflow-Parametern verwenden können, dies ist für die XAML-definierten Workflows erforderlich. Wenn Sie Workflows im Imperative-Kern definieren, können Sie jetzt CoreWF verwenden.

Danke für deine Arbeit @ewinnington und @dmetzgar ! Die XAML-Unterstützung durch Portable.XAML in CoreWF ist eine große Sache für diese Bemühungen. @dmetzgar Planen Sie, bald eine neue Version für NuGet zu veröffentlichen?

Hallo zusammen,

Ist das alles produktionsreif? Wir räkeln die Workflow-Definition, die von einer externen Benutzeroberfläche durchgeführt werden soll. Aber die Engine sollte in der Lage sein, die Definition zu laden und von da an zu arbeiten. Eher eine iffft-Art

@VenkateshSrini , ich denke nicht, dass Microsoft ein plattformübergreifendes Workflow-Framework bereitstellen muss. In den Zeiten von .NET Framework hat Microsoft alles zur Verfügung gestellt, was zu Lasten der gesamten Community ging. Ich würde gerne mehr .NET-Open-Source-Bibliotheken sehen, die von Organisationen übernommen und „produktionsreif“ gemacht werden.

@watertree , ich warte auf eine neue Version von Portable.Xaml. Für die CoreWF-XAML-Unterstützung ist ein kritischer Fix erforderlich.

Was ist vorerst die Alternative für langlaufende Workflows (mit Persistenz)? Nur bezahlte?

@freerider7777

FYI: https://github.com/danielgerlag/workflow-core

Wir verwenden es in unserem Unternehmen mit sehr guten Ergebnissen.

Für diejenigen, die noch folgen, hat das CoreWf- Projekt mit der Integration von Roslyn gerade einen wichtigen Meilenstein erreicht, um die Ausführung dynamisch geladener XAML-Workflows zu ermöglichen. Wenn Sie Workflow Foundation weiterhin auf dotnet core benötigen, probieren Sie es aus.

Hallo ,
Bedeutet das, dass ich den vorhandenen XAML-Workflow nehmen und ihn so verwenden kann, wie er ist? Haben wir eine Einschränkung?

Haben wir eine Einschränkung?

Der Instanzspeicher wurde noch nicht portiert, der Designer befindet sich nicht im Kern und der WCF-Dienst ist nicht verfügbar, da der WCF-Server noch nicht im Kern vorhanden ist.

Bitte erstellen Sie ein Problem im CoreWf- Repo und listen Sie die Anforderungen auf, die Sie haben. Dort können wir das Gespräch fortsetzen.

Das aktuelle Nuget für corewf ist veraltet und enthält nicht die Roslyn-basierte Laufzeit-XAML-Ausführung, die gerade zusammengeführt wurde. Wir suchen immer noch nach Feedback, um zu sehen, was funktioniert und was nicht.

Bedeutet das, dass es nie passieren wird?

Es wird nicht passieren. Es würde nie passieren - - keine Beleidigung für diejenigen, die ihr Bestes gegeben haben. Sehen Sie sich das Projekt von Dan Gerlag an (https://github.com/danielgerlag/workflow-core) oder beißen Sie in den sauren Apfel und steigen Sie in den Azure LogicApps-Zug ein.

Hallo, hier ist Oktober 2020. Irgendwelche Neuigkeiten/Updates/Veröffentlichungen zu Workflow Foundation auf .NET Core?

oder sollen wir alle zu Elsa ziehen? https://elsa-workflows.github.io/elsa-core/

@wstaelens Ich denke, die MS-Antwort war ziemlich klar : WF wird nicht offiziell auf .Net Core portiert. Die vorgeschlagene Alternative ist CoreWF .