Runtime: Porter Workflow Foundation vers .NET Core

cc : @terrajobst , @joshfree , @weshaggard

Nous avons besoin que System.Xaml soit ouvert avant qu'un effort sérieux puisse être fait au portage.

Je comprends @jakesays .

Le fait est que WF peut avoir ses définitions de flux de travail créées dans des classes C # au lieu de XAML (pour l'instant) et de nombreuses personnes n'utilisent même pas la représentation XAML de celui-ci. Plus tard, lorsque System.Xaml est ouvert, nous pouvons également intégrer le concepteur visuel et les définitions XAML. De plus, nous travaillons sur un moteur de flux de travail qui suit strictement l'utilisation/la mise en œuvre de WF, mais au lieu d'utiliser XAML comme stockage de base pour les définitions de flux de travail, nous l'avons basé sur Json pour le magasin, ce qui ouvre de nombreuses opportunités pour les nouveaux concepteurs de flux de travail sur n'importe quel plates-formes (pas seulement VS ou le composant de concepteur hébergé pour WPF/WForms) et présentent plusieurs avantages tels qu'une lecture/écriture plus rapide, la simplicité du schéma, un chargement/compilation plus rapide et des opérations d'exécution. Il peut même être utilisé pour optimiser les flux de travail client, pour guider les flux d'interface utilisateur d'application sur les applications Windows Phone/Store, par exemple, en raison de son exécution légère.

Je pense vraiment que WF est un composant VRAIMENT puissant sur la plate-forme .Net, mais pour les technologies d'aujourd'hui, XAML reste un "limiteur" de celui-ci mais, si pour une décision stratégique de MS, nous pouvons le garder tel quel et le porter sur CoreCLR.

Merci

@zhenlan peut parler de la réflexion actuelle autour du WF

@galvesribeiro beaucoup de gens n'utilisent peut-être pas xaml, mais beaucoup le font, et il est en effet considéré comme un élément central de WF. Nous utilisons abondamment xaml, donc je verrais WF sans support xaml à peine utile.

Je préférerais que nous continuions à faire pression sur Microsoft pour ouvrir System.Xaml.

Et utiliser JSON en remplacement n'est tout simplement pas attrayant.

@galvesribeiro @jakesays Nous aimons vraiment savoir à quel point les clients WF sont intéressés par la version .NET Core de WF, il est donc formidable d'entendre les commentaires de la communauté. S'il y a suffisamment de demande, cela nous aidera à aller de l'avant.

Nous sommes à un stade précoce de l'évaluation de la faisabilité, des dépendances, des priorités des fonctionnalités, etc. Il nous sera donc très utile de savoir quels scénarios sont dans votre esprit, pourquoi WF sur .NET Core (vs. WF en .NET complet) sera utile pour vous et quelles fonctionnalités WF vous souhaitez voir en premier.

@galvesribeiro Dans votre scénario de création de flux de travail dans le code et de stockage de ces définitions au format JSON, qu'utilisez-vous (prévoyez-vous ?) d'utiliser pour les expressions ? Utilisez-vous des expressions VB, des expressions C# ou avez-vous vos propres activités d'expression basées sur CodeActivity pour traiter les expressions ?

Merci pour la contribution.

@jakesays c'est ok pour moi d'utiliser XAML. Je ne m'intéresse qu'aux performances...

@zhenlan Nous avons un commutateur de paiement électronique qui traite des milliards de transactions par carte de crédit/débit par jour pour certaines banques ici au Brésil et d'autres à l'étranger. Nous étions entièrement sur site et nous mettons à jour la technologie pour qu'elle soit entièrement cloud et proposée en tant que service sur Azure. Nous avons obtenu un accord d'entreprise afin d'explorer tout ce dont nous avons besoin d'Azure ici en tant que plate-forme de traitement des paiements multi-locataires pour nos clients.

Nous étudions l'utilisation de NanoServer pour et CoreCLR afin de réduire l'empreinte, la surface d'attaque et la maintenance consacrées à l'exécution de nos services et nous avons remarqué que coreCLR n'a pas encore (au moins) porté System.Activities. En d'autres termes, pas de Workflow Foundation.

Notre moteur de traitement de base est un moteur d'entreprise construit sur le meilleur WF et il contient plus de 40 activités personnalisées axées sur notre entreprise. Ce moteur traite en temps réel le processus/les règles de la transaction afin d'obtenir l'approbation de la transaction. Nous devons l'adapter à la demande, et le faire avec l'implémentation actuelle de WF dans le cloud, disons que ce n'est pas faisable.

Le porter sur .net core, au lieu de le garder sur .net full (profil de serveur) ouvrira la possibilité d'exécuter des flux de travail client, c'est quelque chose qui nous manque vraiment dans notre entreprise. Ces flux de travail client peuvent amener les gens à développer une logique client-entreprise déclarative, de sorte que de petits appareils comme les smartphones, les appareils portables, l'IoT et nos terminaux de paiement peuvent prendre certaines décisions sans écrire de véritable code répétitif.

Comme nous n'avons trouvé aucun effort sur WF pour .net Core, et même cela n'a pas changé depuis des années et dépend toujours de XAML, nous avons décidé de démarrer notre propre moteur de flux de travail qui se comporte exactement de la même manière que WF. Même modèle d'activités, même style de code, etc., mais beaucoup plus léger et basé sur Json comme magasin de définition. Cela permet aux appareils dotés d'une faible puissance de calcul de traiter les flux de travail sans avoir à gérer XAML/XML, de sorte que la plupart de notre code conçu pour WF fonctionne sans beaucoup de modifications sur les définitions Json au lieu des flux de travail basés sur XAML. De plus, s'éloigner de XAML ouvrira la possibilité à de nouveaux concepteurs de flux de travail... Pas bloqué sur Visual Studio et sur les applications WPF pour réhéberger le concepteur VS.

Ce que j'essaie de suggérer est l'une de ces options:

1. Portez WF (avec XAML) tel quel vers le noyau .Net. Cette option prendra beaucoup plus de temps car WF dépend aujourd'hui du profil de serveur de .Net, ce qui nous fera passer beaucoup de temps à le découpler afin de le faire fonctionner avec le noyau .Net.
2. Portez WF en le réécrivant sur le noyau .Net. De cette façon, nous pouvons obtenir les concepts de base et nous concentrer sur la conception d'un moteur plus léger pouvant fonctionner sur des serveurs, des clients, des IoT ou tout ce qui est nécessaire en conservant les principes de conception et les fonctionnalités actuellement implémentées sur WF. De cette façon, nous facilitons la migration de XAML vers (par exemple) des définitions de flux de travail basées sur Json. Toutes les activités actuelles doivent être portées sur le nouveau modèle.

Je ne vous demande pas de constituer une équipe ou de vous engager dans un nouveau produit. La communauté peut le faire comme elle le fait pour ASP.Net et Entity Framework. Faites-en un cadre externe et auxiliaire, non intégré au noyau.

Merci

@jimcarley Les expressions seraient compilées de la même manière qu'elles le sont aujourd'hui sur XAML. Dans l'un de nos flux de travail, nous avons ceci (il peut également s'agir d'une VBValue, je viens de recevoir un échantillon):
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

Les expressions sur XAML aujourd'hui, retournent principalement un booléen, ou attribuent une valeur à une variable, donc cela serait stocké de la même manière qu'il est stocké aujourd'hui sur XAML, mais dans Json et il pourrait être compilé en suivant les mêmes idées c'est aujourd'hui.

Si vous regardez Azure Resource Manager (ARM), ils l'ont déjà fait ! Ils ont le déploiement des ressources en tant que modèle Json, qui a des dépendances et un flux, et les variables peuvent être appelées en tant qu'expressions. Regarde ça:

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

Ok, ils utilisent des fonctions JavaScript mais le principe est le même. Ils ont une variable $schema au-dessus du modèle qui guide la structure du document, les étapes du processus de déploiement que nous pouvons faire en tant qu'activités. La conception est assez similaire à celle du WF mais ce DSL se concentre sur le déploiement du groupe de ressources. Nous pouvons le rendre plus général et utiliser les activités de la même manière qu'ils le font dans la mise en œuvre actuelle du WF.

Si vous décidez que ça vaut le coup, nous pouvons commencer à dessiner de la documentation sur un autre problème qui guidera l'architecture du "nouveau WF". Si cela vous semble si fou et hors de vos plans, faites-le moi savoir, nous le développerons toujours de notre côté pour prendre en charge le noyau .net, et le publierons plus tard en tant que pépite pour les gens. J'essaie juste de mettre à jour ce merveilleux cadre avec les technologies actuelles (à venir). C'est vraiment un besoin commercial pour nous. Nous dépendons beaucoup de WF, mais s'il ne devient pas plus rapide et pris en charge sur coreCLR, nous devrons commencer à préparer ce nouveau framework afin que lorsque le NanoServer + coreCLR sont RTM, nous pouvons nous déplacer pour cela.

S'il vous plaît laissez-moi savoir si vous avez des questions.

Merci

PS : Je suis sur les canaux gitter tous les jours si vous avez besoin de discuter.

@galvesribeiro Vous utilisez donc TextExpressionCompiler pour compiler les expressions après avoir créé l'objet Activity à partir de la définition de workflow stockée dans le JSON. À droite?

@jimcarley nous n'avons pas encore le compilateur d'expression qui fonctionne. Nous le concevons toujours en utilisant les mêmes principes que TextExpressionCompiler mais oui, cela ressemble à peu près au même concept. Les implémentations actuelles semblent encore liées à System.XAML. Comme il n'est pas ouvert, je ne peux pas confirmer si cela fonctionnera de la même manière (en interne) que TextExpressionCompiler mais oui, une fois l'activité chargée, nous devrions évaluer/compiler les expressions (si elles ne sont pas déjà dans un cache) et exposer un objet Expression dessus pour être évalué par les consommateurs de l'activité (si nécessaire).

L'année dernière, j'ai travaillé du côté de l'expression pour activer la prise en charge de l'expression C # dans les concepteurs WF auto-hébergés. Il était basé sur des morceaux de nrefactory et roslyn. Je peux le déterrer si quelqu'un est intéressé.

@galvesribeiro après avoir réfléchi davantage à votre approche json, à la fin, je suppose que cela n'aurait vraiment pas d'importance pour un nouveau développement. Si MS n'ouvre pas le support xaml, cela pourrait fonctionner.

@zhenlan Je suis d'accord avec @galvesribeiro sur le fait que nous ne recherchons pas nécessairement MS pour former une équipe pour porter WF. C'est certainement quelque chose que la communauté pourrait faire avec les conseils de votre équipe, etc.

@jakesays Je suis d'accord avec vous que le stockage n'a pas d'importance si nous créons à nouveau WF pour coreclr.

Le fait est, pourquoi continuer à utiliser XML au lieu de Json puisque nous avons de nombreux tests sur le Web comparant les performances de (dé) sérialisation des deux et json est de loin plus rapide et consomme moins de ressources que lui ? (par exemple en comparant Json.Net de Newtonsoft avec sérialiseur XML standard) Si WF s'exécutait sur un périphérique client à faible encombrement (n'importe quel IoT), chaque octet de mémoire compte.

De plus, avec json, il est beaucoup plus simple d'obtenir immédiatement de nouveaux concepteurs WF basés sur le Web. L'expression compilation et exécution n'est pas difficile à implémenter. Il s'agit grosso modo d'un analyseur de la chaîne pour construire l'objet d'expression. La partie la plus difficile (à mon humble avis) est d'obtenir intellisense sur VS pour les types utilisés lors de la conception du WF, mais je suis presque sûr que Roselyn et les services linguistiques peuvent nous aider et VS dispose d'une infrastructure pour cela.

@galvesribeiro , vous mentionnez que vous avez déjà créé votre propre moteur de flux de travail avec une définition et une sérialisation de flux de travail basées sur JSON. Si WF était porté sur Core, l'utiliseriez-vous réellement ?

@dmetzgar, nous avons commencé à le développer et à le tester comme une preuve de concept que nous pouvons obtenir un meilleur résultat dans un WF plus propre avec presque aucune dépendance sur le framework, ce qui est bien pour le faire fonctionner sur coreclr. Nous ne l'avons pas prêt.

J'aimerais ne pas avoir à créer mon propre moteur et continuer à utiliser WF même s'il est basé sur XAML mais porté sur coreclr et s'il suit le même concept des versions coreclr d'EntityFramework et ASP.Net par exemple (ne dépendez pas de bibliothèques de serveur et s'exécute partout).

Le fait est que si cela dépend toujours de XAML et du profil du serveur, il continuera à être lent (nécessitant trop de ressources), limité aux choix du concepteur, etc.

Ma suggestion est de le porter sur coreclr en utilisant Json et de supprimer de nombreuses dépendances qu'il a aujourd'hui, laissant l'utilisateur capable de l'exécuter n'importe où de la même manière que vous pouvez exécuter ASP.Net vNext sur un appareil IoT ARM (dès que le support ARM est terminé !) et ne vous inquiétez pas des dépendances et de la consommation élevée de ressources.

Tous nos flux de travail aujourd'hui sont créés avec la version actuelle avec certains d'entre eux écrits avec du code pur et certains avec XAML mais dans les deux cas, nous avons toujours des dépendances.

À mon humble avis, le porter sur coreclr tel qu'il est, n'apporte pas autant d'avantages à moins que quelqu'un ne vienne avec un super nouveau moteur léger pour l'analyse/le rendu XAML/XML à la fois pour l'exécution et le temps de conception. Mais si vous décidez de porter tel quel, nous continuerons à l'utiliser de toute façon, car cela fera fonctionner mes flux de travail XAML (j'espère) à partir du jour 0, même si je sais que cela n'apportera aucun avantage pratique...

Encore une fois, je (probablement @jakesays et d'autres utilisateurs de WF) peux aider sur ce port dans les deux sens (XAML ou JSON) quelle que soit votre décision. Je veux juste m'assurer que ce port n'est pas simplement copier-coller-réparer pour le faire fonctionner, et à la place, il apporte vraiment des avantages pour les personnes qui l'utilisent en suivant la même idée de coreclr et il peut fonctionner partout sans douleur.

Merci

@galvesribeiro Je suis d'accord que XAML est trop étroitement intégré à WF. Pour en revenir au livre original de Dharma sur le flux de travail, il avait un exemple qui a construit un flux de travail à partir de Visio. Au moins avec le portage vers le noyau, nous pouvons le découper afin que le runtime soit séparé de XAML. Cela nous permet de procéder avec ou sans le portage de l'équipe XAML vers le noyau et nous pouvons toujours ajouter ultérieurement la prise en charge du flux de travail XAML en tant que projet GitHub/package NuGet distinct. Je suis définitivement tout pour rendre possible la définition et la persistance des flux de travail dans n'importe quel format. Merci, ce retour est utile.

@dmetzgar Je n'ai aucun doute qu'un jour XAML sera porté sur le noyau ... Si .net core va fonctionner sur Windows Phone ou sur tout appareil mobile Windows 10, cela arrivera à un moment donné et je suis tout à fait d'accord avec vous que nous pouvons construire un nouveau noyau, et ajoutez également la persistance des définitions et de l'état du flux de travail ultérieurement.

Alors, que devons-nous faire pour commencer à le porter ? (nous avons déjà signé l'accord de contribution et avons d'autres NDA en tant qu'entreprise avec MS, etc.)

Merci

@galvesribeiro J'apprécie l'enthousiasme ! Aussi tentant qu'il soit d'ouvrir un référentiel GitHub et de commencer à pirater, il y a quelques étapes à suivre. De plus, il n'y a pas que System.Xaml qui doit être découpé. Il existe d'autres dépendances profondément ancrées dans WF comme System.Transactions et certains composants partagés avec WCF. Nous examinons chacun d'entre eux.

Je comprend. Eh bien, je ne veux pas vous bousculer, je m'inquiète juste du temps. Nous avons une décision à prendre maintenant pour aller de l'avant en construisant par nous-mêmes, ou pour rejoindre la communauté ici et porter WF vers coreCLR afin qu'il puisse respecter notre calendrier pour notre produit.

@dmetzgar Avez-vous envisagé de publier les parties qui peuvent être open source dès maintenant sur https://github.com/Microsoft/referencesource ? Je pense que cela pourrait être beaucoup plus simple que de créer un projet open source à part entière qui fonctionne réellement.

De cette façon, vous pouvez prendre votre temps avec la bonne version, et d'autres peuvent créer leurs propres versions partielles/personnalisées en attendant.

Les composants @svick WF en .NET complet ont déjà été publiés sur github referencesource il y a quelque temps. Par exemple, vous pouvez trouver https://github.com/Microsoft/referencesource/tree/master/System.Activities

@zhenlan oui, le problème est que certaines dépendances ne sont pas "résolubles" ... Je ne vois pas correctement quel est le comportement de certaines classes, en raison de sa dépendance à System.Xaml qui n'est pas public ...

Nous pouvons toujours comprendre d'ici notre fin, mais cela signifie que nous ne savons pas avec certitude si nous suivons le même chemin.

@dmetzgar System.Transaction est quelque chose qui n'est pas ouvert (encore ?), mais je pense que nous pouvons y faire face (pour l'instant). Concernant le WCF, l'arborescence des dépendances ne me montre que les activités et l'hôte des services de workflow. Rien sur le noyau (IIRC) ne dépend de WCF...

@galvesribeiro La situation avec System.Transactions est plus complexe que cela. Il est répandu tout au long de l'exécution de WF et dépend fortement de l'instanciation durable, où se trouvent les classes de base pour la persistance. WCF et WF ont été fusionnés dans la même équipe autour de la période .Net 4.0, nous avons donc des choses comme System.ServiceModel.Internals utilisées à la fois par WCF et WF. .Net core a beaucoup de choses importantes portées, mais il en manque beaucoup. Travailler autour des pièces manquantes peut nécessiter des modifications de conception ou des réécritures de fonctionnalités.

Aucun de ces problèmes n'est insurmontable, je ne veux tout simplement pas banaliser l'effort. Cela vaut pour le code et tout ce qui l'entoure, comme obtenir l'approbation légale, créer des environnements, tester l'infrastructure, etc. Nous voulons vraiment que la communauté aide et nous travaillons dans ce sens. Que vous deviez écrire votre propre port ou attendre le "officiel" dépend de votre calendrier. L'exécution de flux de travail sur le serveur Nano est l'un de nos scénarios les plus importants et j'aimerais obtenir votre aide à ce sujet.

@dmetzgar J'ai compris, j'avais toujours un certain retard quand toute question devait être transmise aux relations publiques ou au service juridique lorsque j'étais de votre côté :)

Eh bien, si au moins nous avons une idée d'un certain délai, nous pouvons nous préparer et attendre. Je déteste l'idée de mettre en œuvre quelque chose au "mauvais endroit" ou quand il y a déjà des efforts déployés quelque part où nous pouvons unir nos forces pour faire mieux.

Veuillez me faire savoir si nous pouvons faire quelque chose, ou si vous avez des nouvelles, ou envoyez-moi un ping si vous avez besoin de suggestions concernant la conception/le port.

Merci

Au fur et à mesure que le calendrier se précisera, je ferai des mises à jour sur ce fil. Je serais heureux d'entendre les autres scénarios qui intéressent les gens. WF sur Nano est le scénario principal en ce moment, mais il serait bon de savoir ce que font les autres.

Salut les gars, à part XAML et JSON, il y a une façon COOL de composer des activités : la métaprogrammation. Jetez un œil à mon projet expérimental : Metah.W : A Workflow Metaprogramming Language (https://github.com/knat/Metah).

@jakesays Pouvez-vous fournir des conseils sur la façon d'activer la prise en charge de l'expression C # dans WF auto-hébergé.

Veuillez conserver Xaml. :) Les objets sérialisés JSON seraient également intéressants. Mais je préférerais voir des fournisseurs configurés d'une manière ou d'une autre dans le cadre pour choisir le format préféré.

@dmetzgar (et d'autres personnes de MSFT) y a-t-il des nouvelles à ce sujet ?
Merci

Nous y avons travaillé et avons fait beaucoup de progrès. XAML n'est actuellement pas disponible dans Core, nous nous concentrons donc sur le runtime. Nous envisageons de nous ouvrir à d'autres sérialiseurs. Ainsi, au lieu de choisir entre JSON ou XAML, nous préférons vous permettre d'apporter votre propre sérialiseur. Il y a encore plus de conformité et de choses légales à faire approuver. Étant donné que peu de clients font pression pour ce port, il a été moins prioritaire.

@dmetzgar adorable ! Je serais plus qu'heureux d'y contribuer, mais je le peux si cela devient un projet principal ... que ce soit un concepteur de flux de travail Web, etc. On dirait que xaml n'a guère besoin d'être là pour le format de définition ... ravi d'entendre à propos de ce travail !

Salut les gars, joyeux noël et bonne année!

Alors, avons-nous une mise à jour sur ce port ou au moins une version OSS du travail actuel afin que nous puissions vous aider ?

Merci

@galvesribeiro Je vais essayer d'expliquer la situation du mieux que je peux. Dans mon zèle pour faire porter WF sur .NET Core, je n'ai pas pris en compte le côté commercial de tout cela. WPF/XAML n'est pas porté sur .NET Core et cela représente une partie importante de WF. Bien que XAML ne soit pas essentiel à l'exécution, c'est ainsi que la plupart des clients créent des flux de travail. Cela limite le public qui trouverait WF sur Core utile. L'une des craintes est que nous publions WF sur Core et qu'il n'y a pas beaucoup d'implication de la communauté. Cela augmente nos coûts de support et n'améliore pas la situation pour la plupart des clients WF. Bien que ce soit cool de voir WF fonctionner sur une machine Linux, il est difficile de prouver que quelqu'un l'utiliserait réellement.

Je connais OmniXAML et nous avons réussi à convaincre l'auteur de passer à une licence MIT. Donc, avec un peu d'investissement, nous pourrions potentiellement faire fonctionner XAML. Mais il y a toujours la question de savoir comment cela profite aux clients WF existants. Si un jour un gros client comme SharePoint ou Dynamics arrive et dit qu'il passe à Nano, alors nous aurions un cas convaincant. Mais tout cela est sans objet si l'équipe .NET Framework décide de créer un package capable d'exécuter le framework complet sur Nano.

S'il y avait suffisamment d'intérêt dans la communauté et si quelqu'un était prêt à défendre le projet, nous pourrions essayer de le faire de cette façon. Un peu comme Open Live Writer. La partie délicate est que même si mon équipe y contribuerait autant que possible, ce type de projet ne bénéficierait pas du support Microsoft. Je soupçonne que la plupart des clients WF utilisent WF principalement parce que Microsoft le prend en charge.

Je pense qu'il est important de souligner que .NET Core et le .NET Framework complet sont deux produits différents. Le .NET Framework n'est en aucun cas en train de mourir. Nous continuerons à le prendre en charge, à ajouter des fonctionnalités, etc. Ce n'est donc pas comme si nous devions porter WF sur .NET Core pour le maintenir en vie. WF on Core serait essentiellement un nouveau produit. Trouver une justification commerciale solide est difficile. C'est peut-être même une question de timing. À mesure que de plus en plus d'entreprises adoptent les serveurs Nano, il peut y avoir un cas plus fort.

@dmetzgar Que diriez-vous de Portable.Xaml, cela pourrait-il être une alternative? https://github.com/cwensley/Portable.Xaml Il a été extrait pour être utilisé par l'auteur du fantastique projet Eto.Forms pour Eto. Il est sous licence MIT et (tout comme les bibliothèques de classes dont il dérive dans le projet mono).

@dmetzgar ,

Je vais essayer d'expliquer la situation du mieux que je peux. Dans mon zèle pour faire porter WF sur .NET Core, je n'ai pas pris en compte le côté commercial de tout cela. WPF/XAML n'est pas porté sur .NET Core et cela représente une partie importante de WF. Bien que XAML ne soit pas essentiel à l'exécution, c'est ainsi que la plupart des clients créent des flux de travail. Cela limite le public qui trouverait WF sur Core utile. L'une des craintes est que nous publions WF sur Core et qu'il n'y a pas beaucoup d'implication de la communauté. Cela augmente nos coûts de support et n'améliore pas la situation pour la plupart des clients WF. Bien que ce soit cool de voir WF fonctionner sur une machine Linux, il est difficile de prouver que quelqu'un l'utiliserait réellement.

Je pense que la plus grande motivation pour les utilisateurs actuels de WF est le serveur Nano et les Micro Services et non Linux. Linux ajoutera plus d'utilisateurs, mais ce n'est pas la vraie motivation.

Mais il y a toujours la question de savoir comment cela profite aux clients WF existants.

Nous sommes dans les jours nuageux. Rappelez-vous, "Cloud d'abord, mobile d'abord..." et l'une des grandes technologies qui se développent sont les conteneurs, les Micro Services, et une grande offre de MS pour tout ce qu'il est Nano Server.

Si un jour un gros client comme SharePoint ou Dynamics arrive et dit qu'il passe à Nano, alors nous aurions un cas convaincant.

Même avec le plus gros déploiement Sharepoint ou Dynamics sur terre, nous n'atteindrons jamais le même nombre d'utilisateurs et je dirais même le même niveau de revenus, que celui réalisé avec la technologie cloud.

Mais tout cela est sans objet si l'équipe .NET Framework décide de créer un package capable d'exécuter le framework complet sur Nano.

DNX aujourd'hui (en ce qui concerne le RC1) ne comprend pas seulement coreCLR. Il a également le cadre complet (dnx451) afin que nous puissions actuellement utiliser WF sur DNX et ce n'est pas le problème ici. On parle de coreCLR (dnxcore50)

S'il y avait suffisamment d'intérêt dans la communauté et si quelqu'un était prêt à défendre le projet, nous pourrions essayer de le faire de cette façon. Un peu comme Open Live Writer.

Je ne comparerais pas ça à ce qui a été fait sur Open Live Writer... Je pense que c'est plus ou moins ce qui a été fait avec ASP.Net, MVC, Entity Framework. "Produits" de base de la famille .Net et qui sont aujourd'hui open source.

La partie délicate est que même si mon équipe y contribuerait autant que possible, ce type de projet ne bénéficierait pas du support Microsoft. Je soupçonne que la plupart des clients WF utilisent WF principalement parce que Microsoft le prend en charge.

En effet, les clients WF utilisent des contrats de support MS... Les clients Dynamics et Sharepoint le font cependant, il existe de nombreuses applications en dehors de ce monde qui nécessitent encore un support. Dire que les gens ne l'utilisent qu'à cause du support et que l'OSS n'est pas pris en charge revient presque à dire que CoreCLR, EF, ASP.Net n'auront pas le support de MS. Bien que ces projets soient désormais OSS, ils sont fortement surveillés et modérés par les équipes MS.

Par exemple, j'ai commencé en tant qu'utilisateur sur le projet MS Orleans. Il alimente tous les services cloud Halo depuis près de 7 ans. Skype, Outlook et de nombreux autres services MS publics/cloud l'utilisent d'une manière ou d'une autre. Il y a quelques années, était OSSed de MS Research et est maintenant maintenu par 343 Studios, certaines personnes de MSR et d'autres d'autres groupes à l'intérieur de MS mais principalement maintenu par la communauté. Aujourd'hui, je me considère comme un contributeur actif à ce projet et je soutiens les nouveaux utilisateurs ainsi que d'autres personnes MS et non MS là-bas. Nous avons même des anciens (comme moi) et des non-employés de MS au sein de l'équipe GH pour Orléans. Cela signifie-t-il que nous n'avons pas de soutien ? Eh bien, je n'ai pas acheté Orleans donc je demande légalement une assistance dans mes contrats avec MS pour Orleans spécifiquement cependant, je peux le faire en ciblant .Net framework ou tout autre produit lié donc, je ne suis pas vraiment d'accord sur votre déclaration.

Trouver une justification commerciale solide est difficile.
Je suis d'accord avec vous si vous ne recherchez que les clients Sharepoint et Dynamics.

Eh bien, comme de nombreuses autres entreprises dans le monde, nous maintenons de grands accords d'entreprise (EA) avec Microsoft en utilisant la plupart des produits variables sur ces contrats. Dans notre cas, nous traitons des millions de transactions financières (carte de crédit/débit) par jour et chacune représente une instance d'un WF s'exécutant au-dessus d'Orléans et à l'intérieur de Microsoft Azure. Je ne sais pas ce qui serait grand pour vous afin d'agir comme une justification commerciale.

Je pense juste que le noyau (System.Activities), sans XAML, pourrait être porté sur coreCLR et que les concepteurs pourraient être créés à la demande pour XAML, Json, HTML, XML, n'importe quoi. En découplant cette dépendance, d'autres possibilités s'ouvrent.

Comme je l'ai dit au début de ce fil, le travail le plus lourd que nous voulons maintenant, c'est de l'obtenir OSSed et quelqu'un (au moins initialement) de MSFT, devient disponible pour réviser le PR. Le bon sens ici est de réécrire WF et pas seulement de le copier-coller pour coreCLR, nous nous attendons donc à de grandes contributions à ce sujet.

Si cela ne se produit pas, je pense que nous pouvons résoudre ce problème et au moins les gens commenceront à rechercher d'autres moteurs de flux de travail OSS ou même payants qui finiront par bénéficier du support CoreCLR. Je pense juste que c'est une grosse perte de ne pas l'avoir à l'intérieur de CoreCLR...

Je peux donner une très bonne raison pour laquelle WF devrait être porté sur .Net Core.

Microsoft guide les développeurs vers la plate-forme UWP. UWP sera la plate-forme Windows du futur. Cela n'a rien à voir avec l'idée féerique de porter des applications sur Linux, etc. Il est absolument nécessaire que WF s'exécute sur des machines Windows 10, et UWP est l'avenir de la plate-forme Windows 10.

Nous construisons des applications occasionnellement connectées. Nous avons un back-end .Net et un front-end UWP. Actuellement, toute la logique métier est partagée entre .Net et UWP. Mais, nous aimerions coder en douceur la logique métier dans WF. Cela fonctionnera bien dans .Net, mais WF n'est actuellement pas pris en charge par UWP, donc WF est rendu inutile car à moins que l'utilisateur ne soit connecté à Internet, il ne peut pas passer d'appels validés par la logique WF.

UPW a un XamlReader, donc l'analyse XAML n'est pas vraiment un gros problème...

@MelbourneDeveloper est d'accord avec vous pour toutes les raisons, cependant, gardez à l'esprit que UWP et .Net Core (au moins maintenant) ne sont pas sous le même surnom, ce qui signifie que même s'ils partagent les mêmes API de niveau inférieur, ayant la même surface d'API (et . Net Core est OSS alors que UWP ne l'est pas), ils ne sont pas identiques et ne sont pas compatibles. En d'autres termes, vous ne pouvez pas ajouter un assembly .Net Core à un UWP. Ces différences (IMHO) finiront par disparaître mais pour l'instant, elles existent toujours...

Oui. Compris. C'est avec l'hypothèse de travail que ces deux choses seront réunies à l'avenir. S'ils ne le sont pas, que Dieu nous aide !

De plus, le Xaml de @MelbourneDeveloper UWP est une version complètement différente et simplifiée du Xaml de .NET. UserVoice de WindowsDev est parsemé de votes (ce qui continue d'être ignoré, comme avec tout ce qui semble UWP - il n'est pas étonnant qu'ils aient même un UserVoice pour commencer) pour améliorer son système Xaml :
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

Espérons qu'ils fassent ce qu'il faut et se rallient derrière le port Mono Xaml de @cwensley et/ou OmniXaml, comme suggéré. Le système Xaml d'UWP tel qu'il est est vraiment une blague et fait partie de la raison pour laquelle son taux d'adoption est si terrible.

Parallèlement à cette note, j'ai un cas d'utilisation commerciale pour les MSFTies à considérer : NodeJS. Plus nous grattons tous nos esprits collectifs sur ce problème, plus NodeJS acquiert de la valeur sur le marché, car il est vraiment multiplateforme et vraiment omniprésent, ce que la technologie MSFT ne peut tout simplement pas revendiquer pour le moment (ou dans un avenir prévisible). NodeJS fonctionne sur le serveur et le client (TOUS) et permet la réutilisation du code entre les deux. Une base de code fonctionnera dans des scénarios natifs (via Cordova) et Web (via un navigateur HTML5 standard), ce qui est beaucoup moins cher que ce que vous auriez à faire avec une solution basée sur MSFT.

Il arrivera bientôt au point que refaire un système dans NodeJS et abandonner complètement MSFT deviendra plus acceptable (et évidemment moins cher) que d'attendre (ce qui semble être) des équipes dysfonctionnelles pour rattraper les réalités économiques du marché.

Je le mentionne également car il est mentionné qu'il semble que MSFT compte sur UWP pour sa plate-forme client, mais il atteint une fraction du marché que NodeJS fait. Et quand je dis fraction, c'est peut-être exagéré. Nous parlons de 200 millions (dernier nombre d'installations connues de Windows 10) contre ~ 3 milliards (MILLIARDS) d'appareils que les applications basées sur nodejs peuvent atteindre.

Ne vous méprenez pas ici, j'adore MSFT. J'ai investi plus de 15 ans de ma vie dans ses technologies et je suis complètement investi ici, personnellement. Cependant, cet investissement s'accompagne de la passion de voir tout le monde bien faire les choses et d'être fier des décisions et des efforts déployés ici avec la nouvelle ère de la génialité open source et multiplateforme. Je veux aussi que tout le monde soit conscient de la menace du marché qui se profile (et aussi peut-être vérifier/confirmer mes craintes).

Enfin, si tout se passe bien, nous avons un autre gros problème avec notre état actuel de Xaml multiplateforme, car Portable.Xaml est différent d'OmniXaml, donc à un moment donné, nous devrons, en tant que communauté, trouver comment concilier les deux bases de code... idéalement. :)

@Michael-DST est d'accord avec vous sur tous les points. L'une des cibles sur lesquelles nous voulons que WF s'exécute est les clients (spécialement mobiles et intégrés). Nous voulons réduire le code client pour les règles métier locales en y ajoutant WF. Par clients, je ne parle pas à proprement parler d'UWP comme les appareils Windows (téléphone, tablettes et IoT) ...

Je crois qu'il existe des produits majeurs qui s'appuient sur WF comme BizTalk et Sharepoint, mais ils peuvent toujours s'appuyer sur la version complète de .Net tandis que les utilisateurs de .Net Core (et plus tard UWP) pourraient s'appuyer sur les toutes nouvelles API WF/XAML. Je sais que cela impliquera beaucoup de #if autour de la base de code, mais ce sera la voie à suivre...

@galvesribeiro vous remercie pour la vérification/le support. J'ai parfois l'impression de patiner en montée, car personne ne semble reconnaître ce problème très réel (existentiel?) Face à .NET. En fait, le leadership de .NET contribue à exacerber ce problème en recommandant de coupler .NET avec AngularJS pour les applications Web, défiant ainsi les organisations de passer complètement à NodeJS ! (divulgation complète, j'ai écrit ça. :P ).

J'hésite à publier autant ici concernant NodeJS, car WF est plus une technologie côté serveur, mais la façon dont je (et d'autres organisations commencent à) le voir, cela affecte toutes les sphères et menace .NET à tous les niveaux. Il est tout simplement plus rentable (et efficace sur le marché) d'utiliser NodeJS comme pile de solutions à l'heure actuelle et nous (encore une fois, je déteste me répéter - mais pas vraiment) voyons cela se refléter dans les organisations pour leur technologie de choix.

Bottom line: je dois placer mon angoisse _quelque part_ et ce fil en est la victime. :P #désolépasdésolé

Concernant #if defs... beurk, je citerai le Manifeste MvvMCross ici : "# est pour twitter, pas pour le code." :P

ENFIN, j'ai oublié de taguer @SuperJMN car il devrait également être au courant de ce fil/discussion (en tant qu'auteur d'OmniXaml) - sans vouloir manquer de respect, mec ! Je m'attaquerai personnellement au problème OmniXaml vs Portable.Xaml au cours de la semaine prochaine.

@Michael-DST ouais ... En fait, le #if n'est qu'un moyen ... L'équipe .Net Core a adopté l'approche de "Native Shims" où l'implémentation réelle (spécifique au système d'exploitation) est abstraite sur une fine couche inférieure de code natif. Dans le cas de WF, il pourrait s'agir d'un shim pour .Net Full et d'un autre pour .Net Core par exemple...

Je ne suis pas un fan de Node.js et ni de JavaScript (j'ai tendance à penser que c'est toujours un langage de script, pas un langage de programmation mais c'est mon avis), mais je dois admettre que de nos jours, rien ne lui est comparé en termes de xplat. Microsoft lui-même l'utilise pour ses agents de build sur VSTS (pour ne citer qu'un seul cas, il y en a d'autres sur MS) car il s'exécute sur n'importe quelle plateforme par exemple...

Je pense que WF est une technologie géniale dont la version actuelle était destinée aux utilisateurs côté serveur, avec .Net Core, et peut également parfaitement fonctionner sur les clients ...

@galvesribeiro ... je suis avec toi à 100%. EF Core 1.0 est de la même manière... une technologie traditionnellement côté serveur qui peut désormais également être utilisée côté client. Il serait également très pratique d'avoir WF disponible de cette manière.

Aussi, il est bon d'entendre parler des cales. Beaucoup approuver. :)

Enfin, je ne veux pas faire dérailler/détourner le fil (beaucoup) ici, mais pour être sûr de : JavaScript : je suis d'accord en tant que langage de script. Cependant, c'est aussi un "langage" très flexible qui peut être utilisé sous d'autres formes, notamment le byte code (ish). Comme je suis sûr que vous l'avez vu, il existe un compilateur magique LVVM pour C++. La demande croissante/populaire dans la communauté des développeurs .NET est de faire de même pour .NET (transpiler .NET en JS à titre officiel). Cela corrigerait vraiment tous les maux actuels (majeurs) dans le climat actuel des développeurs MSFT.

Quoi qu'il en soit, revenons à votre programmation habituelle. :P Merci pour le dialogue et les pensées!

Vous touchez à certaines choses avec lesquelles je m'occupe depuis 9 ans. Il y a quelque chose que beaucoup de gens qui travaillent avec les technologies Microsoft ne comprennent pas ; à savoir le concept d'informatique distribuée. Une exigence fondamentale de notre logiciel depuis le tout début est qu'il fonctionne en mode occasionnellement connecté. Au fil du temps, Microsoft a pris diverses mesures pour fournir des outils à cet effet, mais aucun cadre complet n'a jamais été développé. Nous avons un peu de framework de synchronisation ici, un peu une base de données LINQ là-bas, mais aucun ensemble d'outils complet pour que tout fonctionne ensemble.

Au cours des 9 dernières années, nous avons développé notre propre framework occasionnellement connecté. Il fonctionne désormais sur .Net, Silverlight et UWP. Nous nous sommes efforcés de tirer parti des frameworks Microsoft tels que EF et WF, mais aucun support n'était proposé pour ces technologies sur les plates-formes technologiques clientes telles que Silverlight. Nous avons littéralement construit notre propre cadre ORM et de synchronisation pour Silverlight qui est maintenant compatible avec UWP.

Quand il y avait beaucoup de buzz autour de WF en premier lieu, c'était assez excitant car il offrait un moyen de coder en douceur la logique métier sans code. Mais, au fil du temps, je suis devenu de moins en moins enclin à penser qu'il y aurait un jour un port vers une technologie côté client comme Silverlight. J'ai posté de nombreuses questions à ce sujet sur les forums, mais la réponse était toujours la même : WF est une technologie côté serveur, pourquoi voudriez-vous l'utiliser dans Silverlight ?

Comme l'a dit galvesribeiro

"Je pense que WF est une technologie géniale dont la version actuelle était destinée aux utilisateurs côté serveur, avec .Net Core, et peut également parfaitement fonctionner sur les clients..."

Et

"L'une des cibles sur lesquelles nous voulons que WF s'exécute sont les clients (spécialement mobiles et intégrés). Nous voulons réduire le code client pour les règles commerciales locales en y ajoutant WF. Par clients, je ne parle pas strictement d'UWP comme les appareils Windows (téléphone, tablettes et IoT)"

Ce que les gens doivent comprendre, c'est qu'en matière d'informatique distribuée, il n'y a pas de distinction entre la technologie client et la technologie serveur. Réfléchissez au fonctionnement de Git. Le code pour Git est le même, que vous regardiez le dépôt central ou un nœud sur le réseau quelque part. Le code est dupliqué partout. C'est la même chose avec notre cadre. La logique métier est dupliquée sur tous les nœuds. En effet, même si l'utilisateur n'est pas connecté au réseau, il doit toujours être soumis à la même logique métier. Dans l'informatique distribuée, chaque ordinateur EST littéralement un serveur. Il exécute littéralement le même code que le serveur.

Nous n'avons jamais pu tirer parti de WF, car nous ne pouvions pas exécuter le code WF dans Silverlight, et maintenant nous ne pouvons pas l'exécuter dans UWP. Il est encourageant de voir EF être porté sur UWP. C'est peut-être le début pour Microsoft de comprendre que l'informatique distribuée est une nécessité. Mais, Microsoft doit s'impliquer dans l'informatique distribuée et inclure WF dans l'ensemble de l'infrastructure informatique distribuée. Peut-être qu'alors, nous pourrons supprimer notre infrastructure informatique distribuée, et je n'aurai plus à maintenir ce code.

Vraiment une excellente perspective et pensées @MelbourneDeveloper. Merci de les avoir partagés. J'étais aussi un méga grand fan de Silverlight et je le piaffe depuis (d'où mon vote résultant et - vraiment - le site ci-dessus). De plus, je suis curieux de savoir ce que vous pensez des services mobiles Azure et si vous avez envisagé de les utiliser dans votre histoire hors ligne ? Je suis un débutant avec l'informatique distribuée (mais creusez ce que vous avez à dire), mais je cherche vraiment à m'y mettre l'année prochaine (j'entends aussi beaucoup de microservices, qui, je crois, en est le dernier équivalent ?) .

Ce que les gens doivent comprendre, c'est qu'en matière d'informatique distribuée, il n'y a pas de distinction entre la technologie client et la technologie serveur.

Vraiment bon point. À ce stade, tout dépend de l'endroit où la technologie est hébergée. C'est-à-dire que vous êtes vraiment limité par l'hébergeur de la technologie que vous essayez de "distribuer" je dirais (et encore une fois je ne suis pas un expert en la matière). Plus l'hôte est omniprésent (ou facilement disponible), plus l'application est distribuée/accessible. Annnnnd.... Je pense que vous savez où je veux en venir. :P

Dans tous les cas, on a vraiment l'impression que nous sommes tous d'accord sur _quelque chose_ ici avec cette discussion et c'est un changement/accomplissement bienvenu pour moi. ;)

@galvesribeiro

gardez à l'esprit que UWP et .Net Core (au moins maintenant) ne sont pas sous le même surnom, ce qui signifie que même s'ils partagent les mêmes API de niveau inférieur, ayant la même surface d'API (et .Net Core est OSS alors que UWP ne l'est pas) , ils ne sont pas la même chose et ne sont pas compatibles. En d'autres termes, vous ne pouvez pas ajouter un assembly .Net Core à un UWP. Ces différences (IMHO) finiront par disparaître mais pour l'instant, elles existent toujours...

Jetez un œil à ce PR dotnet/corefx#5760, j'espère que cela clarifie certaines choses.

Le côté .NET de UWP _est_ .NET Core. Cependant, .NET Core fournit plusieurs runtimes. UWP utilise le runtime basé sur AOT, de sorte que certaines fonctionnalités qui nécessitent un JIT ne sont pas prises en charge (telles que LCG ou RefEmit). Cependant, ils partagent les mêmes assemblys et (à l'avenir) les mêmes packages NuGet. Nous avons spécifiquement conçu la pile pour permettre le référencement croisé d'assemblys (et de packages) à partir d'UWP et d'ASP.NET Core.

Bien sûr, il existe en plus des outils VS appelés bibliothèques de classes portables (PCL) qui tentent de vous aider à créer des bibliothèques qui fonctionneront sur un ensemble de plates-formes. Il existe plusieurs choix que vous pouvez faire dans la boîte de dialogue de ciblage PCL qui se traduisent tous par la compatibilité de votre binaire avec .NET Core. Cependant, étant donné que la portabilité dans VS est déterminée en examinant les plates-formes, vous ne pourrez pas référencer une PCL à partir d'une application UWP à moins que cette PCL n'indique qu'elle peut cibler UWP. Ce comportement est inhérent à la conception, car l'idée est que les outils PCL vous aident à ne pas utiliser accidentellement des fonctionnalités qui ne sont pas prises en charge partout où vous devez les exécuter. À l'inverse, vous ne pouvez référencer que les PCL des plates-formes qu'il dit cibler.

Puisque vous mentionnez explicitement les surnoms, parlons-en également une seconde. La conception d'un surnom (TFM) est qu'il représente l'intégralité de la surface. Dans notre outillage, il y a deux surnoms :

• TargetPlatformMonikers (TPM)
• TargetFrameworkMoniker (TFM)

Considérez le TFM comme identifiant la totalité de la surface gérée, dans la boîte, tandis que le TPM représente le système d'exploitation sous-jacent, c'est-à-dire l'ensemble d'API fourni par le système d'exploitation.

Puisque nous avons conçu .NET Core pour qu'il soit portable sur plusieurs plates-formes, un TFM traditionnel n'a pas vraiment de sens. C'est pourquoi il existe un nouveau concept, appelé Standard Platform , anciennement appelé générations.

est-ce que cela aide?

Cependant, ils partagent les mêmes assemblys et (à l'avenir) les mêmes packages NuGet.

La plupart des assemblys ont la même DLL d'implémentation BINARY pour les applications NuGet Target 'netcore50' (WIndows UWP Store App) et NuGet Target 'dnxcore50' (ASP.NET v5 / ASP.NET Core 1.0).

Cependant, certains packages NuGet, comme de nombreux packages de bibliothèque System.Net.*, ont des implémentations différentes pour la cible « netcore50 » par rapport à la cible « dnxcore50 ». Par exemple, la bibliothèque System.Net.Http avec 'netcore50' utilise l'implémentation WinRT Windows.Web.Http en dessous. L'implémentation 'dnxcore50' utilise autre chose (WinHTTP natif).

Cependant, certains packages NuGet, comme de nombreux packages de bibliothèque System.Net.*, ont des implémentations différentes pour la cible 'netcore50' par rapport à la cible 'dnxcore50'.

Ouais, j'aurais dû le mentionner. La façon dont je vois cela est qu'un package NuGet fournit un conteneur qui permet au producteur de fournir différentes implémentations pour différents environnements d'exécution alors que les consommateurs n'ont pas besoin de le savoir. En ce sens, les packages NuGet sont les nouveaux assemblys.

Merci @terrajobst et @davidsh pour avoir partagé cette explication plus approfondie et ce problème de référence, mais qu'est-ce qui ne va pas avec ce que j'ai dit "1 assemblage d'une plate-forme ne peut pas être référencé par une autre" ?

La façon dont je vois cela est qu'un package NuGet fournit un conteneur qui permet au producteur de fournir différentes implémentations pour différents environnements d'exécution alors que les consommateurs n'ont pas besoin de le savoir. En ce sens, les packages NuGet sont les nouveaux assemblys.

Ce concept n'est en fait pas nouveau... Les gens créent déjà un package Nuget qui n'est rien de plus qu'une référence à un tas d'autres packages - les soi-disant "méta packages". Il existe plusieurs façons de faire fonctionner une PCL sur de nombreuses plates-formes. Les plus célèbres utilisées par de nombreuses bibliothèques populaires (comme Json.Net de Newtonsoft) sont Bait et Switch où vous avez un nuget qui a une interface publique (la surface API) et un assemblage pour chaque plate-forme spécifique (la véritable implémentation de la surface API) qui peuvent même avoir des dépendances différentes les unes des autres et lors de l'exécution, l'assemblage correct pour cette plate-forme sera sélectionné. La différence maintenant est qu'au lieu d'avoir plusieurs nugets "à l'intérieur" d'un seul nuget de conteneur où tous devraient être sur la même plate-forme ou 1 assemblage d'interface qui est juste utilisé par le développement et qui passera à celui spécifique au moment de l'exécution, nous avons un mélange de ça ! 1 nuget qui est un conteneur et en même temps l'interface publique pour tous les nugets spécifiques à la plate-forme qui lui sont liés.

Je pense qu'on parle de la même chose, je me suis juste mal exprimé au début :sourire:

Quoi qu'il en soit, revenons à WF ... Je pense qu'il est notoire que les gens veulent le faire porter sur WF, pas seulement "parce que c'est cool" pour l'exécuter sur Linux ou sur Nano Server. Les gens veulent également l'utiliser de manière légère sur les clients.

Encore une fois, je pense qu'il y a suffisamment de gens de la communauté pour que ce port existe...

PS : Pour ceux qui s'intéressent à l'informatique distribuée (la vraie, pas l'histoire du client hors ligne), veuillez jeter un œil à notre autre projet Orléans qui est en fait un bon cas d'utilisation pour WF sur .Net Core et qui habilite aujourd'hui les gros services Microsoft comme Skype, Halo5, et que je l'utilise personnellement comme technologie de base de ma plate-forme de traitement des transactions financières qui traite des milliards de transactions de manière distribuée...

@galvesribeiro

qu'est-ce qui ne va pas avec ce que j'ai dit que "1 assembly d'une plate-forme ne peut pas être référencé par une autre" ?

Ce n'est pas que votre déclaration est fausse; c'est juste que ce n'est pas bien non plus :smile: Normalement, je ne suis pas le genre de personne qui aime pinailler, mais ce qui m'a découragé, c'est cette partie :

En d'autres termes, vous ne pouvez pas ajouter un assembly .Net Core à un UWP.

Je veux éviter de donner l'impression que UWP et .NET Core sont des plates-formes .NET différentes, telles que .NET Framework et Silverlight. Nous avons spécifiquement conçu .NET Core pour que vous puissiez créer des assemblages qui fonctionnent sur toutes les plateformes. Par exemple, System.Collections.Immutable et la quasi-totalité de Roslyn sont des assemblages .NET Core qui fonctionneront également correctement dans UWP.

Donc, pour reformuler : notre objectif est de créer une plate-forme où de simples composants basés sur MSIL peuvent littéralement utiliser le même binaire sur toutes les plates-formes basées sur .NET Core. Dans les cas où cela n'est pas possible, par exemple, en raison de dépendances natives ou d'implémentations différentes, nous faisons exactement ce que Paul Betts a décrit avec tant d'éloquence sous le nom de Bait and Switch PCL : surface portable, implémentations variables par plate-forme, et NuGet comme conteneur et sélecteur.

Dans le monde .NET Core, les bibliothèques System ne sont pas vraiment spéciales. N'importe qui peut utiliser la même technique pour s'assurer que la plupart des consommateurs n'ont pas à encombrer leur base de code avec des directives #if .

Je pense qu'on parle de la même chose, je me suis juste mal exprimé au début :sourire:

Je pense que nous avons créé un monde où il est un peu trop facile de confondre les gens - ce qui nous inclut évidemment :smile: C'est pourquoi j'essaie si fort d'être précis sur la façon dont .NET Core a été construit et sur les problèmes que nous avons essayé de résoudre.

Oui, tu as raison. C'est l'impression qui compte.

J'espère qu'un jour nous appellerons également .Net Core sur UWP, donc ce sera fini ... Donc, nous avons toujours besoin de system.xaml

Bien que lié, je pense que System.Xaml est un composant distinct qui ajoute de la valeur en soi. J'ai déposé dotnet/corefx#5766 pour suivre cela séparément.

Merci Michael-DST

De plus, je suis curieux de savoir ce que vous pensez d'Azure Mobile Services (https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/) et si vous avez envisagé de l'utiliser dans votre histoire hors ligne ?

Excellente question. Cela nous amène à une petite leçon d'histoire sur l'expérience de notre entreprise avec l'informatique distribuée, c'est-à-dire les applications occasionnellement connectées, et sur la manière dont cela est lié aux services mobiles Azure et à l'informatique distribuée avec la technologie Microsoft.

Si les gens n'ont pas vu le site Web mentionné ci-dessus, je recommande fortement de le consulter. Il contient une bonne vidéo sur Azure Mobile Services.

Il y a environ 8 ans, nous avons créé une application pour la plate-forme Windows Phone d'origine. La vieille école avec .Net Compact Framework. Les gens peuvent se moquer de cela, mais sur certains points clés, cette plate-forme était plus avancée que la plate-forme UWP actuelle en ce qui concerne la technologie occasionnellement connectée. Cependant, il semble que UWP rattrape son retard. Les clés du succès des applications occasionnellement connectées sur cette plateforme étaient :

1) Implémentation complète de la base de données SQL (SQL Server CE)
2) Implémentation de Sync Framework entre SQL Server (backend) et SQL Server CE (appareil mobile). Il s'agissait de la version 1 de Sync Framework.

Cette application a été un succès. Nous avons écrit une couche de données reposant sur SQL CE et SQL Server qui a été déployée sur le serveur et déployée sur les appareils. Il a presque maximisé la mémoire mais cela a fonctionné. Les travailleurs sur le terrain ont pu effectuer la saisie des données sur le terrain et les données ont été synchronisées avec la base de données centrale.

Nous avons été horrifiés lorsque Windows Phone 7 est sorti car il y avait un problème crucial : toutes les bases de données du marché étaient des bases de données non SQL. Ils ont été principalement implémentés avec LINQ. Ce n'était pas compatible avec notre couche de données et EF n'existait pas pour Windows Phone 7. Nous n'avons donc pas pu créer de cadre occasionnellement hors ligne pour Windows Phone 7, même si nous avions pu créer une solution complète pour l'original. Plate-forme Windows Phone.

Silverlight a changé la donne. Encore une fois, nous sommes tombés sur une base de données SQL complète. Mais, Microsoft n'avait pas implémenté le cadre de synchronisation pour Silverlight, ou pour la base de données en ligne en question. Nous avons donc commencé à écrire notre propre framework de synchronisation sur le modèle du framework de synchronisation de Microsoft. Le cadre de synchronisation Microsoft est basé sur les horodatages. C'est ce que nous avons implémenté dans notre framework de synchronisation. Encore une fois, nous avons eu un succès complet avec Silverlight. Les travailleurs sur le terrain ont pu emporter des tablettes Windows sur le terrain, capturer des données, puis les synchroniser avec la base de données centrale. Le problème était que cela n'était jamais disponible pour les téléphones. La plate-forme de base de données n'existait pas pour Windows Phone 7.

Comme je l'ai mentionné plus tôt, nous voulions implémenter une logique métier avec WF, mais Silverlight a été abandonné et personne n'a même parlé de la possibilité de porter WF vers Silverlight.

Enfin, nous arrivons à UWP. Un wrapper pour SQLite a été écrit pour UWP, et avec quelques hacks sur le wrapper, j'ai pu étendre l'interface avec SQLite pour nous permettre de travailler à nouveau avec une base de données SQL complète. Cela signifie que notre couche de données est compatible avec elle. Notre couche de données et nos couches de synchronisation fonctionnent désormais sur .Net, Silverlight et UWP, avec SQL Server, SQLite et une autre plate-forme de base de données sans nom.

Aujourd'hui, c'est la première fois que je vois une synchronisation se produire avec la pure technologie Microsoft grâce à Michael-DST. Fondamentalement, je peux dire que la synchronisation des services mobiles Azure n'est que le changement de nom de Microsoft Sync Framework. Il a une interface API un peu différente, mais les bases sont les mêmes que le cadre de synchronisation Windows Phone d'origine que nous avons utilisé pour que la synchronisation fonctionne il y a environ 8 ans. Je peux voir qu'il utilise même les deux mêmes champs d'horodatage pour suivre les modifications de données. Celles-ci ont été introduites dans SQL Server en tant que fonctionnalité principale de SQL Server 2008. Notre infrastructure de synchronisation fonctionne plus ou moins de la même manière que l'infrastructure de synchronisation Microsoft.

Donc, pour répondre à la question de Michael, je vais étudier cette technologie. Je vais voir si cela peut remplacer notre cadre de synchronisation. J'aimerais le vider et laisser quelqu'un d'autre le maintenir. Voyant qu'ils ont mentionné qu'il prendrait en charge SQLite, cela semble prometteur car il semble que nous pourrons pirater le wrapper SQLite pour continuer à utiliser la base de données SQL complète, et donc pouvoir continuer à utiliser notre couche de données. Si tel est le cas, cela signifie que plus de 5 ans de code de cadre de synchronisation iront directement à la poubelle.

Quoi qu'il en soit, le fait est que Microsoft semble reconnaître une fois de plus que l'informatique distribuée est importante. Si c'est important, WF doit être porté sur UWP. UWP est l'avenir, et donc aussi l'avenir de l'informatique distribuée avec la technologie Microsoft. L'avenir de la technologie distribuée a besoin de WF.

Bien que lié, je pense que System.Xaml est un composant distinct qui ajoute de la valeur par lui-même. J'ai déposé dotnet/corefx#5766 pour suivre cela séparément.

Merci beaucoup @terrajobst ! Je ne suis pas d'accord avec tout ce que vous publiez en ligne/twitter, mais je suis un grand fan de la façon dont vous facilitez le dialogue et la communication entre les développeurs/la communauté et je serai toujours d'accord avec cela. :) Cela signifie vraiment beaucoup pour moi personnellement, car cela me semble prendre plus d'un an de patinage en montée pour obtenir quoi que ce soit de MSFT (et oui, je réalise que ce n'est pas un engagement, mais à ce stade, tout est significatif).

Donc, pour répondre à la question de Michael, je vais étudier cette technologie.

Génial @MelbourneDeveloper , heureux de vous aider ! Je pense qu'Azure a vraiment une solide maîtrise de leur groupe. Avec VSO/VSTS, ils écoutent vraiment leurs développeurs et obtiennent un *_lot *_done. En fait, cela semble être le cas avec tous les groupes de MSFT _sauf_ pour le groupe UWP, qui ne semble vraiment pas faire grand-chose et ne semble même pas comprendre sa propre technologie (et n'entrons même pas dans leur définition de "Xaml").

Actuellement, nous utilisons WF pour plusieurs de nos services de base et nous élargissons encore notre utilisation car nous avons eu une excellente expérience avec Workflow et avons notre logique métier dans un format aussi visuel et facile à comprendre.

Comme l'a dit @MelbourneDeveloper

Quoi qu'il en soit, le fait est que Microsoft semble reconnaître une fois de plus que l'informatique distribuée est importante. Si c'est important, WF doit être porté sur UWP. UWP est l'avenir, et donc aussi l'avenir de l'informatique distribuée avec la technologie Microsoft. L'avenir de la technologie distribuée a besoin de WF.

WF a été une technologie sous-estimée par de nombreux développeurs .NET car ils n'en avaient peut-être pas vu la valeur à l'époque (je ne l'ai pas fait dans le passé, mais maintenant je suis un grand fan de WF car je comprends à quel point il peut être puissant be!) mais à l'ère de l'informatique distribuée, maintenant plus que jamais WF peut vraiment briller et j'espère qu'il finira par être porté.

Je pense qu'il y a peu de place pour le désaccord sur ce sujet.

On peut certainement soutenir que la programmation visuelle déclarative telle que WF n'est pas aussi efficace que l'écriture de code. J'aurais même tendance à être d'accord. Mais, avoir WF comme outil dans la boîte à outils pour compléter une plate-forme configurable serait certainement une bonne chose. Les clients *_DO *_ veulent voir des flux de travail visuels, et permettre aux clients de modifier leurs propres flux de travail est certainement une bonne chose.

Il est temps de faire ça !

Je pense qu'il y a peu de place pour le désaccord sur ce sujet.

Haha @MelbourneDeveloper avez-vous déjà rencontré un développeur de logiciels ? Ou vraiment, la race humaine ? ;p

Personnellement, je pense que le concepteur visuel WF et les outils existants ont rendu un mauvais service à XAML, car les fichiers trop verbeux générés pour les flux de travail MSBuild ont vraiment donné à Xaml une mauvaise réputation à cet égard. C'est vraiment ce que les développeurs associent à Xaml ("fichiers gonflés") et ont aidé à lancer le vol vers des fichiers JSON "plus simples" et des fichiers de construction "scriptés". Sans parler de tout le processus obscur, difficile et fastidieux (je n'arrive toujours pas à le faire fonctionner pleinement dans mes projets) de même créer un projet pour afficher le fichier Xaml pour commencer.

Alors qu'en fait, la façon dont WF fonctionnait était la "bonne voie" depuis le début. Son vrai mal était dans son outillage.

En tant que tel, si l'outil de conception était un peu plus convivial (et faisait peut-être un meilleur travail avec la sérialisation des fichiers d'une manière plus organisée/compartimentée), ce ne serait pas un problème (ou moins).

Je suis un grand fan du chemin de ce que WF visait, mais il doit être un peu resserré et son outillage adressé et amélioré. Vraiment, en fin de compte, une technologie n'est aussi bonne que ses outils de support - les concepteurs et tout. Plus les outils/concepteurs sont bons, plus ils sont accessibles/compréhensibles, meilleure est la technologie, meilleure est l'adoption.

J'aimerais vraiment que WF ressemble davantage à EF et soit accessible dans n'importe quel scénario .NET, et que les outils soient améliorés pour faciliter exactement cela.

Je crois comprendre que l'une des visions originales de WF était de prendre en charge plusieurs types de fichiers pour les flux de travail, pas seulement XAML. Dans l'ensemble, à part quelques bizarreries ici et là, je n'ai pas vraiment eu de problèmes avec XAML. Il a juste fallu un certain temps pour que ma tête s'y mette et que je me sente à l'aise de le modifier manuellement si nécessaire, ce qui, j'en suis sûr, présente un obstacle à l'entrée pour de nombreuses personnes. Ainsi, même si je pense que XAML doit être maintenu pour une compatibilité descendante (au moins à court terme), j'aimerais vraiment voir d'autres types de fichiers de flux de travail commencer à se développer (comme JSON). J'ai pu voir quelques contributions sympas de la communauté sur ce front ! (Workflows écrits en Whitespace quelqu'un? :smile: )

@Michael-DST Je suis entièrement d'accord avec vous. Récemment, mon équipe et moi avons passé en revue les goûts/détestes/souhaits pour Workflow et presque tout ce que nous voulions voir amélioré concernait le concepteur et pas nécessairement le cœur de WF lui-même. Je pense que Microsoft a fait un travail fantastique avec ce qu'ils ont construit dans WF et je pense que quelques améliorations et un peu d'évangélisation pourraient lui donner une nouvelle vie. Je pense que c'est un outil qui DOIT exister et j'ai tiré une tonne de valeur de WF et je veux le voir continuer pendant longtemps.

Notre entreprise a fait des investissements considérables dans WF et est maintenant une technologie essentielle pour notre entreprise. Compte tenu de l'engagement récent de MIcrosoft envers l'open source et .NET Core, le portage de WF semble être la meilleure prochaine étape pour cette technologie. Nous en avons besoin!

Le workflow a été un outil avec de nombreux avantages pour nous en tant que développeurs au sein de notre organisation. Si Microsoft veut unifier ses frameworks, cela nous faciliterait la vie d'avoir WF dans le framework de base.

Haha @MelbourneDeveloper avez-vous déjà rencontré un développeur de logiciels ? Ou vraiment, la race humaine ? ;p

Haha, je suis un développeur de logiciels. La race humaine est sans importance pour moi.

Michel-DST

Personnellement, je pense que le concepteur visuel WF et les outils existants ont rendu un mauvais service à XAML, car les fichiers trop verbeux générés pour les flux de travail MSBuild ont vraiment donné à Xaml une mauvaise réputation à cet égard. C'est vraiment ce que les développeurs associent à Xaml ("fichiers gonflés") et ont aidé à lancer le vol vers des fichiers JSON "simples" et des fichiers de construction "scriptés".

Vous avez probablement raison. Mais, je pense personnellement qu'il y a trop d'emphase sur le Xaml ici. Lorsque j'ai testé WF (avant de réaliser que nous ne pouvions pas l'utiliser car il n'existe pas sur Silverlight), j'ai créé une application WPF. Cette application s'est connectée à nos services WCF et a stocké le Xaml pour le WF dans une table de notre base de données. C'est ainsi que nous avons réalisé le codage souple de WF.

Mais, le Xaml a été entièrement manipulé à l'aide de l'outil de conception WPF WF. L'utilisateur n'a jamais vu le Xaml. Le xaml n'était pas pertinent pour l'utilisateur. Considérez-le comme le balisage HTML derrière une page Web. Cela pourrait être extrêmement compliqué, mais tant que l'utilisateur final aime la page Web, cela n'a pas vraiment d'importance. Je pense que si vous manipulez le Xaml directement en tant que texte, vous n'utilisez vraiment pas WF comme prévu de toute façon ...

La race humaine est sans importance pour moi.

Agréable. B)

Mais, le Xaml a été entièrement manipulé à l'aide de l'outil de conception WPF WF. L'utilisateur n'a jamais vu le Xaml.

Correct. C'est exactement ainsi que fonctionne MSBuild et les utilisateurs finaux le détestent en raison de la taille des fichiers qu'il génère (surtout lorsque vous les comparez à de simples fichiers "script" très basiques et linéaires). Je suis d'accord avec vous qu'il s'agit d'un problème d'outillage/concepteur, et je dirais également que l'outillage/concepteur pourrait être considérablement amélioré avec WF.

Exemple : articles de blog et copier/coller du code (ou vraiment, copier/coller _workflow_ :smile:). Il y a eu plusieurs fois où j'ai fait des recherches en ligne pour WF, et je suis tombé sur un joli billet de blog qui montrait quelques étapes à suivre pour mettre dans un composant de workflow (très probablement pour MSBuild). Eh bien, pour ce faire, j'ai dû dupliquer un tas d'étapes. Habituellement sur un article de blog de codage, le code est disponible pour un simple copier/coller. Ce n'est pas le cas avec WF. Vous devez le faire étape par étape jusqu'à ce qu'il ressemble exactement sur votre machine à ce qu'il apparaît sur le blog. C'est évidemment très fastidieux et sujet aux erreurs (et donne totalement l'impression de prendre du recul, d'un point de vue C#).

L'autre problème que nous avons rencontré avec MSBuild est la taille du fichier, non seulement en octets mais aussi dans le concepteur lui-même : il était vraiment difficile de naviguer dans un flux de travail complexe. Cela semble être quelque chose qui devrait être pris en compte de manière très complète (et intuitive).

Enfin, je veux conclure sur la taille du fichier. Je ne sais pas si vous connaissez WordML et/ou MSFT Frontpage à l'époque. Mais cela créerait le code HTML le plus gonflé au monde. Bien que les utilisateurs ne mettent généralement pas la main sur le balisage qui en résulte, ils aiment y mettre leur nez pour avoir une idée de sa "propreté". La première chose qu'ils regardent est la taille sur le disque, puis d'ouvrir le fichier pour voir comment il est formaté, etc.

Encore une fois, je suis d'accord sur le fait que la façon dont ces fichiers sont construits est strictement un problème d'outillage/concepteur, mais les développeurs deviennent curieux et cela devrait également être pris en compte. :)

Oui. Tous les bons points. Je pense que le concepteur aurait besoin d'être nettoyé pour qu'il ne crée pas un Xaml aussi verbeux.

Qui a réellement le pouvoir de décider si WF est porté sur .Net Core ou UWP ? Est-ce juste le cas d'un développeur quelque part qui écrit le code, puis soumet ce correctif aux administrateurs du référentiel de base de code .Net Core ? Quelle est la politique autour de cela? N'y a-t-il pas une équipe centrale de développeurs influencés par Microsoft ? Sont des employés de Microsoft ? Je ne comprends toujours pas tout le montage. Qui devons-nous convaincre ?

En fait @MelbourneDeveloper rien qu'en participant à ce fil, vous contribuez à faire valoir l'argument. Il y a une équipe chez MS qui possède WF, actuellement la mienne, mais nous ne prenons pas la décision de publier WF sur Core. Nous devons faire l'analyse de rentabilisation. La discussion ici m'aide à le faire.

C'est vraiment impressionnant de voir comment les gens ont commencé 2016 en soutenant ce fil :)

De plus, le https://github.com/dotnet/corefx/issues/5766 de @terrajobst est devenu beaucoup plus occupé ces jours-ci :)

@dmetzgar J'espère que vous recueillerez autant de commentaires que vous pouvez / avez besoin de ces discussions afin que vous ayez suffisamment de cas pour l'OSS.

Je suis à peu près sûr que si un référentiel dotnet/WF est ouvert ou s'il est ajouté à corefx, les gens le développeront définitivement très rapidement.

En fait @MelbourneDeveloper simplement en participant à ce fil, vous aidez à faire valoir l'argument

Cela me fait me sentir chaud et flou.

Juste pour info dmetzgar - Je suis plus qu'heureux de documenter nos expériences et de présenter un cas convaincant pour aider à établir des preuves pour l'analyse de rentabilisation du port.

Je suis à fond dans la technologie Microsoft depuis 2000. J'ai vu toutes les principales technologies pertinentes pour ce fil se développer et s'estomper. Bien que je sois immergé dans la technologie Microsoft, je la vois toujours d'un point de vue objectif et je pense que WF est l'une des technologies clés qui aiderait à développer l'adhésion des entreprises et des gouvernements aux plates-formes .Net Core et Windows UWP.

Rien n'excite plus un client que les organigrammes ! Rien!

Je dois également dire que la technologie Microsoft est sur le point de devenir quelque chose de grand.

Pendant tant d'années, j'ai vu la bonne technologie monter et descendre. La principale raison pour laquelle la technologie a été abandonnée est l'évolution du paysage des appareils. Auparavant, la stratégie consistait à créer une plate-forme pour chaque famille d'appareils. Il n'y avait rien d'intrinsèquement mauvais dans cette approche. Mais cela signifie porter des technologies entre plates-formes. C'est onéreux, et il n'est pas rare que des technologies tombent à l'eau parce qu'une plate-forme devient soudainement désagréable (toux - Silverlight).

Microsoft se positionne désormais derrière .Net Core et UWP. Bien que je pense que ces deux plateformes devraient être une seule et même plateforme, je suis toujours très optimiste sur le fait que lorsqu'une technologie donnée est créée ou maintenue, elle fonctionnera sur de nombreuses plateformes. Xamarin renforce encore mon optimisme.

Il semble vraiment que pour la première fois dans l'histoire, nous regardons à bout portant un ensemble de technologies qui fonctionnent sur une très large gamme de processeurs et d'environnements d'exploitation. Si Microsoft pousse fort, WF en fera partie.

Cela me fait me sentir chaud et flou.

:+1: sur ce @MelbourneDeveloper et @dmetzgar. C'est le genre d'engagement et de dialogue que j'aime personnellement voir sortir de MSFT, plutôt que les appels ignorés et les appels sans réponse de sa base passionnée ( c'est juste méchant, c'est méchant, mec ).

Un aparté aléatoire ici : à mon avis, NodeJS étant la seule analyse de rentabilisation/menace dont vous avez besoin, un article aléatoire sur lequel je suis tombé récemment .

Enfin, à mon point de "si .NET Core est assez bon pour EF, il devrait être assez bon pour WF" ... si WF est allé à .NET Core, existe-t-il un moyen de l'intégrer à EF afin que EF serve comme son backend en quelque sorte? C'est un cas convaincant ici, si c'est le cas. Si ce n'est pas le cas, cela vaut toujours la peine d'être pensé (voir : discussion/dialogue/brainstorming/etc). :)

Enfin, à mon point de "si .NET Core est assez bon pour EF, il devrait être assez bon pour WF" ... si WF est allé à .NET Core, existe-t-il un moyen de l'intégrer à EF afin que EF serve comme son backend en quelque sorte? C'est un cas convaincant ici, si c'est le cas. Si ce n'est pas le cas, cela vaut toujours la peine d'être pensé (voir : discussion/dialogue/brainstorming/etc). :)

C'est une pensée intéressante. Quel est votre cas d'utilisation pour intégrer EF et WF ? Pouvez-vous donner un exemple? Est-ce pour la persévérance ?

Pouvez-vous donner un exemple? Est-ce pour la persévérance ?

À tout le moins, il pourrait être utilisé comme modèle de support avec lequel le flux de travail fonctionne dans le domaine d'application. Tout au plus, il pourrait en fait servir de mécanisme de stockage pour le flux de travail lui-même (mais je ne le recommanderais pas - Xaml est bien mieux adapté à cela).

Je peux voir ici un paradigme WPF-esque où vous pouvez définir des flux de travail dans Xaml, puis les lier aux propriétés des éléments de flux de travail, en utilisant des données d'entités de modèle définies, modifiées et stockées dans EF.

Certes, mon expérience avec WF est limitée ici (ceux qui ont une vaste expérience pourraient intervenir ici). Mais, si cela fonctionnait pour WPF, cela pourrait fonctionner pour WF. En fait, j'utilise ce même paradigme (c'est-à-dire le développement basé sur WPF-esque Xaml) pour une application console que j'utilise pour mon projet actuel . Certes, il n'utilise pas (encore) de liaisons de données comme je le suggère, mais celles-ci sont facilement produites, comme nous l'a montré OmniXaml/Perspex. :des lunettes de soleil:

@Michael-DST Je préférerais éviter trop d'intégrations. WF doit être un package NuGet autonome. L'intégration de WF et EF ensemble devrait être un projet séparé. Commencez à combiner trop de choses et vous pourriez vous retrouver avec Oslo .

Je suis d'accord avec @dmetzgar :+1:

EF est un fournisseur de stockage/persistance. Il doit s'agir d'un package NuGet diff et être injecté au moment de l'exécution. WF ne doit fournir qu'un ensemble d'interfaces et c'est tout.

Nous l'avons plutôt bien fait avec les fournisseurs de stockage sur Microsoft Orléans.

@dmetzgar (et @galvesribeiro) ont accepté. Je ne suggère pas une intégration requise, mais une proposition de cas d'utilisation/valeur possible. (Voir : remue-méninges. :sourire :)

Quel est votre cas d'utilisation pour intégrer EF et WF ? Pouvez-vous donner un exemple? Est-ce pour la persévérance ?

Je veux intervenir sur celui-ci! Encore une fois, cela se rapporte à l'expérience de mon entreprise. En fin de compte, nous aimerions utiliser EF pour la persistance des données dans des bases de données en ligne telles que SQLite pour les applications occasionnellement connectées. En fin de compte, UWP/.Net Core aurait EF, SQLite, Azure Mobile Services et WF travaillant tous en harmonie. Je me répéterais si j'expliquais pourquoi nous voulons que cela se produise, mais je peux expliquer pourquoi EF et WF fonctionneraient bien ensemble. Bien que nous ayons trouvé une limitation dans EF qui nous a arrêtés dans notre élan dans le passé - et c'est l'autre raison pour laquelle nous avons dû créer notre propre ORM.

Nous avons un système dans lequel l'accès aux données déclenche des événements tels que "BeforeLoad", "BeforeSave", etc. Nous laissons des crochets dans ces événements afin que lorsqu'un type d'enregistrement donné est enregistré, nous puissions y mettre une logique métier personnalisée. Actuellement, nous l'avons fait en nous connectant à des DLL de logique métier personnalisées. Chaque client a son propre ensemble d'événements personnalisés. Nous avons également mis en place des appels à WF. Ainsi, par exemple sur l'événement BeforeSave, nous pourrions y mettre une validation en faisant un appel à WF qui valide les champs obligatoires. De cette manière, la logique de validation était codée en douceur pour un client donné. À long terme, nous avons dû abandonner WF à cette fin car il n'a jamais été implémenté sur Silverlight, mais cela aurait été bien de l'avoir en option.

Quoi qu'il en soit, je pense que c'est une exigence assez universelle pour toute application. De manière générale, vous voudrez toujours une couche juste au-dessus de la couche de données qui valide les données entrant dans la base de données ou effectue une logique métier générale. Par exemple, nous avons une logique métier pour certains clients qui envoient des e-mails lorsqu'un enregistrement d'un type particulier est ajouté à la base de données. Cela pourrait être fait dans WF. Ce serait formidable de mettre en œuvre quelque chose comme ça avec EF et WF travaillant en harmonie.

Hélas, je n'ai jamais trouvé le moyen de le faire avec EF, même sur .Net. Le problème que j'ai trouvé, c'est que EF ne vous dit pas quand un enregistrement d'un type donné est sur le point d'être sauvegardé. Ainsi, par exemple, si vous créez un nouvel objet "Task" et que vous le conservez dans la base de données avec EF, aucun événement déclenché par EF ne contient quelque chose comme "RecordInserted". Cela nous permettrait de créer des liens vers l'accès aux données afin que des activités personnalisées puissent être insérées. C'est donc l'une des raisons pour lesquelles nous n'avons jamais opté pour EF. C'est dommage car la construction de notre propre ORM a pris des années à affiner.

Parler de "l'analyse de rentabilisation" de NodeJS : comment NodeJS domine .NET dans 3 graphiques simples

Attendre patiemment ce dépôt GitHub. Je viens juste de réaliser que WF n'avait pas été porté sur .NET Core, ce qui a pratiquement tué sa viabilité pour notre produit. Ce qui est dommage car nous aimons les changements apportés au noyau ASP.NET et à l'ensemble de l'idée multiplateforme, allégée et modulaire de .NET Core, mais nous avons besoin de WF car c'est la base de l'ensemble de notre produit.

Honnêtement, je suppose que je ne me soucie pas vraiment de savoir s'il s'agit de WWF, ou s'il s'agit d'un autre moteur de flux de travail bien pris en charge, mais je pense qu'à des fins d'extensibilité, un flux de travail quelconque pourrait être absolument énorme.

+1

Nous avons utilisé la génération dynamique (basée sur des règles externes importées) et le chargement de workflows en tant que services WCF. Ce serait super si nous pouvions utiliser un tel modèle dans le noyau .net !
BTW - quel est le problème de l'importation d'assemblages de .Net complet ? s'il s'agit principalement de code IL, pourquoi ne s'exécute-t-il pas dans le noyau .net ?

+1

@dmetzgar C'est incroyablement excitant de voir https://github.com/dmetzgar/corewf ! D'après le fichier readme, j'ai été surpris de voir qu'un port de l'équipe WF n'a pas gagné beaucoup de terrain. Surtout compte tenu du récent port Powershell avec Powershell Workflow qui sera limité au framework complet - Linux et Mac ne sont évidemment pas une cible majeure, mais le serveur Nano, j'imagine, est extrêmement important pour Powershell. Il est également mentionné que vous explorez des alternatives à XAML qui incluent d'autres implémentations Xaml telles que Portable.Xaml, par exemple, prend déjà en charge le profil 259 compatible avec CoreCLR ?

@watertree Portable.Xaml et d'autres implémentations XAML avec prise en charge de .NET Core que j'ai vues jusqu'à présent ont toutes une fonctionnalité manquante. Ils n'implémentent pas l'attribut x:Class="". C'est inutile pour WPF mais essentiel pour WF. Un flux de travail XAML a généralement

PowerShell Workflow a une très bonne façon de définir des workflows dans un script. C'est beaucoup plus propre que d'écrire la même chose en XAML ou C#. Cependant, PSWF convertit ce script en un fichier XAML dans les coulisses. Pour que PSWF fonctionne sur Nano, ils devraient remplacer leur pipeline existant et leur runtime WF afin qu'il n'utilise pas XAML. Et il n'y a vraiment pas assez de pression de la part des clients pour avoir PSWF sur Nano.

En ce qui concerne les alternatives à XAML, j'ai beaucoup d'opinions à ce sujet. Mon problème avec XAML est qu'il est intégré dans WF. Avec l'ancien WF publié dans .NET 3.5, l'équipe WF était davantage encouragée à convertir le format de votre choix en un flux de travail. Ils ont utilisé l'exemple de la conversion de diagrammes Visio en workflows. Mais lorsque le nouveau WF est arrivé en 4.0, tout était axé sur XAML. Avez-vous déjà essayé d'écrire manuellement un flux de travail en XAML ? N'arrive pas. Ensuite, il y a les symboles de débogage et l'état de la vue. Et essayez de comparer une version d'un XAML à une autre avec un outil différent.

Je pense vraiment que l'utilisation de XAML pour définir les flux de travail devrait consister à inclure un package NuGet. La création d'autres moyens de stockage des définitions de workflow doit être encouragée. Peut-être avez-vous besoin de quelque chose qui se comprime bien. Peut-être avez-vous besoin de sécurité et n'autorisez-vous qu'un ensemble limité d'activités. Je préfère avoir des options.

Ils n'implémentent pas l'attribut x:Class=""

En effet, Xaml compilé (baml ?) a été visiblement absent de toutes les variantes Xaml que j'ai vues. J'ai pensé à m'y plonger pendant mon temps libre, mais j'ai le sentiment qu'il sera bientôt disponible dans une certaine mesure, peut-être l'année prochaine. De plus, le système Xaml de Xamarin prend en charge cela, mais il est fermé et pas extensible/accessible du tout.

Avez-vous déjà essayé d'écrire manuellement un flux de travail en XAML ? N'arrive pas.

Vrai. Ironiquement, WF est le bienfaiteur le plus complet (de loin) de toute intégration Xaml. Pour une faute, peut-être. Il est dommage que Xaml ait été conçu pour être extrêmement convivial pour les concepteurs, mais l'outillage autour de WF est un peu prohibitif pour les scénarios écrits à la main, et même pour le concepteur lui-même. Il semble qu'ils visaient vraiment à en faire un langage de programmation visuel, mais sans la quantité importante de support/ressources dont il aurait besoin pour réussir.

Je pense vraiment que l'utilisation de XAML pour définir les flux de travail devrait consister à inclure un package NuGet.

J'aime ta façon de penser ! 👍

BTW, si vous ne l'avez pas encore fait, veuillez passer à la demande/problème de port System.Xaml et voter pour le problème si vous le pouvez. Pour ma part, j'aimerais vraiment voir un nouveau système Xaml open source et multiplateforme qui prend le meilleur de tous les systèmes connus et le fournit comme une saveur officielle et faisant autorité. Ne serait-ce pas sympa ? 😛

Quoi qu'il en soit, c'est jusqu'à 74 votes maintenant. Ce qui est assez génial étant donné que le vote a commencé avant que les réactions de GitHub ne soient disponibles :
https://github.com/dotnet/corefx/issues/5766

17 cœurs sont plutôt cool aussi. :)

Merci pour tout soutien (et commentaires continus) !

@dmetzgar Merci pour vos efforts ! Juste un commentaire sur XAML - J'avais l'habitude d'avoir une vision très négative de XAML parce que la plupart des fichiers que j'ai traités ont été créés avec des dialectes de XAML conçus pour les concepteurs visuels.

Tout a changé lorsque j'ai commencé à programmer avec Xamarin.Forms qui a une très belle API C# déclarative en plus de XAML. Il n'y a pas de concepteur visuel (seulement un aperçu qui est venu bien plus tard que la version XF). Étonnamment, je préfère de loin travailler sur leur dialecte XAML plutôt que sur le code C# ! Ils ont fait un excellent travail, et vous n'avez pas une tonne de métadonnées de concepteur polluant le sens du balisage. Les frameworks de support tels que Prism.Forms aident également à faire pencher la balance de manière drastique vers XAML, car il permet d'écrire très facilement du code sans code-behind.

Je ne pense donc pas que XAML en soi soit le problème, mais les dialectes conçus pour prendre en charge les concepteurs d'abord - XF est une preuve assez convaincante pour moi.

Une mise à jour sur ce sujet ?

Eh bien CoreWF est vivant et existe sur https://github.com/dmetzgar/corewf

Il faut voir si DynamicActivity peut maintenant être porté avec les nouvelles API de composition ajoutées au noyau et la norme .net 2.0.

Ce serait formidable si nous avions des nouvelles de l'équipe WF.

De nombreux commentaires intéressants et utiles ont été faits sur ce sujet. Pour ma part, je pense qu'il est utile que le runtime WF et le suivi des événements (c'est-à-dire sans les bits XAML, Transactions ou WCF) soient portés sur .NET Core et je suis heureux que cela ait été (en quelque sorte) fait.

Je suis d'accord que WF.Core doit exister officiellement. S'il était possible de créer une manière plus flexible de définir les flux de travail qui fonctionnent pour les développeurs, je pense que ce serait la meilleure approche. Je suis d'accord que XAML est un écrou dur à casser si MS dit qu'ils ne vont pas porter System.XAML, mais je veux vraiment voir WF.Core dans mes projets d'API Web .NET Core.

Je pense que l'énorme éléphant dans la salle ici est qu'il n'y a pas assez de traction pour faire décoller ce projet parce que MS et d'autres ont été très discrets sur toute information sur WF. Bien sûr, il y a quelques exemples sur MSDN, mais il y a très peu d'informations sous forme de livres ou d'autres matériaux solides (vérifiés).

Je suis définitivement prêt à consacrer du temps pour aider à donner vie à cela.

Ainsi, OmniXAMLv2 (il se trouve sur une branche du référentiel github), qui est toujours en développement, devrait prendre en charge les attributs x:Class (https://github.com/SuperJMN/OmniXAML/issues/12). Peut-être pouvons-nous l'utiliser pour (Core)WF ?

@ewinnington Merci de l'avoir signalé !
C'est certainement un gros morceau de celui-ci. De plus, .NET Standard 2.0 a un tas de types System.ComponentModel utilisés par WF. System.Transactions est déjà dans corefx. La seule chose qui manque est WCF ServiceHost.

WCF ServiceHost peut attendre à mon humble avis. Le modèle d'hébergement devrait être agnostique comme n'importe quoi d'autre dans le monde .Net Core/Asp.Net, je pense...

@galvesribeiro Je suis d'accord avec cela, étant donné qu'il existe de nombreuses autres façons dont WF peut fonctionner dans un monde .NET Core, y compris l'API Web.

Ouais. Cependant, je suis d'accord avec @dmetzgar qu'il y a un tas de clients qui utilisent aujourd'hui WCF donc le faire prendre en charge est un must mais encore une fois, cela peut être retardé...

En fait, l'hébergement et le "langage de conception" devraient être abstraits du runtime de base...

Nous utilisons WCF avec WF mais passerions volontiers à quelque chose comme WebAPI si WF était dans Core. En fait, nous sommes allés de l'avant et nous sommes passés de WCF à une alternative RESTful malgré tout. Nous obtenons une tonne de valeur de Workflow et c'est l'une de mes technologies .NET préférées !

Je pense également que WF sur le noyau ne devrait pas dépendre de xaml ou de wcf, le simple fait d'avoir le moteur wf et le modèle d'objet serait extrêmement précieux. Vous l'exécuteriez ensuite en tant que middleware sur le noyau asp.net, en particulier avec le nouveau travail de pipeline/non-http qui arrive sur Kestrel.

+1 pour avoir et prendre en charge le moteur WF et le modèle d'objet dans Core. Nous pouvons également contourner XAML et WCF.

XAML est cool - il vous permet de faire une configuration dynamique - dans un projet, nous chargeons des flux de travail xaml à partir de fichiers et ils sont représentés sous forme de points de terminaison WCF. Et ces fichiers XAML sont générés automatiquement à partir du registre des services disponibles. Ainsi, les services wcf obtiennent des points de terminaison :
https://[base]/wcf/[service_id1]
https://[base]/wcf/[service_id2] ...
Ce serait bien d'avoir une telle fonctionnalité dans le noyau .Net :)
Oh... je l'ai déjà écrit ici... :)))

Ouais, comme je me suis familiarisé avec le terrain ici, le support de Xaml dans WF n'est pas si important en soi, mais c'est plutôt le portage de System.Xaml qui est la partie importante. Étant donné que cela est clairement capturé dans un autre - et je suis assez heureux de dire assez populaire (mais ne laissez pas cela vous empêcher de voter, @ freerider7777 ! :sourire :) - problème, je suis en faveur de faire de WF une dépendance libre que possible pour s'assurer qu'il entre dans .NET Core. 👍

@Mike-EEE J'ai voté il y a longtemps !! :)

Étant donné que les flux de travail peuvent être créés via du code, l'utilisation d'une API Fluent similaire à EF Core serait-elle une option valable pour donner vie à WF Core ? Ensuite, la sérialisation/désérialisation pour l'exécution pourrait être construite par la suite et être beaucoup plus facile à mettre en œuvre ?

FluentAPIs... tellement chaud en ce moment. Ou du moins, depuis leur création. 😄

FluentAPIs, Builder Pattern, ils sont essentiellement les mêmes. Je pense que fournir une méthode basée sur un code qui peut être enchaîné et facile à utiliser devrait être un principe solide derrière cela.

Sans designer, tout est inutile. Bien sûr, nous pouvons tout coder nous-mêmes - toute la logique, toutes les chaînes et ainsi de suite (avec fluent ou sans). Mais ce qui est cool dans WF - vous pouvez voir visuellement le flux de traitement. C'est le lien entre les managers (et autres 'parties prenantes') et les développeurs ! Les managers ne comprennent pas le code, mais ces diagrammes de haut niveau sont compréhensibles par tous. Avec WF, vous n'avez pas besoin de diagrammes séparés (visio ou autre) s'ils sont séparés - ils sont généralement désynchronisés avec le code réel :)

@ freerider7777 La sérialisation de la définition WF n'est pas limitée à xaml (voir https://github.com/dmetzgar/corewf de @dmetzgar ). Il pourrait également être implémenté pour JSON . dans un navigateur Web, ouvrant de nouveaux cas d'utilisation pour WF)

Je pense qu'il est préférable de porter WF vers .NET Standard et pas seulement .NET Core. Le runtime WF lié précédemment fonctionne déjà sur .NET Standard 1.3 (nous pouvons descendre plus bas si nous supprimons l'activité WriteLine). Avec la sortie prochaine de la norme 2.0, nous aurons la possibilité de combler de nombreuses lacunes de fonctionnalités telles que les métadonnées de cache automatiques, DynamicActivity et les étendues de transaction. Nous devrions séparer les composants dans différents packages afin qu'il y ait un modèle de paiement pour le jeu : si vous voulez juste du temps d'exécution, vous pouvez vous en tenir à la norme 1.3, mais si vous voulez DynamicActivity, vous aurez besoin de la norme 2.0 et vous limiterez vos plates-formes.

Il y a certainement beaucoup de place pour l'amélioration du code d'exécution WF. Par exemple, je remplacerais les extensions d'activité par l'injection de dépendances. L'API Fluent serait intéressante pour écrire des flux de travail dans le code (et dans ce sens, regardez https://github.com/knat/Metah par @knat) mais je suis d'accord avec @freerider7777 que la possibilité de communiquer avec votre direction et vos BA à l'aide de diagrammes généré à partir de ce qui est réellement utilisé dans la production est un gros plus. @helmsb a beaucoup d'expérience dans ce domaine (consultez http://dotnetrocks.com/?show=1236).

Un nouveau concepteur devrait être une application Web. Cibler WPF ou UWP limiterait l'audience. Si OmniXAML se développe, les utilisateurs peuvent créer/modifier des flux de travail à l'aide des mêmes outils qu'ils utilisent aujourd'hui (solution VS ou réhébergée). Le problème est que, puisque le concepteur actuel est intégré au .NET Framework, toutes les fonctionnalités ou tous les correctifs doivent attendre une version du .NET Framework. C'est assez bon pour commencer mais pas une solution à long terme. @erikcai8 a fait quelques expériences avec un concepteur de sites Web, similaires à nodered. Je vais voir si je peux le convaincre de partager.

Pour le frontal du concepteur de workflow, une première tentative est disponible sur github : https://github.com/gary-b/WF4JSDesigner et vous pouvez l'utiliser en direct http://gary-b.github.io/WF4JSDesigner/

Voilà à quoi ça ressemble déjà :

@ewinnington : C'est super de voir le POC du concepteur de flux de travail Web. J'en ai également construit un autre comme illustré ci-dessous.

OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOUI !!! C'EST UN WF POC-OFF !!! 🎉

Hé hé. Hé @ erikcai8 où est l'exportation vers Xaml ??? Ha ha. Je te retourne juste du chagrin. En quelque sorte. 👼

Les deux efforts ont fière allure. C'est bon de les voir tous les deux. Cela semble assez évident maintenant, mais à quel point cela aurait-il été génial d'avoir un concepteur visuel basé sur le Web dans le WF original ? Tout est verrouillé et chargé, prêt à fonctionner, il vous suffit de visiter une URL. Je pense que cela aurait vraiment aidé avec l'image de marque et l'adoption. Malheureusement, tout le monde semble avoir atterri sur l'éditeur basé sur TFS, qui était très difficile à configurer et conduisait à un Xaml très verbeux. Ce fut une mauvaise expérience pour le développeur typique qui devait y faire face et qui donnait une mauvaise réputation à tout ce qui avait à voir avec l'expérience (WF ou Xaml).

Ceci, OTOH, semble être une excellente approche. Que la renaissance commence !

@Mike-EEE Mon expérience E2E a amélioré le Workflow Core Engine pour charger le workflow JSON de manière native afin que le format XAML ne soit pas requis. Le flux de travail XAML peut être exporté à partir du moteur de flux de travail une fois qu'il a chargé le flux de travail JSON.

C'est le but. Nous ne devrions pas lier le runtime et son modèle d'objet au concepteur et au format sérialisé comme c'était le cas dans WF 4.5...

@galvesribeiro Compris le point. L'expérience supposait cependant que le format JSON était pris en charge comme une autre option pour Workflow Core. Comme indiqué ci-dessus, XAML n'est pas encore compatible avec les dernières technologies Web.

Nous aimons WF, veuillez le porter sur .NetCore.

Nous avons besoin d'un concepteur de flux de travail basé sur le Web. La prise en charge du noyau .NET, pour exécuter les flux de travail, serait doublement génial. aller aller

Daniel Gerlag travaille ici sur un très bon moteur de flux de travail léger et compatible avec le cœur :

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

Daniel's a parcouru un long chemin en très peu de temps. Je vous encourage fortement à le regarder et à participer à ce projet si vous y trouvez du mérite.

Avec tout cet intérêt, pourquoi ne pas simplement créer un moteur compatible Net Core à partir de rien ?

@ccpony Parce que vous pouvez utiliser CoreWF sur dot net core dès maintenant -> https://github.com/dmetzgar/corewf . Les composants centraux sont portés et fonctionnent. Quelques éléments attendent la norme .net 2.0.

@ewinnington Merci d'avoir répondu, mais je ne comprends pas. WF n'était pas un produit MS réussi et MS n'a rien fait pour l'améliorer depuis des années. La communauté regorge de témoignages d'implémentations éprouvées. Il n'a pas été largement adopté dans l'entreprise. Il est lourd, trop complet, difficile à apprendre et (encore) bogué. Son interface est largement décriée. Il n'a pas réussi à devenir une technologie conviviale pour l'utilisateur final. Ses composants internes sont essentiellement une boîte noire qui ne peut pas être facilement améliorée. C'est LENT avec autre chose que de simples flux de travail. C'est très difficile à tester. Il est basé sur d'anciennes technologies (WCF, XAML). Depuis que Ron Jacobs est tombé malade, WF languit et n'a aucun ami chez MS.

À mon avis, WF a essayé d'être tout pour tout le monde et en fait, s'est avéré être peu pour tout le monde. Microsoft l'a pratiquement laissé tomber. Pourquoi voudrions-nous ressusciter quelque chose comme ça ? Si une technologie importante nécessitait une refonte et une réécriture, C'EST ÇA.

Regardez le projet naissant de Daniel Gerlag. C'est nouveau et immature. Mais il faut une approche moderne du flux de travail qui serait facile à améliorer. Si tout le monde ici arrêtait d'essayer de moderniser un projet complexe, daté et, franchement, sur-conçu et, à la place, mettait ses efforts dans quelque chose de nouveau et de meilleur, alors nous aurions une chance de nous retrouver dans un endroit valable - - construire progressivement un moteur de flux de travail de classe mondiale au lieu d'essayer de réécrire un mastodonte dès le départ. Honnêtement, j'admire tous ceux qui veulent s'engager dans un effort TRÈS valable - - créer, ENFIN, un outil de flux de travail (machine d'état?) Bien conçu, fonctionnel, léger, facile à apprendre et multiplateforme. Mais, je suis désolé de le dire, si vous continuez tous à suivre cette voie, alors tous vos efforts s'évanouiront dans le néant. MHO.

@ccpony Merci d'avoir partagé votre opinion. Pourriez-vous préciser à quels bogues vous faites référence ? S'il y a quelque chose que nous pouvons faire pour résoudre les problèmes dans le .NET Framework, je serais heureux de le savoir.

@dmetzgar Merci d'avoir répondu, Dustin. Pendant la période où j'essayais de développer des applications WF, j'ai rencontré des bogues. Pas seulement des comportements inattendus, mais il y avait plusieurs fois qu'un WF complexe "explosait" et générait des erreurs dans l'interface utilisateur XAML qui étaient difficiles à corriger dans le code XAML. Je n'ai jamais vraiment développé une grande confiance dans la technologie WF. Vraiment, j'en suis arrivé au point où j'avais l'impression de lutter contre un gorille de 800 livres - - pour chaque pas en avant, je finissais par reculer de deux pas.

Je sais que ce n'est pas ce que vous recherchez dans votre aimable demande pour moi d'élaborer sur les bogues. Franchement, je pourrais contourner ces bugs. Mais j'ai finalement abandonné WF pour toutes les autres raisons que j'évoquais dans mon post précédent.

Vous êtes le fer de lance de cet effort et je vous en félicite. Mais il arrive sûrement un moment où essayer de moderniser une technologie complexe devient contre-productif. En suivant tout ce fil, je ne peux tout simplement pas m'empêcher de penser que les progrès sont très lents - - voire pas du tout - - et que finalement rien ne ressortira de tout cela. Je trouve très peu probable que les anciens flux de travail soient portables sur tout ce qui est produit ici. Les personnes dans ce fil parlent de flux de travail basé sur le client (c'est-à-dire JavaScript), de compatibilité REST, de réduction des dépendances, de multiplateforme, etc. Par exemple, XAML est une partie si importante de l'ancienne technologie WF, quelle est l'utilisation XAML n'en fera pas partie ?

Alors Dustin, je dois vous demander ceci : nous sommes ici depuis 18 mois dans ce projet et il ne semble tout simplement pas y avoir de consensus sur le fait que de réels progrès sont réalisés. Je respecte vos efforts et je peux voir que vous êtes un excellent codeur - - mais voici ma question : ne serait-il pas BEAUCOUP plus logique de rassembler toute cette énergie et cet enthousiasme et de créer quelque chose de nouveau ?

@ccpony La discussion dans ce sujet est de prendre en charge WF .Net Standard et non l'inverse.

Simple curiosité... Avez-vous déjà utilisé ou vu un déploiement Sharepoint en action ? Si vous le faites, vous verrez que c'est vraiment fortement sur WF. Avez-vous déjà vu un déploiement BizTalk ? Le même.

Ce sont des produits MSFT majeurs dans le monde de l'entreprise, donc oui, il y a des utilisateurs qui se soucient de WF et il y en a une utilisation. Ce n'est pas un projet abandonné / abandonné comme vous l'avez dit.

Cela dit, si vous regardez le repo @dmetzgar , vous verrez que même si certaines choses sont similaires ou héritent de certains comportements de l'ancienne incarnation de WF, vous verrez également qu'il a été repensé pour être léger. La persistance est découplée et les gens peuvent facilement en créer de nouveaux. Le concepteur est découplé et les gens ont déjà créé plusieurs tests.

Je comprends votre frustration de vouloir quelque chose de nouveau. Croyez-moi, je veux que cela se produise aussi. Mais il faut comprendre @dmetzgar et son équipe. Ce n'est pas une priorité puisque 95% des clients sont des utilisateurs de l'ancien WF qui fonctionne essentiellement sur BizTalk et Sharepoint comme je l'ai mentionné. J'ai utilisé l'ancien WF pendant des années dans un environnement à très haut tps (transactions bancaires et financières) et il m'a très bien servi.

Ma nouvelle technologie fonctionne avec .Net Core, et la seule raison pour laquelle je ne l'utilise plus pour le moment, c'est parce que nous ne l'avons pas encore pour .Net Core.

Ce que j'ai déjà suggéré à @dmetzgar , c'est d'apporter le référentiel WF à .Net Foundation, de définir des jalons, d'y mettre le code et d'ajouter des tâches en tant que problèmes et de le marquer comme up-for-grabs pour que la communauté commence à le faire. Cependant, cela demande encore du temps à son équipe pour faire ce travail et ils n'ont peut-être pas (encore) ce temps disponible.

@galvesribeiro Je comprends votre point. Oui, j'ai écrit des déploiements SharePoint. Et j'ai vu des déploiements BizTalk en action ( * obturateur *). Je comprends la relation entre SharePoint et WF. (Je ne sais pas ce que vous voulez dire lorsque vous suggérez que BizTalk s'appuie d'une manière ou d'une autre sur WF. Ce n'est pas le cas.)

Mais je dois être en désaccord avec vous sur un point important : WF EST un projet abandonné/abandonné. Je comprends vraiment l'inquiétude des développeurs SharePoint à ce stade. Il n'y a aucune raison de croire que MS améliorera les capacités de WF dans SharePoint. Je ne comprends pas pourquoi vous pensez que les efforts de @dmetzgar auront quoi que ce soit à voir avec l'avenir de SharePoint (ou BizTalk). Ce n'est pas comme si MS modernisait SharePoint avec le code de @dmetzgar . Désolé, mais l'avenir de SharePoint n'a rien à voir avec les efforts déployés ici.

Donc, tout ce qui compte vraiment, c'est de savoir si un bon moteur de workflow sortira de tout cela. Et je soutiens qu'essayer de forcer un mastodonte comme WF dans le futur n'est pas la meilleure ligne de conduite. Mieux vaut construire à partir de zéro.

@ccpony Je voudrais vous rappeler qu'il y a de nombreuses personnes ici qui cherchent activement à voir ce projet prendre vie, et certaines mettent en fait du temps pour le concrétiser. Bien que vous puissiez personnellement considérer WF comme un produit raté de Microsoft, il continue de faire partie de .NET et est utilisé par plus que nous ici.

Ce fil devrait être destiné aux critiques constructives et à la contribution pour faire de la transition une réalité et non un claquement sur les autres ou le produit lui-même. Bien que vos points de vue soient respectés, notez qu'ils sont les vôtres et que d'autres peuvent penser différemment en ce qui concerne l'importance du WF pour eux.

Nous accueillons activement vos commentaires sur les moyens d'améliorer le produit et sur la meilleure façon d'aider ceux qui participent activement à la tentative.

Merci =^_^=

@ccpony

(Je ne sais pas ce que vous voulez dire lorsque vous suggérez que BizTalk s'appuie d'une manière ou d'une autre sur WF. Ce n'est pas le cas.)

Désolé, je m'exprime mal (je suis sur mobile). J'ai eu une application qui utilise les deux ensemble et j'en connais beaucoup d'autres qui le font aussi.

Il n'y a aucune raison de croire que MS améliorera les capacités de WF dans SharePoint.

Je ne dis pas que ce sera le cas. Je dis que l'équipe qui travaille avec WF Today est totalement concentrée sur le support des déploiements Sharepoint. Même la dernière version de Sharepoint utilise la même version/actuelle de WF.

Je ne comprends pas pourquoi vous pensez que les efforts de @dmetzgar auront quoi que ce soit à voir avec l'avenir de SharePoint (ou BizTalk).

Je ne dis pas que cela affectera l'avenir de Sharepoint. Je dis que l'équipe est occupée à supporter Sharepoint si j'ai bien compris. ( @dmetzgar peut me corriger si je me trompe)

Ce n'est pas comme si MS modernisait SharePoint avec le code de @dmetzgar . Désolé, mais l'avenir de SharePoint n'a rien à voir avec les efforts déployés ici

Si MS utilisera ou non WF vNext sur Sharepoint vNext, eux seuls peuvent le dire avec certitude. Encore une fois, le problème est que l'équipe WF n'est pas en mesure de gérer les deux.

Donc, tout ce qui compte vraiment, c'est de savoir si un bon moteur de workflow sortira de tout cela. Et je soutiens qu'essayer de forcer un mastodonte comme WF dans le futur n'est pas la meilleure ligne de conduite. Mieux vaut construire à partir de zéro.

Personne ne le porte tel quel. Le dépôt de @dmetzgar est la preuve qu'il est en train d'être entièrement repensé. Encore une fois, le problème est l'arriéré et la bande passante dont l'équipe dispose pour gérer les deux choses. C'est pourquoi j'ai suggéré de "l'ouvrir" sur la base dotnet et d'en faire un effort communautaire majeur avec les conseils et la curation de l'équipe WF afin que nous essayions d'affecter le moins possible leurs horaires.

Encore une fois, comme @InariTheFox et moi-même l'avons mentionné, ce fil est une avancée pour le port, ce qui ne signifie pas nécessairement forcer l'ancienne fersion avec toutes ces fonctionnalités vers la nouvelle version. Cependant, il est important de comprendre que les gens consacrent beaucoup d'efforts (et d'argent) à leurs produits actuels basés sur WF, donc @dmetzgar s'inquiète de la plus grande compatibilité possible avec les anciens flux de travail, c'est en effet quelque chose à surveiller.

D'accord. Je vois les passions ici. En fait, s'il y avait un bon remplacement de WF qui résolvait tous les problèmes que j'ai mentionnés précédemment, nous n'aurions pas cette conversation. Pour mémoire, beaucoup d'entre nous se sont éloignés de WF et ont attendu en vain la prochaine chose à venir. Cela n'a jamais été le cas. Au meilleur de ma connaissance, il n'existe AUCUNE solution de flux de travail/machine d'état actuelle, prise en charge, fonctionnelle et basée sur .Net qui soit largement considérée. Veuillez comprendre : je maintiens mon affirmation selon laquelle WF est une technologie morte du point de vue de Microsoft.

Mais cela dit, aidez-moi à comprendre. Le dépôt de @dmetzgar fonctionne-t-il tel quel ? Comment écrit-on des workflows avec ? Je ne vois aucun exemple de code et il n'y a aucune documentation. Comment procéderais-je ?

Je pense qu'il existe de nombreux produits / entreprises qui ont placé WF au centre de leur stratégie produit, ce n'est pas seulement une dépendance Sharepoint en mode support : dans mon entreprise actuelle, nous avons développé une plate-forme d'automatisation avec WF comme technologie centrale (et je sais 2 autres concurrents de ce marché qui utilisent également WF dans leurs produits) ; j'en ai aussi discuté avec des gens qui l'utilisent dans l'insurtech.. donc je crois fermement que le public de WF est toujours là.

Cela étant dit, .net core semble être l'un des domaines d'intérêt de Microsoft et de nombreuses innovations technologiques y seront consacrées au cours de la prochaine période ; Je pense que ce serait une grande perte de ne pas avoir WF dans le cadre de cela.

De mon point de vue, la bonne voie pour y parvenir est de rendre le noyau WF indépendant de xaml et de faciliter la (dé)sérialisation des workflows dans d'autres formats également (ex : json). Cela simplifierait également la mise en œuvre de scénarios tels que les concepteurs de flux de travail hébergés dans des navigateurs Web. Et avec le repo https://github.com/dmetzgar/corewf nous avons un point de départ.

Pour ceux qui sont intéressés par un aperçu de l'état actuel du WF (que je ne vois pas comme abandonné par MS), il y a quelque temps, j'ai centralisé les informations disponibles concernant le WF dans un article et une présentation http://andreioros.com/blog /windows-workflow-foundation-rehosted-designer/ ; Je le tiens toujours à jour

Nous et nos clients comptons sur WF et nous aimerions beaucoup le voir fonctionner aussi bien sur le client que sur le serveur. Un WF exempt de XAML et d'autres dépendances, conçu pour être léger mais avec l'expressivité du WF existant qui est également pris en charge par la communauté avec MS, serait en effet un produit passionnant et précieux.

Encore une fois, permettez-moi de vous demander : que faut-il faire avec le port de @dmetzgar pour lui donner un coup de pouce ? Quel est l'état actuel ?

Je ne savais pas que le port de @dmetzgar était réellement utilisable dans son incarnation actuelle...

De @ewinnington , ci-dessus :

"Parce que vous pouvez utiliser CoreWF sur dot net core dès maintenant -> https://github.com/dmetzgar/corewf . Les composants centraux sont portés et fonctionnent. Quelques éléments attendent la norme .net 2.0."

Auquel cas moi aussi j'aimerais entendre parler de son utilisation...

Oui, ce sont les bases des fonctionnalités de base. Vous pouvez exécuter des workflows basés sur du code. Les fonctionnalités manquantes de netstandard2.0 sont principalement liées à la prise en charge des transactions.

C'est plus une raison pour laquelle je suggère toujours de le démarrer ouvert et de faire contribuer les gens à un endroit central. Le fait de le diffuser rendra les choses encore plus difficiles à atteindre dans un produit final un jour dans le futur.

Votez pour la réécriture de WF avec des tests et la prise en charge des fonctionnalités modernes de Roslyn dans le cadre de Core. J'aimerais voir comment le sans serveur et les conteneurs pourraient affecter l'architecture, en particulier le déploiement et la mise à l'échelle des ensembles de règles dans des contextes de domaine et des processus métier distincts. Personnellement, je préférerais un DSL succinct à un concepteur WYSIWYG. Personnellement, j'aimais le designer, mais il me semblait bizarre presque tout le temps. WF lui-même avait le potentiel d'être extrêmement solide, mais nécessitait une expertise approfondie. En fait, un large déploiement de WF qui incluait WF Manager et des flux persistants dans SQL Server nécessitait des conseils MS et des corrections de bogues. Bien que je supporte maintenant les équipes Java depuis plusieurs années, j'aime garder un œil sur .NET après un peu plus de 15 ans à me concentrer principalement sur la technologie MS. Je lisais "Code Generation with Roslyn" de Nick Harrison (je n'ai aucun lien avec lui ou le livre) et je me suis demandé s'il ne fallait pas aborder à nouveau l'espace Business Rule Engine, ce qui m'a amené à m'interroger une fois de plus sur le sort de WF... en toute honnêteté, je pense qu'Azure Functions est en concurrence avec les ressources MS ainsi qu'avec leur volonté générale d'entreprise de soutenir des investissements importants dans WF n'importe où. Il semble évident qu'ils voudraient que vous l'utilisiez... alors, peut-être que la solution est de se concentrer plutôt sur une version .NET open source d'OpenWhisk. Mais, dans un monde conteneurisé, ... je peux simplement utiliser OpenWhisk en tant que service. Alors...

PS prenant simplement en charge une méthode robuste d'importation d'expressions externalisées pourrait résoudre 60% des exigences de l'application là-bas qui pensent qu'ils pourraient vouloir WF. Était-ce CSharpScript ? Un moyen simple d'importer des configurations de règles métier de base avec une API simple irait loin (diverses options de persistance, de récupération et de mise en cache). Avec une infrastructure virtuelle jetable (automatisation sur infrastructure, conteneur et plate-forme en tant que service), WF vNext pourrait se concentrer sur le déploiement des changements de version en tant que service plutôt que d'essayer de les intégrer dans les applications (c'est-à-dire une meilleure solution pour WF sur WCF)

Je suis extrêmement intéressé par cette conversation. Mon équipe a également été confrontée à la frustration de XAML. Notre dilemme est que nous créons notre propre concepteur d'interface utilisateur pour permettre à nos clients de créer leurs propres flux de travail sans avoir besoin de Visual Studio ou du concepteur réhébergé. Nous devons pouvoir enregistrer des morceaux de XAML dans des bits réutilisables afin que le client n'ait pas toujours besoin de réécrire ces bits (considérez-les comme des fonctions de flux de travail). Cela nous oblige à savoir comment fusionner des morceaux de XAML ensemble, ce que nous avons appris est extrêmement frustrant. Ce que nous pensons faire, c'est créer une abstraction où nous nous appuyons simplement sur un modèle de base de données de nos diverses activités et de leurs liens et ignorons complètement XAML. Nous créerons ensuite les activités, etc. par programmation à chaque exécution d'un flux de travail. En recherchant cette approche, je suis tombé sur ce fil. Continuez la conversation, je suis très intéressé d'avoir l'avis des autres.

@erikcai8 Workflow designer est une très bonne idée. Puis-je obtenir la source de votre concepteur de flux de travail ?

J'utilise WF depuis plus de 5 ans maintenant dans mes projets d'automatisation et c'était merveilleux. J'espère que de nombreux développeurs soutiendront cette demande et y parviendront. J'ai toujours utilisé la technologie .Net depuis que j'ai commencé à travailler et je voudrais continuer à le faire. Cependant, être capable de prendre en charge plusieurs plates-formes est la direction de l'entreprise, donc j'ai vraiment hâte de voir le WF complet dans .Net Core.

Avec l'arrivée du net standard 2.0, il serait bon d'avoir une mise à jour sur les problèmes de corewf :

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

Comment l'API ajoutée a-t-elle débloqué le processus de portage et que pouvons-nous faire pour vous aider ?

Je pense que indépendamment de netstandard2.0 , ce port devrait aller comme il allait à mon humble avis... Avec une réécriture... Le rendre convivial pour les planificateurs de tâches externes, async/wait/Task, et d'autres trucs modernes. Autant j'aime WF, autant la version actuelle est assez obsolète...

Je veux dire cela sans aucun manque de respect. Honnêtement. Mais suis-je le seul ici à comprendre que ce projet est sans espoir ? Nous avons désespérément besoin d'un bon moteur de workflow pour .Net, mais ce n'est tout simplement pas ça. Ne devrions-nous pas changer la conversation ici?

Je suis ouvert à un nouveau moteur de flux de travail amélioré. En fin de compte, nous en avons besoin d'un dans .NET Core. Nous utilisons WF depuis des années et cela a très bien fonctionné pour nous, donc c'est mieux que rien si c'est l'alternative.

@kalokamgit , la source est disponible sur la source de référence. C'est en deux montages :
System.Activities.Presentation et System.Activities.Core.Presentation .

Malheureusement, l'outil qui publie la source de référence ne fait que le code C#. Il n'inclut aucun des fichiers XAML. Vous pouvez fournir des commentaires à ce sujet à [email protected] et/ou voter sur le problème de la voix de l'utilisateur .

Le code se trouve dans le .NET Framework, vous êtes donc libre de l'utiliser dans vos propres outils. Quelques exemples sont le projet de @orosandrei et un exemple de projet ici .

Je veux dire cela sans aucun manque de respect. Honnêtement. Mais suis-je le seul ici à comprendre que ce projet est sans espoir ? Nous avons désespérément besoin d'un bon moteur de workflow pour .Net, mais ce n'est tout simplement pas ça. Ne devrions-nous pas changer la conversation ici?

Eh bien, si vous voulez _vraiment_ ne pas manquer de respect. :) Je suis curieux de savoir ce que tout le monde pense de Flow ? C'est ce à quoi je pense quand je pense "flux de travail" pour le "jour moderne" ... aussi ce qu'Azure colporte assez fort ces jours-ci.

Je le pense VRAIMENT VRAIMENT :)

Guess Flow est la réponse à la croissance de Zapier ? Je ne vois pas en quoi cela remplacerait le WWF de quelque manière que ce soit.

WF est-il interrompu ou ai-je raté quelque chose ici ? Ce serait bien triste !

Où puis-je voter pour WF?

Le meilleur article de ce numéro est le meilleur endroit.

Je me demande ce que @rjacobs (gourou WF) pense de cette affaire.

Vous voulez dire @ronljacobs ?

@dmetzgar Probablement oui. Il est le vrai héros WF

Ceci est ma réponse
https://github.com/danielgerlag/workflow-core

Ron Jacobs était le gars qui s'est investi corps et âme dans WF pendant des années et des années. Il a contracté la maladie de Dercum et a quitté Microsoft en 2013. (ici) Quand il est parti, c'était fini pour WF. Encore une fois, et j'espère pour la dernière fois : WF IS DEAD.

Et encore une fois - - J'encourage tout le monde et n'importe qui à regarder le projet de Dan Gerlag, ci-dessus. Il est éloquent, magnifiquement conçu et fonctionne sur Core. Quiconque souhaite contribuer à une solution de flux de travail viable doit la regarder.

Veuillez également consulter le cadre de tâches durables . Ceci est ajouté à Azure Functions, voir Fonctions durables .

@dmetzgar Ce cadre est dans les couches à considérer comme une alternative au WF. Je ne pense pas que ce soit sérieux que Microsoft propose ce genre de chose. Ne vaudrait-il pas mieux au lieu de réinventer la roue, de migrer WF vers .NET Core et de le réutiliser comme base dans tous les projets Microsoft ? Désolé pour la dureté de mes mots, mais je pense qu'ils représentent le sentiment de beaucoup de gens qui sont très déçus de la situation actuelle de WF.

@Suriman , bon point

J'ai mis à jour le fichier Lisez-moi sur le référentiel corewf pour avoir une meilleure description de ce qui est impliqué dans le portage de WF vers .NET Core. Cela vous dérangerait-il d'y jeter un œil ?

@dmetzgar Merci pour les clarifications et pour avoir clairement montré la voie à suivre pour porter WF vers .NET Core. Je comprends de ce que vous dites que Microsoft ne va pas faire tout ce travail de migration et qu'il espère que la communauté le fera, n'est-ce pas ? La réponse à cette question est la clé, selon la réponse, les entreprises peuvent opter pour une voie alternative ou faire le travail que Microsoft devrait faire.

Microsoft ne fera pas de portage officiel de WF vers .NET Core. Mon équipe et moi travaillerons là-dessus pendant notre temps libre, mais pas à titre officiel ou avec des versions programmées. Tous les problèmes énumérés sont à saisir. Il y a des utilisations pour un tel port pour certains des projets que nous réalisons. C'est de là que viennent la plupart de nos contributions. Je pense qu'il est juste de fermer ce problème pour l'instant et de diriger les gens vers le référentiel corewf pour suivre les derniers travaux.

Salut,
Le passage de Future Milestone à 2.1 signifie-t-il que Microsoft portera WF sur .NET Core ?

Le changement de jalon pour les problèmes fermés reflète simplement la version au cours de laquelle le problème a été fermé.
Ce problème particulier a été fermé essentiellement comme "Ne sera pas corrigé" - voir l'explication ci-dessus https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275

@karelz Quel dommage. Pendant un moment, il a semblé que la loterie nous avait frappés.

Nous avons une solution basée sur WF. Nous créons des étapes d'activités à l'aide de WF et ce flux de travail sera livré à tous les abonnés et ils traiteront les actions basées sur WF. Nous aimons trop WF. soutenir la multiplateforme est la direction de notre entreprise. Nous sommes très intéressés d'avoir WF sur .NET CORE.

Il y a CoreWF qui est le code de Workflow Foundation partiellement porté sur le noyau .net. Vous pouvez maintenant utiliser la plateforme multiplateforme Workflow Foundation. Vous ne pouvez tout simplement pas utiliser les flux de travail basés sur XAML pour le moment.

J'ai une branche où j'ai travaillé sur l'ajout de la prise en charge de l'activité dynamique en plus de Net Standard 2.0 .

Le processus d'analyse XAML nécessite que Microsoft ouvre suffisamment System.XAML pour que nous puissions progresser dans l'analyse correcte des fichiers.

Vous pouvez suivre l'évolution du problème ici : https://github.com/dmetzgar/corewf/issues/6 et dans mes diverses tentatives pour signaler ce problème :
Sur CoreFX
Sur la source de référence

Le pack de compatibilité .Net a un "Peut-être" sur le devant System.XAML. Mais aucune nouvelle n'a filtré sur son inclusion. Le problème Ship .Net Framework Compatibility Pack répertorie actuellement "aucun plan" pour System.XAML.

Peut-être aussi que le problème Customer Adoption Epic pourrait être utilisé pour raconter comment l'ajout de Workflow Foundation (et System.Xaml) permettrait à votre entreprise d'expédier un produit.

Mon entreprise est également investie dans WF : nous avons un produit pour les entreprises énergétiques où nos clients créent des flux de travail à l'aide de Workflow Foundation.

Merci pour votre réponse.
c'était très utile de l'apprécier.

Le 2 novembre 2017 à 18h22, "Eric Winnington" [email protected] a écrit :

Il y a CoreWF https://github.com/dmetzgar/corewf qui est le code de
Workflow Foundation partiellement porté sur .net core. Vous pouvez utiliser Workflow
plate-forme croisée de fondation maintenant . Vous ne pouvez tout simplement pas utiliser les flux de travail basés sur XAML
en ce moment.

J'ai une succursale où j'ai travaillé sur l'ajout de la prise en charge de l'activité dynamique
en plus de Net Standard 2.0 https://github.com/ewinnington/corewf .

Le processus d'analyse XAML nécessite que Microsoft ouvre System.XAML
suffisamment pour que nous puissions progresser dans l'analyse correcte des fichiers.

Vous pouvez suivre l'évolution du problème ici : dmetzgar/corewf#6
https://github.com/dmetzgar/corewf/issues/6 et dans mes diverses tentatives
à signaler ce problème :
Sur CoreFX
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
Sur la source de référence
https://github.com/Microsoft/referencesource/issues/39

Le pack de compatibilité .Net
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
a un "Peut-être" sur le devant System.XAML. Mais aucune nouvelle n'a filtré sur son
inclusion. Expédier le pack de compatibilité .Net Framework
https://github.com/dotnet/corefx/issues/24909 répertorie actuellement "non
plans" pour System.XAML.

Peut-être aussi le problème Customer Adoption Epic
https://github.com/dotnet/corefx/issues/24751 pourrait être utilisé pour dire
votre histoire sur la façon dont l'ajout de Workflow Foundation (et System.Xaml) permettrait
votre entreprise pour expédier un produit.

Mon entreprise est également investie dans WF : Nous avons un produit pour les entreprises énergétiques
où nos clients créent des flux de travail à l'aide de Workflow Foundation.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

Salut,
C'est un monde de micro-services et tout est décomposé en composants. Maintenant, si nous devons l'orchestrer, nous devrons dépendre des applications logiques Azure ou d'un autre fournisseur externe qui facture une prime pour un flux de travail. Bien que très peu de produits non .NET WF comme Netflix Conductor, nous aimerions en avoir un en version pure .NET core. Vous pouvez prendre les indices du conducteur Netflix sur https://github.com/Netflix/conductor et commencer à en construire un à partir de là. Ce sera une aubaine pour les développeurs de cloud privé qui n'ont pas accès à Azure Stack et qui ne peuvent pas utiliser Logic Apps.

J'ai pensé que je posterais ici par souci de sensibilisation. Je lisais la documentation suivante et cela m'a fait penser à ce fil:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

On dirait que Dynamics365 et PowerApps font une fusion mentale et utilisent maintenant Windows Workflow dans une certaine mesure pour la gestion de son flux de travail. Bien sûr, tout cela est uniquement Windows, mais dans la nouvelle ère du multiplateforme, etc., combien de temps cela durera-t-il ?

Je ne sais pas ce que je suis censé utiliser. Je souhaite que MSFT le fasse. Apportez de la clarté Microsoft.

@VenkateshSrini , vous devriez également vous pencher sur Cadence : https://github.com/uber/cadence
Le modèle ressemble plus au SWF d'Amazon, mais il est open source. Pas encore de client .NET.

La recherche d'un. Version de base nette

Ça n'arrivera pas.

De : VenkateshSrini [email protected]
Envoyé : mercredi 26 septembre 2018 00:30
À : dotnet/corefx [email protected]
Cc : Jeffrey Michelson [email protected] ; Mentionnez [email protected]
Objet : Re : [dotnet/corefx] Port Workflow Foundation vers .NET Core (#2394)

La recherche d'un. Version de base nette

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5uewLNgaJpZM4FaQMY .

Dommage

Alors, qu'est-ce que Microsoft propose pour ifttt ou workflow dans un écosystème non Azure. Quand ils veulent activer des choses comme ml hors d'Azure, pourquoi pas les workflows

Découvrez le travail de Dan Gerlag.

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

De : VenkateshSrini [email protected]
Envoyé : mercredi 26 septembre 2018 08:34
À : dotnet/corefx [email protected]
Cc : Jeffrey Michelson [email protected] ; Mentionnez [email protected]
Objet : Re : [dotnet/corefx] Port Workflow Foundation vers .NET Core (#2394)

Alors, qu'est-ce que Microsoft propose pour ifttt ou workflow dans un écosystème non Azure. Quand ils veulent activer des choses comme ml hors d'Azure, pourquoi pas les workflows

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY .

Il y a CoreWF qui est un portage de Workflow Foundation vers .net core. Ce port progresse. Nous recherchons des personnes pour nous aider.

La prochaine étape majeure consiste à compiler les flux de travail chargés avec Roslyn afin que nous puissions utiliser du code dans les paramètres de flux de travail, cela est nécessaire pour les flux de travail définis en XAML. Si vous définissez des flux de travail dans le noyau Imperative, vous pouvez utiliser CoreWF maintenant.

Merci pour votre travail @ewinnington et @dmetzgar ! La prise en charge de XAML via Portable.XAML dans CoreWF est un gros problème pour cet effort. @dmetzgar Prévoyez-vous de publier bientôt une nouvelle version de NuGet ?

Salut tout le monde,

Est-ce que toute la production est prête. Nous préparons la définition du flux de travail à effectuer à partir d'une interface utilisateur externe. Mais le moteur devrait pouvoir charger la définition et travailler à partir de là. Plus d'un genre iffft

@VenkateshSrini , je ne pense pas qu'il soit nécessaire que Microsoft fournisse un cadre de workflow multiplateforme. À l'époque du .NET Framework, Microsoft fournissait tout, ce qui se faisait au détriment de l'ensemble de la communauté. J'aimerais voir davantage de bibliothèques open source .NET adoptées par les organisations et rendues "prêtes pour la production".

@watertree , j'attends une nouvelle version de Portable.Xaml. Un correctif critique est nécessaire pour la prise en charge de CoreWF XAML.

Quelle est l'alternative pour les longs workflows pour l'instant (avec persistance) ? Uniquement les payants ?

@freerider7777

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

Nous l'utilisons dans notre entreprise avec de très bons résultats.

Pour ceux qui suivent encore, le projet CoreWf vient de franchir une étape importante avec l'intégration de Roslyn pour permettre l'exécution de workflows XAML chargés dynamiquement. Si vous avez toujours besoin de Workflow Foundation sur dotnet core, consultez-le.

Salut ,
Cela signifie-t-il que je peux prendre le flux de travail XAML existant et nous le faire tel qu'il est ? Avons-nous une limite

Avons-nous une limite

Le magasin d'instance n'a pas encore été porté, le concepteur n'est pas sur le noyau et le service WCF n'est pas disponible car le serveur WCF n'est pas encore sur le noyau.

Veuillez créer un problème sur le référentiel CoreWf et répertorier les exigences que vous avez. Nous pouvons continuer la conversation là-bas.

Le nuget actuel pour corewf est obsolète et n'inclut pas l'exécution Xaml basée sur Roslyn qui vient d'être fusionnée. Nous sommes toujours à la recherche de commentaires pour voir ce qui fonctionne et ce qui ne fonctionne pas.

Est-ce à dire que cela n'arrivera jamais ?

Ca ne va pas arriver. Cela n'allait jamais arriver - - sans offenser ceux qui ont fait de leur mieux. Découvrez le projet de Dan Gerlag (https://github.com/danielgerlag/workflow-core) ou accrochez-vous et montez à bord du train Azure LogicApps.

Bonjour, c'est l'appel d'octobre 2020. Des nouvelles/mises à jour/publications sur Workflow Foundation sur .NET Core ?

ou devrions-nous tous déménager à Elsa? https://elsa-workflows.github.io/elsa-core/

@wstaelens Je pense que la réponse de MS était assez claire : WF ne sera pas officiellement porté sur .Net Core. L'alternative suggérée est CoreWF .