Runtime: ワークフローファウンデーションを.NETCoreに移植する

cc： @ terrajobst 、 @ joshfree 、 @ weshaggard

移植に真剣に取り組む前に、System.Xamlを開く必要があります。

@jakesaysを理解しています。

重要なのは、WFのワークフロー定義をXAMLではなくC＃クラスで作成できることであり（現時点では）、多くの人はそのワークフロー定義をXAML表現でさえ使用していません。 後でSystem.Xamlを開くと、ビジュアルデザイナーとXAML定義を統合することもできます。 また、WFの使用/実装に厳密に従うワークフローエンジンに取り組んでいますが、ワークフロー定義のベースストレージとしてXAMLを使用する代わりに、ストアのJsonに基づいており、新しいワークフローデザイナーに多くの機会を提供します。プラットフォーム（VSまたはWPF / WForms用のホストされたデザイナーコンポーネントだけでなく）には、読み取り/書き込みの高速化、スキーマの単純化、読み込み/コンパイルの高速化、ランタイム操作などのいくつかの利点があります。 実行時間が軽量であるなどの理由で、クライアントワークフローを強化したり、Windows Phone / StoreアプリでのアプリケーションUIフローをガイドしたりするためにも使用できます。

WFは.Netプラットフォーム上で非常に強力なコンポーネントだと思いますが、今日のテクノロジでは、XAMLは依然としてその「リミッター」ですが、MSの戦略決定のために、そのままにしてCoreCLRに移植できます。

ありがとう

@zhenlanはWFに関する現在の考え方に向けて話すことができます

@galvesribeiro多くの人がxamlを使用しないかもしれませんが、多くの人がxamlを使用しており、実際にWFのコア部分と見なされています。 xamlを広く使用しているので、xamlサポートのないWFを使用する価値はほとんどありません。

引き続きMicrosoftにSystem.Xamlを開くよう働きかけたいと思います。

そして、JSONを代わりに使用することは、少なくとも魅力的ではありません。

@galvesribeiro @jakesays WFの顧客が.NETCoreバージョンのWFにどれだけ興味を持っているかを知りたいので、コミュニティからのフィードバックを聞くのは素晴らしいことです。 十分な需要があれば、前進するのに役立ちます。

私たちは、実現可能性、依存関係、機能の優先順位などを評価する初期段階にあります。したがって、どのシナリオが頭に浮かぶのか、なぜ.NET Core上のWF（完全な.NETのWFと比較して）になるのかを知ることは非常に役立ちます。あなたにとって便利であり、あなたが最初に見たいWF機能は何ですか。

@galvesribeiroコードでワークフローを構築し、それらの定義をJSONとして保存するシナリオでは、式に何を使用しますか（計画していますか？）。 VB式、C＃式を使用していますか、それとも式を処理するためにCodeActivityに基づく独自の式アクティビティがありますか？

入力ありがとうございます。

@jakesaysは、XAMLを使用しても問題ありません。 私はパフォーマンスだけを気にします...

@zhenlanここブラジルの一部の銀行と海外の一部の銀行では、1日に数十億のクレジット/デビットカード取引を処理する電子決済スイッチがあります。 私たちは完全にオンプレミスであり、テクノロジーを完全にクラウドに更新し、Azureでサービスとして提供しています。 お客様向けのマルチテナント支払い処理プラットフォームとして、ここでAzureに必要なすべてのものを調査するために、エンタープライズ契約を取得しました。

NanoServer forとCoreCLRの使用法を調査しているため、サービスの実行に費やされるフットプリント、攻撃対象領域、およびメンテナンスを削減できます。coreCLRには（少なくとも）System.Activitiesがまだ移植されていないことがわかりました。 つまり、WorkflowFoundationはありません。

当社のコア処理エンジンは、トップWF上に構築されたビジネスエンジンであり、当社のビジネスに焦点を当てた40以上のカスタムアクティビティが含まれています。 このエンジンは、トランザクションの承認を得るために、トランザクションプロセス/ルールをリアルタイムで処理します。 需要に応じて拡張する必要があり、クラウドでのWFの現在の実装でそれを実行します。たとえば、実行可能ではありません。

.net full（サーバープロファイル）に保持するのではなく、.netコアに移植すると、クライアントワークフローを実行する可能性が広がります。これは、私たちのビジネスでは本当に見逃していることです。 これらのクライアントワークフローにより、スマートフォン、ウェアラブル、IoTなどの小型デバイスや決済端末デバイスが実際の反復コードを記述せずにいくつかの決定を下せるように、クライアントとビジネスロジックを宣言的に開発できます。

WF for .net Coreでの取り組みは見当たらず、何年も変わらず、XAMLに依存しているため、WFとまったく同じように動作する独自のワークフローエンジンを開始することにしました。 同じアクティビティモデル、同じコードスタイルなどですが、はるかに軽量で、定義ストアとしてJsonに基づいています。 これにより、計算能力の低いデバイスがXAML / XMLを処理するオーバーヘッドなしでワークフローを処理できるため、WF用に作成されたコードのほとんどはXAMLベースのワークフローではなくJson定義に多くの変更を加えることなく機能します。 また、XAMLから離れることで、新しいワークフローデザイナーの可能性が開かれます... Visual StudioやWPFアプリケーションにとらわれずに、VSデザイナーを再ホストします。

私が提案しようとしているのは、それらのオプションの1つです。

1. WF（XAMLを使用）をそのまま.Netコアに移植します。 今日のWFは.Netのサーバープロファイルに依存しているため、このオプションにはさらに時間がかかります。これにより、.Netコアで動作させるために、WFの分離に多くの時間を費やすことになります。
2. ポートWFはそれを.Netコアに書き換えます。 このようにして、コアコンセプトを取得し、サーバー、クライアント、IoTなど、現在WFに実装されている設計原則と機能を維持しながら実行できるより軽量なエンジンの設計に集中できます。 このようにして、XAMLから（たとえば）Jsonベースのワークフロー定義に移行するのに非常に少ない労力と摩擦のないプロセスを実現します。 現在のすべてのアクティビティを新しいモデルに移植する必要があります。

チームを結成したり、新製品に取り組んだりすることを求めているのではありません。 コミュニティは、ASP.NetおよびEntityFrameworkの場合と同じようにそれを行うことができます。 コアに埋め込まれていない、外部の補助フレームワークにします。

ありがとう

@jimcarley式は、現在XAMLで使用されているのと同じ方法でコンパイルされます。 ワークフローの1つに、これがあります（VBValueの場合もありますが、サンプルを取得しただけです）。
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

今日のXAMLの式は、ほとんどがブール値を返すか、変数に値を割り当てるため、XAMLで今日保存されるのと同じ方法で保存されますが、Jsonでは、同じアイデアに従ってコンパイルできます。今日。

Azure Resource Manager（ARM）を見ると、彼らはすでにそれを行っています！ これらには、依存関係とフローを持つJsonテンプレートとして作成されたリソースのデプロイがあり、変数は式として呼び出すことができます。 これをみて：

"変数"：{
"場所"： "[resourceGroup（）。location]"、
"usernameAndPassword"： "[concat（ 'parameters（' username '）、'： '、parameters（' password '））]"、
"authorizationHeader"： "[concat（ 'Basic'、base64（variables（ 'usernameAndPassword'）））]"
}

わかりました、彼らはJavaScript関数を使用していますが、原則は同じです。 テンプレートの上に$ schema変数があり、ドキュメント構造、アクティビティとして作成できる展開プロセスの手順をガイドします。 設計はWFと非常に似ていますが、このDSLはリソースグループの展開に重点を置いています。 より一般的にして、現在のWF実装と同じようにアクティビティを使用できます。

試してみる価値があると判断した場合は、「新しいWF」のアーキテクチャをガイドする別の問題に関するドキュメントの作成を開始できます。 それがとてもクレイジーに聞こえて、あなたの計画から私に知らせてくれたとしても、私たちはまだ.netコアをサポートするためにそれを開発し、後で人々のためのナゲットとしてリリースします。 私はこの素晴らしいフレームワークを現在の（今後の）テクノロジーで最新のものにしようとしています。 これは本当に私たちのビジネスニーズです。 私たちはWFに大きく依存していますが、高速化せず、coreCLRでサポートされていない場合は、この新しいフレームワークの準備を開始する必要があります。これにより、NanoServer + coreCLRがRTMの場合に移行できます。

ご不明な点がございましたら、お気軽にお問い合わせください。

ありがとう

PS：チャットが必要な場合は、毎日gitterチャンネルを利用しています。

@galvesribeiroしたがって、JSONに格納されているワークフロー定義からActivityオブジェクトを作成した後、TextExpressionCompilerを使用して式をコンパイルしています。 右？

@jimcarleyまだ式コンパイラが機能していません。 TextExpressionCompilerと同じ原則を使用して設計していますが、そうです、まったく同じ概念のように見えます。 現在の実装は、まだSystem.XAMLに関連付けられているように見えます。 開いていないため、TextExpressionCompilerと同じように（内部的に）機能するかどうかは確認できませんが、アクティビティが読み込まれた後、式を評価/コンパイルし（まだキャッシュにない場合）、Expressionオブジェクトを公開する必要がありますアクティビティの消費者によって評価されます（必要な場合）。

昨年、セルフホストのWFデザイナーでC＃式のサポートを有効にするために、式側でいくつかの作業を行いました。 それはnrefactoryとroslynのビットに基づいていました。 興味があれば掘り下げることができます。

@galvesribeiroは、jsonのアプローチについて詳しく考えた後、最終的には、新しい開発にはまったく関係ないと思います。 MSがxamlサポートを開かない場合、これは機能する可能性があります。

@zhenlan WFを移植するチームを形成するために、必ずしもMSを探しているわけではないという点で@galvesribeiroに同意します。 これは間違いなく、コミュニティがあなたのチームなどからの指導でできることです。

@jakesays coreclr用にWFを再度作成する場合、ストレージは実際には問題ではないことに同意します。

重要なのは、両方の（逆）シリアル化パフォーマンスを比較する多くのテストがWebで行われているのに、なぜJsonの代わりにXMLを使用し続けるのか、そしてjsonはそれよりもはるかに高速で、消費するリソースが少ないということです（たとえば、NewtonsoftのJson.Netと通常のXMLシリアライザー）WFが小さなフットプリントのクライアントデバイス（任意のIoT）で実行される場合、各メモリバイトが重要になります。

また、jsonを使用すると、新しいWebベースのWFデザイナーをすぐに入手するのがはるかに簡単になります。 式のコンパイルと実行は、実装するのが難しくありません。 これは、式オブジェクトを構築するための文字列の大まかなパーサーです。 難しい部分（imho）は、WFの設計中に使用されるタイプのVSでインテリセンスを取得することですが、Roselynと言語サービスがそれを支援し、VSにはそのためのインフラストラクチャがあると確信しています。

@galvesribeiroは、JSONベースのワークフロー定義とシリアル化を使用して独自のワークフローエンジンをすでに構築しているとおっしゃっています。 WFがCoreに移植された場合、実際に使用しますか？

@dmetzgarは、フレームワークにほとんど依存せずに、よりクリーンなWFでより良い結果を達成できるという概念実証として開発とテストを開始しました。これは、coreclrで動作させるのに適しています。 準備ができていません。

XAMLに基づいているがcoreclrに移植されていて、たとえばEntityFrameworkとASP.Netのcoreclrバージョンと同じ概念に従っている場合でも、独自のエンジンを構築してWFを使い続ける必要はありません（サーバーライブラリとどこでも実行）。

重要なのは、それでもXAMLとサーバープロファイルに依存する場合は、速度が低下し続け（必要なリソースが多すぎる）、設計者の選択に制限されるなどです。

私の提案は、Jsonを使用してcoreclrに移植し、現在の多くの依存関係を削除して、ユーザーがIoTARMデバイスでASP.NetvNextを実行できるのと同じ方法で好きな場所で実行できるようにすることです（ARMサポートとしてすぐに）完了しました！）依存関係や高いリソース消費について心配する必要はありません。

今日のすべてのワークフローは現在のバージョンで作成されており、一部は純粋なコードで記述され、一部はXAMLですが、どちらの場合も依存関係があります。

IMHOは、それをそのままcoreclrに移植しますが、実行時と設計時の両方でXAML / XML解析/レンダリング用の非常に新しい軽量エンジンが付属していない限り、それほど多くのメリットはありません。 ただし、そのまま移植することにした場合は、XAMLワークフローが0日目から機能するようになるため（私は願っています）、実用的なメリットがないことがわかっていても、とにかく使用し続けます...

繰り返しになりますが、私（おそらく@jakesaysと他のWFユーザー）は、皆さんが決定するかどうかに関係なく、両方の方法（XAMLまたはJSON）でこのポートを支援できます。 このポートを機能させるためにコピー＆ペースト＆フィックスするだけでなく、coreclrと同じ考え方で使用している人々に本当にメリットがあり、問題なくどこでも実行できることを確認したいと思います。

ありがとう

@galvesribeiroXAMLがWFに緊密に統合されていることに同意します。 ワークフローに関するDharmaの元の本に戻ると、Visioからワークフローを構築したサンプルがありました。 少なくともコアへの移植では、ランタイムがXAMLから分離されるようにそれを切り分けることができます。 これにより、XAMLチームのコアへの移植の有無にかかわらず続行でき、後でXAMLワークフローサポートを個別のGitHubプロジェクト/ NuGetパッケージとしていつでも追加できます。 ワークフローを任意の形式で定義および永続化できるようにするために、私は間違いなくすべてです。 おかげで、このフィードバックは役に立ちます。

@dmetzgarいつかXAMLがコアに移植されることは間違いありません.... netコアがWindowsPhoneまたは任意のWindows10モバイルデバイスで実行される場合、それはいつか発生し、私たちが構築できることに完全に同意します新しいコアを追加し、後でワークフローの定義と状態の両方の永続性を追加します。

では、移植を開始するために何をする必要がありますか？ （私たちはすでに貢献者契約に署名しており、MSなどとの会社として他のNDAを持っています）

ありがとう

@galvesribeiro熱意に感謝します！ GitHubリポジトリを開いてハッキングを開始するのと同じくらい魅力的ですが、いくつかの手順が必要です。 また、切り分けなければならないのはSystem.Xamlだけではありません。 System.TransactionsやWCFとのいくつかの共有コンポーネントなど、WFには他にも深く根付いた依存関係があります。 これらのそれぞれを調査しています。

わかりました。 さて、私はあなたたちをプッシュしたくありません、私はただ時間について心配しています。 私たちは今、自分たちで構築を進めるか、ここのコミュニティに参加してWFをcoreCLRに移植し、製品のタイムラインを満たすことができるようにすることを決定しました。

@dmetzgar現在オープンソースにできるパーツをhttps://github.com/Microsoft/referencesourceに公開することを検討しましたか？ これは、実際に機能する本格的なオープンソースプロジェクトを作成するよりもはるかに簡単だと思います。

そうすれば、適切なバージョンで時間をかけることができ、その間に他の人が独自の部分的/カスタムバージョンを作成することができます。

完全な.NETの@svickWFコンポーネントは、しばらく前にgithubリファレンスhttps：//github.com/Microsoft/referencesource/tree/master/System.Activitiesを見つけることができ

@zhenlanはい、問題は、一部の依存関係が「解決可能」ではないことです...公開されていないSystem.Xamlに依存しているため、一部のクラスの動作が正しくわかりません...

私たちはいつでも自分の終わりまでに理解することができますが、それは私たちが同じように進んでいるかどうか確信が持てないことを意味します。

@dmetzgar System.Transactionは（まだ？）開いていないものですが、（今のところ）対処できると思います。 WCFに関しては、依存関係ツリーにはアクティビティとワークフローサービスホストのみが表示されます。 コア（IIRC）の何もWCFに依存していません...

@ galvesribeiroSystem.Transactionsの状況はそれよりも複雑です。 これはWFランタイム全体に散らばっており、永続的なインスタンス化に大きく依存しています。これは、基本クラスが永続化するためのものです。 WCFとWFは.Net4.0の時間枠で同じチームに統合されたため、System.ServiceModel.InternalsのようなものがWCFとWFの両方で使用されます。 .Net Coreには多くの重要な機能が移植されていますが、不足しているものはたくさんあります。 欠落している部分を回避するには、設計の変更または機能の書き直しが必要になる場合があります。

これらの問題はどれも克服できないものではありません。私は努力を簡単にしたくありません。 これは、法的な承認の取得、環境の構築、インフラストラクチャのテストなど、コードとその周辺のすべてに当てはまります。私たちは間違いなくコミュニティに支援を求めており、それに向けて取り組んでいます。 独自のポートを作成するか、「公式」ポートを待つかは、時間枠によって異なります。 Nanoサーバーでワークフローを実行することは私たちの最大のシナリオの1つであり、私はそれについてあなたの助けを得たいと思います。

@dmetzgar私が理解したのですが、私があなたの側にいたときに質問をPRまたは法務に転送する必要がある場合は、常に多少の遅延がありました:)

まあ、少なくとも私たちが何らかの時間枠の概念を持っているなら、私たちは自分自身を準備してそれを待つことができます。 私は、「間違った場所」に何かを実装することや、より良いことをするために力を合わせることができる場所ですでにいくつかの努力が費やされているときに、そのアイデアを嫌います。

私たちにできることがあるかどうか、何かニュースがあれば教えてください。デザイン/ポートに関する提案が必要な場合は、私に連絡してください。

ありがとう

時間枠が明確になったら、このスレッドを更新します。 人々が興味を持っている他のシナリオを聞いてうれしいです。Nano上のWFが現在の主要なシナリオですが、他の人が何をしているのかを知っておくとよいでしょう。

こんにちはみんな、XAMLとJSONの他に、アクティビティを構成するクールな方法があります：メタプログラミング。 私の実験プロジェクトを見てください：Metah.W：ワークフローメタプログラミング言語（https://github.com/knat/Metah）。

@jakesaysセルフホストWFでC＃式のサポートを有効にする方法についてのガイダンスを提供できますか。

Xamlを保管してください。 ：）JSONシリアル化されたオブジェクトも興味深いでしょう。しかし、フレームワークで何らかの形で構成されているプロバイダーを見て、優先フォーマットを選択したいと思います。

@dmetzgar （および他のMSFTの人々）この主題に関するニュースはありますか？
ありがとう

私たちはこれに取り組んでおり、多くの進歩を遂げてきました。 XAMLは現在Coreで使用できないため、ランタイムに重点を置いています。 私たちは他のシリアライザーへの開放を検討しています。 そのため、JSONまたはXAMLのどちらかを選択するのではなく、独自のシリアライザーを持参できるようにすることをお勧めします。 承認を受けるには、さらに多くのコンプライアンスと法的な事柄があります。 多くの顧客がこのポートを推進していないため、優先度は低くなっています。

@dmetzgar甘い！ これに貢献できれば幸いですが、これがコアプロジェクトになると、Webワークフローデザイナーなどになります。定義形式のためにxamlが存在する必要はほとんどないようです...聞いて興奮していますこの作品について！

こんにちはみんな、メリークリスマスと新年あけましておめでとうございます！

それで、私たちはそれを助けることができるように、そのポートまたは少なくとも現在の作業のOSSリリースの更新がありますか？

ありがとう

@galvesribeiroできる限り状況を説明しようと思います。 WFを.NETCoreに移植したいという私の熱意の中で、私はこのすべてのビジネス面を考慮に入れることができませんでした。 WPF / XAMLは.NETCoreに移植されておらず、これはWFのかなりの部分を表しています。 XAMLはランタイムに不可欠ではありませんが、ほとんどのお客様がワークフローを構築する方法です。 これにより、コア上のWFが役立つと思われる対象者が制限されます。 懸念の1つは、コアでWFをリリースし、コミュニティの関与があまりないことです。 これにより、サポートコストが増加し、ほとんどのWFのお客様の状況は改善されません。 LinuxマシンでWFが実行されるのを見るのはクールですが、誰かが実際にそれを使用することを証明するのは難しいです。

私はOmniXAMLを知っており、MITライセンスに変更するように作者を説得することができました。 したがって、ある程度の投資を行うことで、XAMLを機能させることができる可能性があります。 しかし、これが既存のWFの顧客にどのように役立つかについてはまだ疑問があります。 ある日、SharePointやDynamicsのような大口顧客がやって来て、Nanoに移行すると言った場合、説得力のあるケースがあります。 ただし、.NET Frameworkチームが、Nanoで完全なフレームワークを実行できるパッケージを作成することを決定した場合、それはすべて議論の余地があります。

コミュニティの関心が十分にあり、プロジェクトを支持してくれる人がいれば、そのようにすることができます。 Open LiveWriterのようなものです。 トリッキーな部分は、私のチームがこれに可能な限り貢献する一方で、その種のプロジェクトにはMicrosoftのサポートが付属しないということです。 ほとんどのWFのお客様は、主にMicrosoftがWFをサポートしているためにWFを使用していると思います。

.NETCoreと完全な.NETFrameworkは2つの異なる製品であることを強調することが重要だと思います。 .NETFrameworkは決して死にかけているわけではありません。 今後もサポートや機能の追加などを行っていきますので、WFを.NETCoreに移植して存続させる必要はありません。 WF onCoreは基本的に新製品です。 確かなビジネスの正当化を思い付くのは難しいです。 それはタイミングの問題でさえあるかもしれません。 より多くの企業がNanoサーバーを採用するにつれて、より強力なケースが存在する可能性があります。

@dmetzgar Portable.Xamlはどうですか、代替手段になる可能性がありますか？ https://github.com/cwensley/Portable.Xamlこれは、Etoの素晴らしいEto.Formsプロジェクトの作成者が使用するために抽出されました。 これはMITライセンスであり、（monoプロジェクトで派生したクラスライブラリも同様です）。

@dmetzgar 、

できる限り状況を説明しようと思います。 WFを.NETCoreに移植したいという私の熱意の中で、私はこのすべてのビジネス面を考慮に入れることができませんでした。 WPF / XAMLは.NETCoreに移植されておらず、これはWFのかなりの部分を表しています。 XAMLはランタイムに不可欠ではありませんが、ほとんどのお客様がワークフローを構築する方法です。 これにより、コア上のWFが役立つと思われる対象者が制限されます。 懸念の1つは、コアでWFをリリースし、コミュニティの関与があまりないことです。 これにより、サポートコストが増加し、ほとんどのWFのお客様の状況は改善されません。 LinuxマシンでWFが実行されるのを見るのはクールですが、誰かが実際にそれを使用することを証明するのは難しいです。

WFの現在のユーザーの最大の動機は、LinuxではなくNanoサーバーとマイクロサービスだと思います。 Linuxはより多くのユーザーを追加しますが、本当の動機ではありません。

しかし、これが既存のWFの顧客にどのように役立つかについてはまだ疑問があります。

私たちはクラウドの時代にいます。 「クラウドファースト、モバイルファースト...」ということを忘れないでください。成長しているビッグテックの1つは、コンテナー、マイクロサービス、そしてMSからのNanoServerの大きなオファーです。

ある日、SharePointやDynamicsのような大口顧客がやって来て、Nanoに移行すると言った場合、説得力のあるケースがあります。

地球上で最大のSharepointまたはDynamicsの展開があっても、クラウドテクノロジーで作成されたものと同じ数のユーザーに到達することはなく、同じレベルの収益でさえあります。

ただし、.NET Frameworkチームが、Nanoで完全なフレームワークを実行できるパッケージを作成することを決定した場合、それはすべて議論の余地があります。

今日のDNX（RC1まで）は、coreCLRだけで構成されていません。 完全なフレームワーク（dnx451）も備えているため、現在DNXでWFを使用できますが、ここでの問題は問題ではありません。 coreCLR（dnxcore50）について話している

コミュニティの関心が十分にあり、プロジェクトを支持してくれる人がいれば、そのようにすることができます。 Open LiveWriterのようなものです。

Open LiveWriterで作成されたものとは比較しません...これは多かれ少なかれASP.Net、MVC、EntityFrameworkで作成されたものだと思います。 .Netファミリーのコア「製品」であり、今日はオープンソースです。

トリッキーな部分は、私のチームがこれに可能な限り貢献する一方で、その種のプロジェクトにはMicrosoftのサポートが付属しないということです。 ほとんどのWFのお客様は、主にMicrosoftがWFをサポートしているためにWFを使用していると思います。

実際、WFのお客様はMSサポート契約を使用しています...特にDynamicsとSharepointのお客様はそれを使用していますが、この世界以外にもサポートが必要なアプリケーションがたくさんあります。 サポートのために人々がそれを使用するだけであり、OSSがサポートされていないと言うことは、CoreCLR、EF、ASP.NetがMSからのサポートを受けないこととほぼ同じです。 これらのプロジェクトは現在OSSですが、MSチームによって厳重に監視および管理されています。

たとえば、私はMSOrleansプロジェクトのユーザーとして始めました。 ほぼ7年間、すべてのHaloクラウドサービスに電力を供給します。 Skype、Outlook、および他の多くのMSパブリック/クラウドサービスは、何らかの形でそれを利用しています。 数年前、MS ResearchからOSSされ、現在は343 Studios、MSRの一部の人々、およびMS内の他のグループの一部の人々によって維持されていますが、ほとんどはコミュニティによって維持されています。 今日、私は自分自身がそのプロジェクトに積極的に貢献していると考えており、他のMSおよび非MSの人々と一緒に新しいユーザーをサポートしています。 OrleansのGHチームには、元（私のように）でMS以外の従業員もいます。 これは、サポートがないことを意味しますか？ ええと、私はOrleansを購入しなかったので、MS for Orleansとの契約の中で法的にサポートを求めていますが、.Net Frameworkまたはその他の関連製品をターゲットにすることでそれを行うことができます。そのため、あなたの声明には同意しません。

確かなビジネスの正当化を思い付くのは難しいです。
SharepointとDynamicsのお客様のみをお探しの場合は、同意します。

ええと、私たちは世界中の他の多くの企業と同様に、マイクロソフトとの大規模なエンタープライズ契約（EA）を維持しており、これらの契約で最も可変的な製品を使用しています。 私たちの場合、1日あたり数百万の金融（クレジット/デビットカード）トランザクションを処理し、それぞれがOrleans上およびMicrosoftAzure内で実行されているWFの1つのインスタンスを表します。 私はあなたがビジネスの正当化として行動するために何が大きいかわかりません。

XAMLを使用しないcore（System.Activities）をcoreCLRに移植し、XAML、Json、HTML、XMLなどのオンデマンドでデザイナーを作成できると思います。 この依存関係を切り離すことにより、他の可能性が開かれます。

このスレッドの冒頭で述べたように、私たちが今望んでいる最も重い作業は、それをOSS化して、MSFTの誰か（少なくとも最初は）がPRをレビューできるようにすることです。 ここでの常識は、WFを書き直し、coreCLRにコピーして貼り付けるだけではないため、大きな貢献が期待できます。

それが起こらない場合は、この問題を解決できると思います。少なくとも、他のOSSや、最終的にCoreCLRサポートを利用できる有料のワークフローエンジンを探し始める人もいるでしょう。 CoreCLR内に持っていないのは大きな損失だと思います...

WFを.NetCoreに移植する必要がある非常に強力な理由を説明できます。

Microsoftは、開発者をUWPプラットフォームに向けて案内しています。 UWPは、将来のWindowsプラットフォームになります。 Linuxなどにアプリを移植するという風通しの良い妖精のアイデアとは何の関係もありません。Windows10マシンでWFを実行する必要はほとんどなく、UWPはWindows10プラットフォームの未来です。

時々接続されたアプリを作成します。 .NetバックエンドとUWPフロントエンドがあります。 現在、すべてのビジネスロジックは.NetとUWPで共有されています。 ただし、WFでビジネスロジックをソフトコーディングしたいと思います。 これは.Netで正常に機能しますが、WFは現在UWPでサポートされていないため、ユーザーがインターネットに接続していない限り、WFロジックで検証された呼び出しを行うことができないため、WFは使用できなくなります。

UPWにはXamlReaderがあるため、XAMLの解析はそれほど重要ではありません...

@MelbourneDeveloperはすべての理由であなたに同意しますが、UWPと.Net Core（少なくとも現在）は同じモニカの下にないことに注意してください。つまり、同じ低レベルAPIを共有し、同じAPIサーフェス（および。 Net CoreはOSSですが、UWPはそうではありません）、それらは同じものではなく、互換性がありません。 つまり、.NetCoreアセンブリをUWPアセンブリに追加することはできません。 それらの違い（IMHO）は最終的には取り除かれますが、今のところ、それらはまだ存在しています...

はい。 了解した。 将来的には、これら2つのことが一緒になるというのが実際の前提でした。 そうでなければ、神は私たちを助けてくださいます！

また、 @ MelbourneDeveloper UWPのXamlは、.NETのXamlとはまったく異なる、ダムダウンバージョンです。 WindowsDevのUserVoiceには、Xamlシステムを改善するための投票が寄せられています（すべてのUWPと同様に、無視され続けています。そもそもUserVoiceがあるのも不思議ではありません）。
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

うまくいけば、彼らは正しいことをし、提案されているように@cwensleyのMonoXamlポートおよび/またはOmniXamlの後ろに集結します。 現状のUWPのXamlシステムは本当に冗談であり、その採用率が非常にひどい理由の一部です。

そのようなメモに沿って、MSFTiesが検討するビジネスユースケースがあります：NodeJS。 NodeJSは真にクロスプラットフォームであり、真にユビキタスであり、MSFT techが現時点（または予見可能な将来）では主張できないものであるため、この問題について私たち全員が集合的な問題を解決する時間が長ければ長いほど、NodeJSは市場でより多くの価値を生み出します。 NodeJSは、サーバーとクライアント（ALL OF THEM）で動作し、2つの間でコードを再利用できるようにします。 1つのコードベースは、ネイティブ（Cordova経由）およびWeb（標準HTML5ブラウザー経由）のシナリオで機能します。これは、MSFTベースのソリューションで行うよりもはるかに安価です。

NodeJSでシステムをやり直し、MSFTを完全に廃止することは、機能不全のチームが市場の経済的現実に追いつくのを待つよりも、口に合う（そして明らかに安価になる）ようになるでしょう。

また、MSFTがクライアントプラットフォームとしてUWPを信頼しているように見えると述べられているので、これについても言及しますが、NodeJSが提供する市場の一部に到達しています。 そして、私が分数と言うとき、それはそれを誇張しているかもしれません。 私たちは、nodejsベースのアプリケーションが到達できる200m（Windows 10の最後の既知のインストール数）と約30億（BILLION）のデバイスについて話しています。

ここで誤解しないでください。MSFTが大好きです。 私は15年以上にわたってそのテクノロジーに投資してきましたが、個人的にはここに完全に投資しています。 しかし、その投資には、誰もがそれを正しく理解し、オープンソースのクロスプラットフォームの素晴らしさの新時代でここで行われた決定と努力を誇りに思うという情熱が伴います。 また、迫り来る市場の脅威をすべての人に知ってもらいたい（そしておそらく私の恐れを検証/確認するためにも）。

最後に、すべてがうまくいけば、Portable.XamlはOmniXamlとは異なるため、クロスプラットフォームXamlの現在の状態に別の大きな問題があります。したがって、ある時点で、コミュニティとして2つを調整する方法を理解する必要があります。コードベース...理想的には。 :)

@ Michael-DSTはすべての点であなたに同意します。 WFで実行するターゲットの1つは、クライアント（特にモバイルおよび組み込み）です。 WFを追加することで、ローカルビジネスルールのクライアントコードを削減したいと考えています。 クライアントによると、私はWindowsデバイス（電話、タブレット、IoT）のようなUWPについて厳密に話しているわけではありません...

BizTalkやSharepointなどのWFに依存する主要な製品があると思いますが、.Net Core（およびそれ以降のUWP）を使用するユーザーは新しいWF / XAML APIに依存できますが、.Netフルバージョンに依存することもできます。 私はそれがコードベースの周りにたくさんの#ifを意味することを知っています、しかしそれは行く方法になるでしょう...

@galvesribeiro検証/サポートに感謝します。 .NETが直面しているこの非常に現実的な（実存的な？）問題を誰も認識していないように見えるので、私は時々上り坂でスケートをしているように感じます。 実際、.NETのリーダーシップは、Webアプリケーション用に.NETをAngularJSとペアリングすることを推奨することで、この問題を悪化させるのに役立っています。基本的に、組織は大胆にNodeJSに切り替える必要があります。 （完全な開示、私はそれを書いた。：P）。

WFはサーバー側の技術であるため、ここにNodeJSについて多くのことを投稿することを躊躇しますが、私（および他の組織）が見始めているように、これはすべての分野に影響を及ぼし、.NETを全面的に脅かします。 現在、NodeJSをソリューションスタックとして使用する方がコスト効率が高く（そして市場に到達するのに効率的）、私たちは（繰り返しになりますが、実際にはそうではありませんが）これが組織の選択した技術に反映されていることを確認しています。

結論：私は自分の不安を_どこかに_置く必要があり、このスレッドが犠牲になっています。 ：P #sorrynotsorry

#if defs ... yuckについては、ここでMvvMCrossマニフェストを引用します。「＃はTwitter用であり、コードではありません。」 ：P

最後に、 @ SuperJMNにタグを付けるのを忘れました。彼はこのスレッド/ディスカッションも（OmniXamlの作成者として）知っているはずだからです。 私は来週かそこらでOmniXaml対Portable.Xamlの問題に個人的に取り組むつもりです。

@ Michael-DSTええ...実際には#ifは一方向です.... Net Coreチームは、実際の（OS固有の）実装がネイティブコードの薄い下位層に抽象化される「ネイティブシム」のアプローチを採用しました。 WFの場合、たとえば.Net Fullのシムであり、.NetCoreのシムである可能性があります...

私はNode.jsとJavaScriptのどちらも好きではありませんが（プログラミング言語ではなく、スクリプト言語であると思う傾向がありますが、それは私自身の意見です）、今日では、それに匹敵するものは何もないことに同意する必要があります。 xplatの観点から。 Microsoft自体は、VSTSのビルドエージェントに使用します（1つのケースを挙げれば、MSには他のケースもあります）。たとえば、任意のプラットフォームで実行されます...

WFは素晴らしい技術だと思いますが、現在のバージョンは.Net Coreを使用してサーバー側のユーザーになることを目的としており、クライアントでも完全に使用できます...

@galvesribeiro ...私はあなたと100％一緒にいます。 EF Core 1.0も同じ方法です...従来はサーバー側のテクノロジーでしたが、現在はクライアント側でも使用できます。 このような方法でWFを利用できるようにしておくと非常に便利です。

また、シムについて聞くのは良いことです。 多くの承認。 :)

最後に、ここでスレッドを（多くの場合）脱線/ハイジャックしたくはありませんが、確かに次の点に注意してください。JavaScript：スクリプト言語として同意しています。 ただし、これは非常に柔軟な「言語」でもあり、他の形式、特にバイトコード（ish）で利用できます。 ご覧のとおり、C ++用のLVVMコンパイラの魔法があります。 .NET開発者コミュニティで成長している/人気のある質問は、.NETに対して同じことを行うことです（公式の容量で.NETをJSにトランスパイルします）。 これにより、現在のMSFT開発者の状況における現在の（主要な）すべての悪が本当に修正されます。

とにかく、通常のスケジュールされたプログラミングに戻ります。 ：P対話と考えをありがとう！

皆さんは私が9年間扱ってきたいくつかのことに触れています。 マイクロソフトのテクノロジを使用する多くの人が理解していないことがあります。 つまり、分散コンピューティングの概念です。 私たちのソフトウェアの最初からの基本的な要件は、それが時々接続されたモードで動作することです。 時が経つにつれ、Microsoftはこのためのツールを提供するためにさまざまな試みを行ってきましたが、包括的なフレームワークはこれまで開発されていません。 ここには同期フレームワークが少しあり、そこにはLINQデータベースが少しありますが、すべてを連携させるための包括的なツールセットはありません。

過去9年間、私たちは時折接続された独自のフレームワークを開発してきました。 現在、.Net、Silverlight、およびUWPで実行されます。 EFやWFなどのMicrosoftフレームワークを活用しようと懸命に努力しましたが、Silverlightなどのクライアントテクノロジプラットフォームでは、これらのテクノロジのサポートは提供されませんでした。 文字通り、UWPと互換性のあるSilverlight用の独自のORMおよび同期フレームワークを構築しました。

そもそもWFの周りに多くの話題があったとき、それはコードなしでビジネスロジックをソフトコーディングする方法を提供したので非常にエキサイティングでした。 しかし、時間が経つにつれて、Silverlightのようなクライアント側のテクノロジへの移植がこれまでにないだろうと考える傾向がますます少なくなりました。 これについて多くの質問をフォーラムに投稿しましたが、応答は常に同じでした。WFはサーバー側のテクノロジですが、なぜSilverlightで使用したいのでしょうか。

ガルベスリベイロが言ったように

「WFは素晴らしい技術だと思いますが、現在のバージョンは.Net Coreを使用してサーバー側のユーザーを対象としており、クライアントでも完全に使用できます...」

と

「WFを実行したいターゲットの1つは、クライアント（特にモバイルおよび組み込み）です。WFを追加することで、ローカルビジネスルールのクライアントコードを削減したいと考えています。クライアントによると、WindowsデバイスのようなUWPについて厳密に話しているわけではありません。 （電話、タブレット、IoT）」

人々が理解しなければならないのは、分散コンピューティングに関しては、クライアントテクノロジーとサーバーテクノロジーの区別がないということです。 Gitの仕組みについて考えてみてください。 Gitのコードは、中央リポジトリを表示している場合でも、ネットワーク上のノードを表示している場合でも同じです。 コードはどこにでも複製されます。 それは私たちのフレームワークでも同じです。 ビジネスロジックはすべてのノードに複製されます。 これは、ユーザーがネットワークに接続していなくても、同じビジネスロジックに従う必要があるためです。 分散コンピューティングでは、各コンピューターは文字通りサーバーです。 文字通り、サーバーと同じコードを実行します。

SilverlightでWFコードを実行できなかったため、WFを活用できませんでした。現在、UWPで実行できません。 EFがUWPに移植されているのを見るのは心強いです。 おそらくこれは、分散コンピューティングが必要であることをマイクロソフトが理解するようになった始まりです。 ただし、Microsoftは、分散コンピューティングに参加し、分散コンピューティングフレームワーク全体の一部としてWFを含める必要があります。 そうすれば、分散コンピューティングフレームワークを削除できるようになり、そのコードを維持する必要がなくなります。

本当に素晴らしい視点と考え@MelbourneDeveloper。 それらを共有していただきありがとうございます。 私はSilverlightの大ファンでもあり、それ以来、Silverlightに注目しています（したがって、結果として得られた投票と、上記のサイト）。 また、 Azure Mobile Servicesについてどう思うか、オフラインストーリーでそれを使用することを検討したかどうかについても興味があります。 私は分散コンピューティングの初心者です（しかし、あなたが言わなければならないことを掘り下げてください）が、来年は本当にそれを取り入れたいと思っています（私はこれに相当する最新のものだと私が信じる多くのマイクロサービスも聞いていますか？） 。

人々が理解しなければならないのは、分散コンピューティングに関しては、クライアントテクノロジーとサーバーテクノロジーの区別がないということです。

本当に良い点です。 この時点では、テクノロジーがホストされている場所がすべてです。 つまり、あなたは私が言う「配布」しようとしている技術のホストによって本当に制限されています（そして私はこれについての専門家ではありません）。 ホストが最も普及している（またはすぐに利用できる）ほど、アプリケーションの分散/アクセスが容易になります。 Annnnnd ....あなたは私がそれでどこに行くのか知っていると思います。 ：P

いずれにせよ、実際には、この議論で私たち全員がここで_何か_について合意を回しているように感じます。それは私にとって歓迎すべき変化/達成です。 ;）

@galvesribeiro

UWPと.NetCore（少なくとも現在）は同じモニカの下にないことに注意してください。つまり、同じ低レベルAPIを共有し、同じAPIサーフェスを持っています（.Net CoreはOSSですが、UWPはそうではありません）。 、それらは同じものではなく、互換性がありません。 つまり、.NetCoreアセンブリをUWPアセンブリに追加することはできません。 それらの違い（IMHO）は最終的には取り除かれますが、今のところ、それらはまだ存在しています...

このPRdotnet / corefx＃5760を見てください。これにより、いくつかのことが明らかになることを願っています。

UWP _is_ .NETCoreの.NET側。 ただし、.NETCoreは複数のランタイムを提供します。 UWPはAOTベースのランタイムを使用するため、JITを必要とする特定の機能（LCGやRefEmitなど）はサポートされていません。 ただし、それらは同じアセンブリと（前進する）同じNuGetパッケージを共有します。 スタックは、UWPおよびASP.NET Coreからのアセンブリ（およびパッケージ）を相互参照できるように特別に設計されています。

もちろん、この上にポータブルクラスライブラリ（PCL）と呼ばれるVSツールがあり、一連のプラットフォームで動作するライブラリの構築を支援します。 PCLターゲティングダイアログで行うことができる厳しい選択があり、その結果、バイナリは.NETCoreと互換性があります。 ただし、VSの移植性はプラットフォームを確認することで決定されるため、PCLがUWPをターゲットにできると言わない限り、UWPアプリからPCLを参照することはできません。 PCLツールを使用すると、実行する必要のあるすべての場所でサポートされていない機能を誤って使用しないようにすることができるため、この動作は設計によるものです。 逆に、PCLを参照できるのは、ターゲットとされているプラ​​ットフォームからのみです。

モニカについて明示的に言及しているので、これについても少し話しましょう。 モニカ（TFM）の設計は、表面積全体を表すことです。 私たちのツールには2つのモニカがあります：

• TargetPlatformMonikers（TPM）
• TargetFrameworkMoniker（TFM）

TFMは、管理対象の受信トレイの表面積の全体を識別するものと考えてください。TPMは、基盤となるOS、つまりOSが提供するAPIセットを表します。

.NET Coreは複数のプラットフォームに移植できるように設計されているため、従来のTFMはあまり意味がありません。 そのため、以前は世代と呼ばれていた、標準プラットフォームと呼ばれる新しい概念があります。

これは役に立ちますか？

ただし、それらは同じアセンブリと（前進する）同じNuGetパッケージを共有します。

ほとんどのアセンブリには、「netcore50」NuGetターゲット（WIndows UWPストアアプリ）と「dnxcore50」NuGetターゲット（ASP.NET v5 / ASP.NET Core 1.0）アプリケーションの両方に同じBINARY実装DLLがあります。

ただし、多くのSystem.Net。*ライブラリパッケージのような一部のNuGetパッケージでは、「netcore50」ターゲットと「dnxcore50」ターゲットの実装が異なります。 たとえば、「netcore50」を含むSystem.Net.Httpライブラリは、その下にあるWinRTWindows.Web.Http実装を使用します。 'dnxcore50'実装は、他のもの（ネイティブWinHTTP）を使用します。

ただし、多くのSystem.Net。*ライブラリパッケージなどの一部のNuGetパッケージでは、「netcore50」ターゲットと「dnxcore50」ターゲットの実装が異なります。

ええ、私はそれについて言及すべきでした。 私の見方では、NuGetパッケージは、プロデューサーがさまざまな実行環境にさまざまな実装を提供できるようにするコンテナーを提供しますが、コンシューマーはそれを知る必要はありません。 その意味で、NuGetパッケージは新しいアセンブリです。

この詳細な説明と参照の問題を共有してくれた@terrajobstと@davidshに感謝しますが、「あるプラットフォームの1つのアセンブリを他のプラットフォームから参照できない」と言ったことの何が問題になっていますか？

私の見方では、NuGetパッケージは、プロデューサーがさまざまな実行環境にさまざまな実装を提供できるようにするコンテナーを提供しますが、コンシューマーはそれを知る必要はありません。 その意味で、NuGetパッケージは新しいアセンブリです。

この概念は実際には新しいものではありません...人々はすでに1つのNugetパッケージを作成しています。これは、他の一連のパッケージ、いわゆる「メタパッケージ」への参照にすぎません。 PCLを多くのプラットフォームで機能させるにはいくつかの方法があります。 多くの人気のあるライブラリ（NewtonsoftのJson.Netなど）で最もよく使用されているのは、パブリックインターフェイス（APIサーフェス）と特定のプラットフォームごとに1つのアセンブリ（APIサーフェスの実際の実装）を持つナゲットがあるおとり商法です。相互に異なる依存関係を持つこともでき、実行時に、そのプラットフォームに適したアセンブリが選択されます。 現在の違いは、単一のコンテナーnugetの「内部」に複数のnugetを配置する代わりに、すべてを同じプラットフォームまたは1つのインターフェイスアセンブリに配置する必要があります。これらは開発で使用され、実行時に特定のnugetに切り替わります。それの！ コンテナであると同時に、それにリンクされているすべてのプラットフォーム固有のnugetのパブリックインターフェイスである1つのnuget。

私たちは同じことを話していると思います、私は最初に自分自身をひどく表現しました：smile：

とにかく、WFに戻りましょう... LinuxやNanoServerで実行するために、単に「クールな理由」ではなく、WFに移植してもらいたいという人がいることは悪名高いと思います。 人々はそれをクライアントでも軽量な方法で使用したいと思っています。

繰り返しになりますが、この移植を実現するのに十分な数のコミュニティの人々がいると思います...

PS：分散コンピューティングに興味のある方（オフラインクライアントの話ではなく実際の方）は、他のプロジェクトOrleansをご覧ください。これは、実際には.Net Core上のWFの優れたユースケースであり、今日の大きなMicrosoftサービスに力を与えています。 SkypeやHalo5のように、私は個人的に、分散方式で数十億のトランザクションを処理する金融トランザクション処理プラットフォームのコアテクノロジーとして使用しています...

@galvesribeiro

「あるプラットフォームの1つのアセンブリを他のプラットフォームから参照できない」と言ったことの何が問題になっていますか？

あなたの発言が間違っているわけではありません。 どちらも正しくないというだけです：smile：通常、私はニッチを好むような人ではありませんが、私を失望させたのはこの部分でした：

つまり、.NetCoreアセンブリをUWPアセンブリに追加することはできません。

UWPと.NETCoreは、.NETFrameworkやSilverlightなどの異なる.NETプラットフォームであるという印象を与えたくありません。 すべてのプラットフォームで動作するアセンブリを作成できるように、.NETCoreを特別に設計しました。 たとえば、 System.Collections.ImmutableとほとんどすべてのRoslynは.NET Coreアセンブリであり、UWPでも正常に機能します。

言い換えると、私たちの目標は、単純なMSILベースのコンポーネントがすべての.NETCoreベースのプラットフォームで文字通り同じバイナリを使用できるプラットフォームを構築することです。 たとえば、ネイティブの依存関係やさまざまな実装が原因でそれが不可能な場合は、 PaulBettsがおとり商法として雄弁に説明したことを正確に実行しています。ポータブル表面積、プラットフォームごとのさまざまな実装、コンテナとしてのNuGet、セレクタ。

.NET Coreの世界では、 Systemライブラリはそれほど特別なものではありません。 誰でも同じ手法を使用して、ほとんどのコンシューマーがコードベースに#ifディレクティブを散らかす必要がないことを確認できます。

私たちは同じことを話していると思います、私は最初に自分自身をひどく表現しました：smile：

私たちは人々を混乱させるのが少し簡単すぎる世界を作ったと思います-それは明らかに私たちを含みます：smile：だから私は.NETCoreがどのように構築されたのかそして私たちがどのような問題を解決しようとしたのかを正確にしようと努力しています。

はい、その通りです。 印象は重要です。

いつかUWPでも.NetCoreを呼び出すと、これが終了することを願っています...したがって、system.xamlが必要です。

関連していると思いますが、 System.Xamlは、それ自体で価値を付加する別個のコンポーネントだと思います。 これを個別に追跡するために、dotnet / corefx＃5766を提出しました。

ありがとうMichael-DST

また、Azureモバイルサービスについてどう思うか知りたいです（https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/）オフラインストーリーでそれを使用することを検討した場合はどうなりますか？

すばらしい質問です。 これは、分散コンピューティング、別名接続されたアプリ、およびそれがAzure Mobile Servicesとどのように結びつくか、およびMicrosoftテクノロジを使用した分散コンピューティングに関する当社の経験についての少しの歴史の教訓を促します。

上記のウェブサイトをまだご覧になっていない方は、ぜひご覧になることをお勧めします。 Azure MobileServicesに関する優れたビデオがあります。

約8年前、元のWindowsPhoneプラットフォーム用のアプリを作成しました。 .Net CompactFrameworkを備えた古い学校のもの。 人々はそれを嘲笑するかもしれませんが、いくつかの重要な点で、このプラットフォームは、時折接続されるテクノロジに関して、現在のUWPプラットフォームよりも高度でした。 ただし、UWPが追いついてきているようです。 そのプラットフォームで時折接続されるアプリを成功させるための鍵は次のとおりです。

1）完全なSQLデータベースの実装（SQL Server CE）
2）SQL Server（バックエンド）とSQL Server CE（モバイルデバイス）間の同期フレームワークの実装。 これはSyncFrameworkバージョン1でした。

このアプリは成功しました。 最上位のSQLCEと、サーバーに展開され、デバイスに展開されたSQLServerの上に配置されたデータレイヤーを作成しました。 それはほとんどメモリを最大にしましたが、それは機能しました。 フィールドワーカーはフィールドでデータキャプチャを実行でき、データは中央データベースに同期されました。

Windows Phone 7がリリースされたとき、重大な問題があったため、私たちは恐怖を感じました。市場に出回っているすべてのデータベースは非SQLデータベースでした。 それらは主にLINQで実装されました。 これはデータレイヤーと互換性がなく、EFはWindows Phone 7には存在しませんでした。そのため、元のソリューションの完全なソリューションを構築できたとしても、Windows Phone7のオフラインフレームワークを構築できませんでした。 WindowsPhoneプラットフォーム。

Silverlightはゲームチェンジャーでした。 ここでも、完全なSQLデータベースに出くわしました。 ただし、Microsoftは、Silverlightまたは問題のインラインデータベースの同期フレームワークを実装していませんでした。 そこで、Microsoftの同期フレームワークをモデルにした独自の同期フレームワークの作成に着手しました。 Microsoft同期フレームワークは、タイムスタンプに基づいています。 これは、同期フレームワークに実装したものです。 繰り返しになりますが、Silverlightで完全な成功を収めました。 フィールドワーカーは、Windowsタブレットをフィールドに持ち出し、データをキャプチャして、中央データベースに同期することができました。 問題は、これが電話では利用できないことでした。 データベースプラットフォームは、Windows Phone7には存在しませんでした。

先に述べたように、WFを使用してビジネスロジックを実装したかったのですが、Silverlightは放棄され、WFをSilverlightに移植する可能性については誰も話しませんでした。

最後に、UWPに到着します。 SQLiteのラッパーはUWP用に作成されており、ラッパーをいくつかハックすることで、SQLiteとのインターフェイスを拡張して、完全なSQLデータベースで再び作業できるようになりました。 つまり、データ層はそれと互換性があります。 データレイヤーと同期レイヤーは、SQL Server、SQLite、および別の名前のないデータベースプラットフォームを使用して、.Net、Silverlight、およびUWPで機能するようになりました。

Michael-DSTのおかげで、純粋なMicrosoftテクノロジで同期が発生するのを目にしたのは今日が初めてです。 基本的に、Azure MobileServicesの同期はMicrosoftSyncFrameworkのブランド変更に過ぎないと言えます。 APIインターフェイスは少し異なりますが、基本は、約8年前に同期を機能させるために使用した元のWindowsPhone同期フレームワークと同じです。 同じ2つのタイムスタンプフィールドを使用してデータの変更を追跡していることがわかります。 これらは、SQL Server2008のコア機能としてSQLServerに導入されました。同期フレームワークは、Microsoft同期フレームワークとほぼ同じように機能します。

それで、マイケルの質問に答えるために、私はこの技術を調査します。 同期フレームワークを置き換えることができるかどうかを確認します。 私はそれを捨てて、他の誰かにそれを維持させたいです。 彼らがSQLiteをサポートすると述べているのを見ると、SQLiteラッパーをハックして完全なSQLデータベースを使い続けることができ、したがってデータレイヤーを使い続けることができるように見えるので、有望に聞こえます。 その場合、5年以上の同期フレームワークコードが直接ビンに入れられることを意味します。

とにかく、要点は、Microsoftは分散コンピューティングが重要であることをもう一度認めているように見えるということです。 重要な場合は、WFをUWPに移植する必要があります。 UWPは未来であり、したがって、マイクロソフトテクノロジを使用した分散コンピューティングの未来でもあります。 分散型テクノロジーの未来にはWFが必要です。

関連していると思いますが、System.Xamlは、それ自体で価値を付加する別個のコンポーネントだと思います。 これを個別に追跡するために、dotnet / corefx＃5766を提出しました。

どうもありがとう@terrajobst！ 私はあなたがオンライン/ツイッターに投稿するすべてに同意しませんが、私はあなたが開発者/コミュニティ間の対話とコミュニケーションを促進する方法の大ファンであり、私は常にそれに同意します。 :)これは、MSFTから何かを得るために1年以上上り坂でスケートをしているように見えるので、個人的には本当に大きな意味があります（もちろん、それはコミットメントではないことを認識していますが、現時点では何か意味があります）。

それで、マイケルの質問に答えるために、私はこの技術を調査します。

素晴らしい@MelbourneDeveloper 、喜んでお手伝いします！ Azureは本当に彼らのグループをしっかりと把握していると思います。 VSO / VSTSに加えて、彼らは実際に開発者の話を聞き、* _ lot * _doneを取得します。 実際、これは、MSFTのすべてのグループに当てはまるようです。UWPグループは、実際にはあまり機能していないようで、独自のテクノロジーを理解していないようです（そして、 「Xaml」）。

現在、いくつかのコアサービスにWFを使用していますが、ワークフローの経験が豊富で、ビジネスロジックがこのように視覚的でわかりやすい形式になっているため、さらに使用を拡大しています。

@MelbourneDeveloperが言ったように

とにかく、要点は、Microsoftは分散コンピューティングが重要であることをもう一度認めているように見えるということです。 重要な場合は、WFをUWPに移植する必要があります。 UWPは未来であり、したがって、マイクロソフトテクノロジを使用した分散コンピューティングの未来でもあります。 分散型テクノロジーの未来にはWFが必要です。

WFは、当時その価値を認識していなかった可能性があるため、多くの.NET開発者から過小評価されてきました（以前は見ていませんでしたが、WFの強力さを理解しているため、今ではWFの大ファンです。です！）しかし、分散コンピューティングの時代では、今まで以上にWFが本当に輝けるようになり、最終的に移植されることを願っています。

このトピックについて意見の相違はほとんどないと思います。

確かに、WFなどの宣言型のビジュアルプログラミングは、コードを書くほど効率的ではないと主張されています。 私も同意する傾向があります。 しかし、構成可能なプラットフォームを完成させるためのツールキットのツールとしてWFを使用することは、確かに良いことです。 顧客* _DO * _は視覚的なワークフローを見たいと思っており、顧客が自分のワークフローを変更できるようにすることは確かに良いことです。

これを成し遂げる時が来ました！

このトピックについて意見の相違はほとんどないと思います。

ハハ@MelbourneDeveloperソフトウェア開発者に会ったことはありますか？ それとも本当に人類？ ; p

個人的には、WFビジュアルデザイナーと既存のツールがXAMLに悪影響を及ぼしていると感じています。これは、MSBuildワークフロー用に生成された過度に冗長なファイルがXamlにこの点で悪い名前を付けているためです。 これは、開発者がXaml（「肥大化したファイル」）と関連付け、「より単純な」JSONファイルと「スクリプト化された」ビルドファイルへのフライトを生み出すのに役立ったものです。 言うまでもなく、最初にXamlファイルを表示するプロジェクトを作成するという、難解で困難で面倒なプロセス全体（プロジェクトで完全に機能させることすらできません）。

実際、WFがどのように機能するかは、ずっと「正しい方法」でした。 その本当の病気はその工具にありました。

そのため、デザイナーツールがもう少し使いやすい場合（そして、ファイルをより整理された/区画化された方法でシリアル化することでより良い仕事をした場合）、これは問題ではありません（または問題は少なくなります）。

私はWFが目指していた道の大ファンですが、それを少し強化し、そのツールに対処して改善する必要があります。 実際、結局のところ、技術はそのサポートツール（設計者やすべて）と同じくらい優れています。 ツール/設計者が優れているほど、アクセス可能/理解しやすい技術が優れているほど、採用も向上します。

私は間違いなく、WFがEFのようになり、どの.NETシナリオでもアクセスできるようになり、これを容易にするためにツールが改善されることを望んでいます。

私の理解では、WFの当初のビジョンの1つは、XAMLだけでなく、ワークフローで複数のファイルタイプをサポートすることでした。 全体的に、あちこちのいくつかの癖を除いて、XAMLで実際に問題が発生したことはありません。 頭を包み込み、必要に応じて手動で編集できるようになるまでには少し時間がかかりました。これは、多くの人にとって参入障壁になると確信しています。 したがって、下位互換性のためにXAMLを維持する必要があると思いますが（少なくとも短期的には）、他のワークフローファイルタイプ（JSONなど）の開発を開始することを本当に望んでいます。 私はその面でいくつかのクールなコミュニティの貢献を見ることができました！ （ホワイトスペースで書かれたワークフローは誰ですか？：smile :)

@ Michael-DST私はあなたに完全に同意します。 最近、私のチームと私はワークフローの好き/嫌い/願いを検討していましたが、改善したいと思っていたほとんどすべてがデザイナーの周りにあり、必ずしもコアWF自体ではありませんでした。 マイクロソフトは、WFに組み込まれているもので素晴らしい仕事をしたと思います。また、いくつかの改善と、新しい命が吹き込まれた伝道を見ることができたと思います。 それは存在する必要のあるツールだと思います。私はWFから多くの価値を得ており、それが長く続くことを望んでいます。

私たちの企業はWFにかなりの投資をしており、現在は私たちのビジネスにとって極めて重要なテクノロジーです。 オープンソースと.NETCoreに対するMIcrosoftの最近の取り組みを考えると、WFの移植はこのテクノロジーの次の最良のステップのように思われます。 これが必要です！

ワークフローは、組織内の開発者として多くのメリットをもたらすツールです。 マイクロソフトがフレームワークを統合しようとすると、コアフレームワークにWFを含めることが私たちの生活を楽にするでしょう。

ハハ@MelbourneDeveloperソフトウェア開発者に会ったことはありますか？ それとも本当に人類？ ; p

ハハ、私はソフトウェア開発者です。 人類は私にとって取るに足らないものです。

マイケル-DST

個人的には、WFビジュアルデザイナーと既存のツールがXAMLに悪影響を及ぼしていると感じています。これは、MSBuildワークフロー用に生成された過度に冗長なファイルがXamlにこの点で悪い名前を付けているためです。 これは、開発者がXaml（「肥大化したファイル」）と関連付け、「より単純な」JSONファイルと「スクリプト化された」ビルドファイルへのフライトを生み出すのに役立ったものです。

あなたはおそらく正しいです。 しかし、個人的には、ここではXamlが強調されすぎていると思います。 WFを試したとき（Silverlightに存在しないために使用できないことに気付く前に）、WPFアプリを作成しました。 そのアプリはWCFサービスに接続し、WFのXamlをデータベースのテーブルに保存しました。 これが、WFのソフトコーディングを実現した方法です。

ただし、Xamlは、WPFWFデザイナーツールを使用して完全に操作されました。 ユーザーはXamlを見たことがありません。 xamlはユーザーとは無関係でした。 Webページの背後にあるHTMLマークアップのように考えてください。 非常に複雑になる可能性がありますが、エンドユーザーがWebページを気に入っている限り、それは実際には問題ではありません。 Xamlをテキストとして直接操作している場合は、とにかく意図した方法でWFを実際に使用していないと思います...

人類は私にとって取るに足らないものです。

良い。 B）

ただし、Xamlは、WPFWFデザイナーツールを使用して完全に操作されました。 ユーザーはXamlを見たことがありません。

正しい。 これはまさにMSBuildの仕組みであり、生成されるファイルの大きさのためにエンドユーザーはMSBuildを嫌います（特に、非常に基本的で線形の単純な「スクリプト」ファイルと比較した場合）。 これは工具/設計者の問題であることに同意します。また、WFを使用すると、工具/設計者を大幅に改善できると思います。

適切な例：ブログ投稿とコードのコピー/貼り付け（または実際には、_workflow_：smile :)のコピー/貼り付け。 WFをオンラインで検索したり、ワークフローコンポーネント（おそらくMSBuildの場合）を配置するために実行するいくつかの手順を示した素敵なブログ投稿に出くわしたことが何度かあります。 さて、これを行うために、私は基本的に一連のステップを複製する必要がありました。 通常、コーディングブログの投稿では、コードは単純なコピー/貼り付けに使用できます。 WFではそうではありません。 ブログ投稿での表示とまったく同じようにマシンで表示されるまで、段階的に実行する必要があります。 これは明らかに非常に面倒でエラーが発生しやすいです（C＃の観点からは、完全に一歩後退したように感じます）。

MSBuildで発生したもう1つの問題は、ファイルのサイズ（バイト単位だけでなく、デザイナー自体）です。複雑なワークフローをナビゲートするのは非常に困難でした。 これは、非常に包括的（かつ直感的）な方法で説明する必要があるもののようです。

最後に、ファイルサイズについてまとめたいと思います。 昔からWordMLやM​​SFTフロントページを知っているかどうかはわかりません。 しかし、それは世界で最も肥大化したHTMLを作成するでしょう。 ユーザーは通常、結果のマークアップに手を入れませんが、それがどれほど「クリーン」であるかを感じるために、マークアップに鼻を入れるのが好きです。 彼らが最初に見るのはディスク上のサイズであり、次にファイルを開いてそれがどのようにフォーマットされているかなどを確認します。

繰り返しになりますが、これらのファイルの作成方法は厳密にツール/設計者の問題であることに同意しますが、開発者は興味を持ち、これも考慮する必要があります。 :)

はい。 すべての良い点。 このような冗長なXamlが作成されないように、デザイナーをクリーンアップする必要があると思います。

WFを.NetCoreに移植するか、UWPに移植するかを決定する権限を実際に持っているのは誰ですか？ どこかでコードを記述し、そのパッチを.Net Coreコードベースリポジトリの管理者に送信する開発者の場合だけですか？ これを取り巻く政治は何ですか？ マイクロソフトの影響を受けた開発者のコ​​アチームはありませんか？ マイクロソフトの従業員ですか？ 私はまだ全体のセットアップを実際に取得していません。 誰を説得する必要がありますか？

実際、 @ MelbourneDeveloperは、このスレッドに参加するだけで、議論を支援しています。 現在私のWFを所有しているMSのチームがありますが、コアでWFをリリースすることは決定していません。 私たちはビジネスケースを作らなければなりません。 ここでの議論は私がそれをするのを助けます。

人々がこのスレッドをサポートするために2016年を始めた方法は実際に印象的です:)

また、 @ terrajobstのhttps://github.com/dotnet/corefx/issues/5766は最近非常に忙しくなりました:)

@dmetzgar OSSするのに十分なケースがあるように、これらのディスカッションからできるだけ多くのフィードバックを取得してください。

dotnet / WFリポジトリが開かれていれば、corefxに追加されれば、人々は間違いなくそれを非常に速く成長させるでしょう。

実際、 @ MelbourneDeveloperはこのスレッドに参加するだけで、議論をするのに役立ちます

それは私を暖かくそしてぼんやりと感じさせます。

参考までにdmetzgar-私たちの経験を文書化し、説得力のある事例を提示して、港湾ビジネスケースの証拠を構築するのに役立てることができてうれしいです。

私は2000年以来、マイクロソフトテクノロジに深く関わっています。このスレッドに関連するすべての主要なテクノロジが開発され、フェードアウトするのを見てきました。 私はマイクロソフトのテクノロジに没頭していますが、それでも客観的な観点から見て、WFは.NetCoreおよびWindowsUWPプラットフォームへのビジネス/政府の賛同を得るのに役立つ重要なテクノロジの1つだと思います。

フローチャートほど顧客を興奮させるものはありません！ 何もない！

また、マイクロソフトのテクノロジは何か大きなものの先端にあると言わなければなりません。

何年もの間、私は優れたテクノロジーが上下するのを見てきました。 テクノロジーが道に迷った主な理由は、デバイスの状況が変化しているためです。 以前の戦略は、デバイスファミリごとにプラットフォームを構築することでした。 このアプローチには本質的に何も問題はありませんでした。 しかし、それはプラットフォーム間でテクノロジーを移植することを意味します。 これは面倒であり、プラットフォームが突然口に合わなくなったためにテクノロジーが途方に暮れることも珍しくありません（咳-Silverlight）。

Microsoftは現在、.NetCoreとUWPに遅れをとっています。 これらの2つのプラットフォームは同一である必要があると思いますが、特定のテクノロジーが作成または維持されると、多くのプラットフォームで機能することを非常に楽観視しています。 Xamarinは私の楽観主義をさらに高めます。

歴史上初めて、非常に広範囲のCPUと動作環境で機能するテクノロジーのコレクションを真っ白に見つめているように思われます。 マイクロソフトがこれを強く推し進めれば、WFはその一部になるでしょう。

それは私を暖かくそしてぼんやりと感じさせます。

：+1：その@MelbourneDeveloperと@dmetzgar。 これは、私が個人的にMSFTから見たいと思う一種の関与と対話であり、その情熱的な基盤からの無視された嘆願や応答のない呼び出しではありません（つまり、平均、つまり、人間）。

ここではランダムですが、NodeJSが必要な唯一のビジネスケース/脅威であるという私のポイントでは、最近偶然出会ったランダムな記事です。

最後に、「。NET CoreがEFに十分であれば、WFにも十分であるはずです」... WFが.NETCoreに移行した場合、EFが機能するようにEFと統合する方法はありますか。どういうわけかそのバックエンドとして？ もしそうなら、それはまさにそこにある説得力のあるケースです。 そうでない場合でも、検討する価値があります（ディスカッション/ダイアログ/ブレーンストーミングなどを参照）。 :)

最後に、「。NET CoreがEFに十分であれば、WFにも十分であるはずです」... WFが.NETCoreに移行した場合、EFが機能するようにEFと統合する方法はありますか。どういうわけかそのバックエンドとして？ もしそうなら、それはまさにそこにある説得力のあるケースです。 そうでない場合でも、検討する価値があります（ディスカッション/ダイアログ/ブレーンストーミングなどを参照）。 :)

それは興味深い考えです。 EFとWFを統合するためのユースケースは何ですか？ 例を挙げていただけますか？ これは永続性のためですか？

例を挙げていただけますか？ これは永続性のためですか？

少なくとも、ワークフローがアプリケーションドメインで機能するバッキングモデルとして使用できます。 せいぜい、ワークフロー自体のストレージメカニズムとして実際に機能する可能性があります（ただし、これはお勧めしません。Xamlの方がはるかに適しています）。

Xamlでワークフローを定義し、EFで定義、変更、保存されたモデルエンティティのデータを使用して、ワークフロー要素のプロパティにバインドできるWPF風のパラダイムをここで確認できます。

確かに、WFでの私の経験はここでは限られています（豊富な経験を持つ人はここでチャイムを鳴らすかもしれません）。 ただし、WPFで機能する場合は、WFで機能する可能性があります。 実際、現在のプロジェクトで使用しているコンソールアプリケーションには、これと同じパラダイム（つまり、WPF風のXamlベースの開発）を使用しています。 確かに、私が提案しているように（まだ）データバインディングを使用していませんが、OmniXaml / Perspexが示しているように、データバインディングは簡単に作成できます。 ：サングラス：

@ Michael-DSTあまりにも多くの統合を避けたいと思います。 WFはスタンドアロンのNuGetパッケージである必要があります。 WFとEFを統合することは、別のプロジェクトである必要があります。 あまりにも多くのものを組み合わせ始めると、オスロになってしまう可能性があります。

@dmetzgarに同意します：+1：

EFはストレージ/永続性プロバイダーです。 これはdiffNuGetパッケージであり、実行時に注入される必要があります。 WFは、一連のインターフェイスのみを提供する必要があり、それだけです。

MicrosoftOrleansのストレージプロバイダーでかなりうまくいきました。

@dmetzgar （および@galvesribeiro）は同意しました。 必要な統合を提案しているのではなく、考えられるユースケース/価値提案を提案しています。 （参照：ブレーンストーミング。：smile :)

EFとWFを統合するためのユースケースは何ですか？ 例を挙げていただけますか？ これは永続性のためですか？

これでチャイムしたい！ 繰り返しますが、これは私の会社の経験に関連しています。 最終的には、時々接続されるアプリのSQLiteなどのインラインデータベースのデータを永続化するためにEFを使用したいと考えています。 最終的に、UWP / .Net Coreでは、EF、SQLite、Azure Mobile Services、およびWFがすべて調和して機能します。 なぜこれを実現したいのかを説明すれば繰り返しますが、EFとWFがうまく連携する理由は説明できます。 ただし、EFには、過去にトラックで私たちを止めていた1つの制限があります。これが、独自のORMを作成しなければならなかったもう1つの理由です。

データアクセスが「BeforeLoad」、「BeforeSave」などのイベントをトリガーするシステムがあります。これらのイベントにフックを残して、特定のレコードタイプが保存されたときに、カスタムビジネスロジックをそこに配置できるようにします。 現在、カスタムビジネスロジックDLLにリンクすることでこれを行っています。 各顧客には、独自のカスタムイベントのセットがあります。 WFへの呼び出しも実装しました。 したがって、たとえば、BeforeSaveイベントでは、必須フィールドを検証するWFを呼び出すことで、そこに検証を加えることができます。 このようにして、検証ロジックは特定の顧客向けにソフトコーディングされました。 長期的には、WFはSilverlightに実装されていなかったため、この目的のために放棄する必要がありましたが、オプションとしてそこにあると便利でした。

とにかく、これはどのアプリにとってもかなり普遍的な要件だと思います。 一般的に言えば、データベースに入るデータを検証する、または一般的なビジネスロジックを実行する、データ層のすぐ上にある層が常に必要になります。 たとえば、特定のタイプのレコードがデータベースに追加されたときに電子メールを送信する一部の顧客向けのビジネスロジックがあります。 これはWFで行うことができます。 EFとWFが調和して機能するようにこのようなものを実装するのは素晴らしいことです。

残念ながら、.NetでもEFを使用してこれを行う方法を見つけることはできませんでした。 私が見つけた問題は、特定のタイプのレコードがいつ保存されようとしているのかをEFが通知しないことでした。 したがって、たとえば、新しい「タスク」オブジェクトを作成し、それをEFを使用してデータベースに永続化する場合、「RecordInserted」のようなEFによって発生するイベントはありません。「これにより、データアクセスへのフックを構築して、カスタムビジネスを挿入できるようになります。したがって、これがEFを使用しなかった理由の1つです。独自のORMの構築には何年もかかったため、残念です。

NodeJSの「ビジネスケース」と言えば、3つの簡単なチャートでNodeJSが.NETをどのように支配しているか

そのGitHubリポジトリを辛抱強く待っています。 WFが.NETCoreに移植されていないことに気付いただけで、製品の実行可能性がほとんど失われました。 ASP.NET Coreに加えられた変更と、.NET Coreのスリム化されたモジュール式のクロスプラットフォーム全体のアイデアが気に入っているので、これは残念ですが、製品全体の基盤であるWFが必要です。

これがWWFなのか、それとも他の十分にサポートされているワークフローエンジンなのかは正直気にしないと思いますが、拡張性の目的で、ある種のワークフローは絶対に巨大になる可能性があります。

+1

動的生成（インポートされた外部ルールに基づく）とワークフローの読み込みをWCFサービスとして使用しました。 .netコアでそのようなモデルを使用できれば素晴らしいでしょう！
ところで-完全な.Netのアセンブリをインポートすることの問題は何ですか？ ほとんどがILコードの場合、なぜ.net Coreで実行されないのですか？

+1

@dmetzgar https://github.com/dmetzgar/corewfを見るのは非常にエキサイティングです！ READMEから、WFチームによる移植があまり牽引されていないことに驚きました。 特に、完全なフレームワークに限定されるPowershellワークフローを備えた最近のPowershellポートを考えると、LinuxとMacは明らかに主要なターゲットではありませんが、NanoサーバーはPowershellにとって非常に重要だと思います。 また、Portable.Xamlなどの他のXaml実装を含むXAMLの代替案を検討していることも記載されています。たとえば、XamlはすでにCoreCLRと互換性のあるプロファイル259をサポートしていますか？

@watertree Portable.Xamlおよびこれまで見てきた.NETCoreをサポートするその他のXAML実装には、すべて欠落している機能があります。 x：Class = ""属性は実装されていません。 WPFには不要ですが、WFには重要です。 XAMLワークフローには通常

PowerShellワークフローには、スクリプトでワークフローを定義するための非常に優れた方法があります。 XAMLまたはC＃で同じことを書くよりもはるかにクリーンです。 ただし、PSWFはそのスクリプトをバックグラウンドでXAMLファイルに変換します。 PSWFがNanoで動作するには、XAMLを使用しないように、既存のパイプラインとWFランタイムを置き換える必要があります。 そして、NanoにPSWFを導入するという顧客からのプレッシャーは本当に十分ではありません。

XAMLの代替案に関して、私はこれについて多くの意見を持っています。 XAMLに関する私の問題は、それがWFに埋め込まれていることです。 .NET 3.5でリリースされた古いWFでは、WFチームから、必要な形式をワークフローに変換するようにとの励ましがありました。 彼らは、Visioダイアグラムをワークフローに変換する例を使用しました。 しかし、新しいWFが4.0で登場したとき、すべてがXAMLに集中していました。 XAMLでワークフローを手動で作成しようとしたことがありますか？ 起きていません。 次に、デバッグシンボルとビューステートがあります。 また、差分ツールを使用して、XAMLの1つのバージョンを別のバージョンと比較してみてください。

XAMLを使用してワークフローを定義することは、NuGetパッケージを含めることの問題だと私は本当に思います。 ワークフロー定義を保存する他の手段を作成することをお勧めします。 多分あなたはよく圧縮する何かが必要です。 たぶん、セキュリティが必要で、限られた一連のアクティビティのみを許可します。 私はオプションがあることを好みます。

x：Class = ""属性を実装していません

確かに、コンパイルされたXaml（baml？）は、私が見たすべてのXamlフレーバーに著しく欠けています。 自分の暇な時間でこれに飛び込むことを考えましたが、近いうちに、おそらく来年には、ある程度の容量で利用できるようになると思います。 また、XamarinのXamlシステムはこれをサポートしていますが、閉じられており、拡張可能/アクセス可能ではありません。

XAMLでワークフローを手動で作成しようとしたことがありますか？ 起きていません。

本当です。 皮肉なことに、WFはXaml統合の中で（はるかに）最も包括的な恩恵を受けています。 おそらく、欠点があります。 Xamlが非常にデザイナーフレンドリーになるように構築されているのは残念ですが、WFを取り巻くツールは、手書きのシナリオ、さらにはデザイナー自身にとっても少し法外なものです。 彼らは本当にそれをビジュアルプログラミング言語にすることを目指していたようですが、かなりの量のサポート/リソースがなければ成功する必要があります。

XAMLを使用してワークフローを定義することは、NuGetパッケージを含めることの問題だと私は本当に思います。

私はあなたの考え方が好きです！ 👍

ところで、まだ行っていない場合は、System.Xamlポートのリクエスト/問題にアクセスして、可能であれば問題に賛成してください。 私は、すべての既知のシステムを最大限に活用し、それを1つの公式で信頼できるフレーバーとして提供する、新しいオープンソースのクロスプラットフォームXamlシステムを本当に望んでいます。 それはいいことではないでしょうか？ 😛

とにかく、今は最大74票です。 GitHubの反応が利用可能になる前に投票が開始されたことを考えると、これはかなりの狂気です。
https://github.com/dotnet/corefx/issues/5766

17のハートもかなりかっこいいです。 :)

サポート（および継続的なフィードバック）をありがとうございます！

@dmetzgar頑張ってくれてありがとう！ XAMLについてコメントするだけです。私が扱ったほとんどのファイルはビジュアルデザイナーが最初に使用したXAMLの方言で作成されていたため、以前はXAMLに対して非常に否定的な見方をしていました。

XAMLに加えて非常に優れた宣言型C＃APIを備えたXamarin.Formsを使用してプログラミングを開始すると、すべてが変わりました。 ビジュアルデザイナーは存在しません（XFリリースよりずっと後に登場したプレビューアのみ）。 驚いたことに、私はC＃コードよりもXAMLの方言で作業する方がはるかに好きです！ 彼らはそれを非常にうまくやってくれました、そしてあなたはマークアップの意味を汚染するデザイナーのメタデータをたくさん持っていません。 Prism.Formsのようなサポートフレームワークは、コードビハインドなしでコードを書くのに非常に簡単なので、XAMLに向けてスケールを大幅に傾けるのにも役立ちます。

したがって、XAML自体が問題になるとは思いませんが、最初に設計者をサポートするように設計された方言-XFは私にとってかなり説得力のある証拠です。

そのトピックに関する更新はありますか？

CoreWFは生きていて、 https：//github.com/dmetzgar/corewfに存在します

コアに追加された新しいCompositionAPIと.net標準2.0を使用してDynamicActivityを移植できるかどうかを確認する必要があります。

WFチームから連絡があれば素晴らしいと思います。

このトピックについては、多くの興味深い有益なコメントが寄せられています。 私の場合、.NET Coreに移植されたWFランタイムとイベント追跡（つまり、XAML、トランザクション、またはWCFビットなし）だけに価値があると信じており、これが（一種の）行われたことをうれしく思います。

WF.Coreが正式に存在する必要があることに同意します。 開発者のために機能するワークフローを定義するためのより柔軟な方法を作成する機能があれば、それが最善のアプローチになると思います。 MSがSystem.XAMLを移植しないと言った場合、XAMLは難しい問題であることに同意しますが、.NET Core WebAPIプロジェクトでWF.Coreを確認したいと思います。

ここの部屋にいる巨大な象は、MSや他の人たちがWFに関する情報を非常に厳しく取り締まっているため、このプロジェクトを軌道に乗せるのに十分な牽引力がないことだと思います。 確かにMSDNにはいくつかのサンプルがありますが、本やその他の堅実な（精査された）資料の形での情報はほとんどありません。

私は間違いなくこれを実現するために時間を割いて喜んでいます。

したがって、まだ開発中のOmniXAMLv2（githubリポジトリのブランチにあります）は、x：Class属性（https://github.com/SuperJMN/OmniXAML/issues/12）をサポートする必要があります。 多分それを（コア）WFに使用できますか？

@ewinningtonそれを指摘してくれてありがとう！
それは間違いなくそれの大きな塊です。 また、.NET Standard 2.0には、WFで使用される多数のSystem.ComponentModelタイプがあります。 System.Transactionsはすでにcorefxにあります。 不足しているのはWCFServiceHostだけです。

WCFServiceHostはIMHOを待機できます。 ホスティングモデルは、.Net Core /Asp.Netの世界で他のものと同じように不可知論的である必要があります...

@galvesribeiro WFがWebAPIを含め、.NET Coreの世界で機能する方法は他にもたくさんあるという事実を考えると、私はこれに同意します。

うん。 ただし、 @ dmetzgarには、今日WCFを使用している顧客がたくさんいることに同意します。そのため、WCFをサポートすることは必須ですが、これも遅れる可能性があります...

実際、ホスティングと「設計言語」はコアランタイムから抽象化する必要があります...

WFでWCFを使用しますが、WFがCoreにある場合は、WebAPIのようなものにうまく切り替えます。 実際、私たちはWCFからRESTfulな代替手段に移行してきました。 私たちはワークフローから非常に多くの価値を引き出し、それは私のお気に入りの.NETテクノロジーの1つです！

また、コア上のWFはxamlまたはwcfのいずれかに依存する必要はないと思います。ただ、wfエンジンとオブジェクトモデルがあれば非常に価値があります。 次に、それをasp.netコアのミドルウェアとして実行します。特に、kestrelに追加される新しいパイプライン/非http作業を使用します。

CoreでWFエンジンとオブジェクトモデルを使用およびサポートするための+1。 XAMLとWCFも回避できます。

XAMLは優れており、動的な構成を行うことができます。1つのプロジェクトで、ファイルからxamlワークフローをロードし、それらはWCFエンドポイントとして表されます。 また、これらのXAMLファイルは、利用可能なサービスのレジストリから自動生成されます。 したがって、wcf-servicesはエンドポントを取得します。
https：// [base] / wcf / [service_id1]
https：// [base] / wcf / [service_id2]..。
.Netコアにそのような機能があるといいでしょう:)
ああ...私は前にここにそれを書いた... :)））

ええ、私がここの土地に慣れてきたので、WFでのXamlサポート自体はそれほど重要ではありませんが、実際にはSystem.Xamlを移植することが重要な部分です。 それは別の問題で明確に捉えられているので-そして私は非常に人気があると言って非常に嬉しく思います（しかしそれがあなたの賛成を止めさせないでください、@ freerider7777！：smile：）-問題、私はWFを依存関係にすることを支持しています.NET Coreに確実に組み込まれるように、可能な限り無料で提供します。 👍

@ Mike-EEE私はずっと前にそこに賛成しました!! :)

ワークフローをコードで作成できることを考えると、EFCoreに似たFluentAPIを使用することは、WF Coreを実現するための有効なオプションでしょうか？ 次に、ランタイムのシリアル化/逆シリアル化を後で構築して、実装をはるかに簡単にすることができますか？

FluentAPIs ...今とても暑いです。 または少なくとも、彼らが受け入れられたので。 😄

FluentAPI、ビルダーパターン、どちらも基本的に同じです。 連鎖可能で使いやすいコードベースの方法を提供することは、この背後にある確固たる原則であると私は信じています。

デザイナーがいなければ、それはすべて役に立たない。 もちろん、すべてを自分でコーディングすることもできます-すべてのロジック、すべてのチェーンなど（流暢であろうとなかろうと）。 しかし、WFの優れている点は、処理の流れを視覚的に確認できることです。 これは、マネージャー（および他の「利害関係者」）と開発者の間のリンクです。 管理者はコードを理解できませんが、これらの高レベルの図はすべての人に理解できます。 WFを使用すると、別々の図（visioまたはその他）が分離されている場合は必要ありません。通常、実際のコードと同期していません:)

@ freerider7777 WF定義のシリアル化はxamlに限定されません（ @dmetzgarのhttps://github.com/dmetzgar/corewfを参照）。 JSONにも実装できます。これにより、NodeRed http://nodered.org/などの既存のプロジェクトを統合/フォークする可能性が広がります。これは多くの点でWF Designerの機能やUXに似ています（+これも実行されます） Webブラウザーで、WFの新しいユースケースを開きます）

WFを.NETCoreだけでなく.NETStandardに移植するのが最善だと思います。 以前にリンクされたWFランタイムはすでに.NETStandard 1.3で動作します（WriteLineアクティビティを削除すると低くなる可能性があります）。 2.0標準が間もなくリリースされると、自動cachemetadata、DynamicActivity、トランザクションスコープなどの多くの機能ギャップを埋めることができるようになります。 コンポーネントを異なるパッケージに分割して、有料モデルを作成する必要があります。ランタイムだけが必要な場合は1.3標準を使用できますが、DynamicActivityが必要な場合は2.0標準が必要であり、プラットフォームを制限します。

WFランタイムコードには間違いなく改善の余地がたくさんあります。 たとえば、アクティビティ拡張を依存性注入に置き換えます。 Fluent APIは、コードでワークフローを作成するのに役立ちます（そして、それらの行に沿って@knatによるhttps://github.com/knat/Metahを参照してください）が、ダイアグラムを使用して管理者やBAと通信する機能について@ freerider7777に同意します実際に本番環境で使用されているものから生成されることは大きなプラスです。 @helmsbはこれに関して多くの経験があります（http://dotnetrocks.com/?show=1236をチェックしてください）。

新しいデザイナーはWebアプリケーションである必要があります。 WPFまたはUWPをターゲットにすると、対象者が制限されます。 OmniXAMLが機能する場合、人々は現在と同じツール（VSまたは再ホストされたソリューション）を使用してワークフローを作成/編集できます。 問題は、現在の設計者が.NET Frameworkに組み込まれているため、機能や修正が.NETFrameworkのリリースを待たなければならないことです。 始めるには十分ですが、長期的な解決策ではありません。 @ erikcai8は、noderedと同様に、Webデザイナーでいくつかの実験を行いました。 彼に分かち合うよう説得できるかどうか見ていきます。

ワークフローデザイナーのフロントエンドの場合、githubで利用可能な最初の試みがあります： https ：//github.com/gary-b/WF4JSDesignerそしてそれをライブで使用できますhttp://gary-b.github.io/WF4JSDesigner/

これはすでにどのように見えるかです：

@ewinnington ：WebワークフローデザイナーのPOCを見るのは素晴らしいことです。 下のスクリーンショットに示すように、別のものも作成しました。

AWWWWWスナップ!!! それはWFPOC-OFFです!!! 🎉

ふふふ。 ねえ@ erikcai8Xamlへのエクスポートはどこにありますか？ ハハ。 ただあなたの悲しみをひっくり返します。 ソータ。 👼

どちらの努力も素晴らしく見えます。 それらの両方を見て良かった。 これは今では当たり前のように思えますが、元のWFにWebベースのビジュアルデザイナーがいたとしたら、どれほど素晴らしいことでしょうか。 すべてがロックされてロードされ、準備が整いました。URLにアクセスするだけです。 それはブランディングと採用に本当に役立ったと思います。 残念ながら、誰もがTFSベースのエディターにたどり着いたようですが、これはセットアップが非常に難しく、非常に冗長なXamlにつながりました。 これは、それに対処しなければならない典型的な開発者にとっては貧弱な経験であり、経験（WFまたはXaml）と関係があるものには悪い名前を付けました。

これ、OTOHは素晴らしいアプローチのようです。 ルネッサンスを始めましょう！

@ Mike-EEE私のE2E実験では、ワークフローコアエンジンが拡張され、JSONワークフローがネイティブに読み込まれるため、XAML形式は必要ありません。 ただし、XAMLワークフローは、JSONワークフローをロードするとワークフローエンジンからエクスポートできます。

そこが肝心だ。 ランタイムとそのオブジェクトモデルを、WF4.5の場合のようにデザイナとシリアル化された形式に結び付けてはなりません...

@galvesribeiro要点を理解しました。 ただし、この実験では、ワークフローコアの別のオプションとしてJSON形式がサポートされていることを前提としています。 上で説明したように、XAMLはまだ最新のWebテクノロジに対応していません。

WFが大好きです。.NetCoreに移植してください。

Webベースのワークフローデザイナーが必要です。 ワークフローを実行するための.NETCoreのサポートは2倍素晴らしいでしょう。 行く行く

Daniel Gerlagは、ここで非常に優れた軽量のコア互換ワークフローエンジンに取り組んでいます。

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

ダニエルズは非常に短い期間で長い道のりを歩んできました。 ぜひご覧になり、メリットがあればこのプロジェクトに参加してください。

このすべての関心を持って、Net Core互換エンジンを最初から構築してみませんか？

@ccpony今すぐドットネットコアでCoreWFを使用できるため-> https://github.com/dmetzgar/corewf 。 中央のコンポーネントは移植され、機能します。 .net標準2.0を待っていることがいくつかあります。

@ewinnington返信ありがとうございますが、うまくいきません。 WFは成功したMS製品ではなく、MSは何年もの間それを強化するために何もしていません。 コミュニティは、試行錯誤された実装の証言でいっぱいです。 企業では広く採用されていません。 それは扱いにくく、機能が多すぎて、学ぶのが難しく、（まだ）バグがあります。 そのインターフェースは広く悪意を持っています。 エンドユーザーに優しいテクノロジーにはなりませんでした。 内部は本質的にブラックボックスであり、簡単に拡張することはできません。 単純なワークフロー以外では低速です。 テストするのは非常に難しいです。 これは、古いテクノロジ（WCF、XAML）に基づいています。 ロン・ジェイコブスが病気になって以来、WFは衰弱し、MSには友達がいません。

私の推定では、WFはすべての人にとってすべてであるように努めましたが、実際、誰にとってもほとんどないことがわかりました。 マイクロソフトはそれをほとんど落としました。 なぜ私たちはそのようなものを復活させたいのでしょうか？ 重要なテクノロジーが再考と書き直しを必要とする場合、これはそれです。

DanielGerlagの新しいプロジェクトを見てください。 それは新しくて未熟です。 ただし、ワークフローには、拡張が容易な最新のアプローチが採用されています。 ここにいる全員が、複雑で時代遅れの、率直に言って過剰に設計されたプロジェクトを改造しようとするのをやめ、代わりに彼らの努力を新しくてより良いものに注ぐなら、私たちは価値のある場所にたどり着く可能性があります---段階的に構築する最初から巨大なものを書き直そうとする代わりに、世界クラスのワークフローエンジン。 正直なところ、私はここで非常に価値のある努力をしたいと思っているすべての人を賞賛します---最終的に、うまく設計された、機能的で、軽量で、東から学ぶためのクロスプラットフォームワークフロー（ステートマシン？）ツールを作成します。 しかし、申し訳ありませんが、皆さんがこの道を歩み続けると、皆さんの努力はすべて消え去ってしまいます。 MHO。

@ccponyご意見をお寄せいただきありがとうございます。 あなたが言及しているバグについて詳しく説明していただけませんか？ .NET Frameworkの問題を修正するためにできることがあれば、喜んでお知らせします。

@dmetzgar返信ありがとう、ダスティン。 WFアプリケーションを開発しようとしていた期間中に、バグに遭遇しました。 予期しない動作だけでなく、複雑なWFが「爆発」してXAML UIでエラーを生成し、XAMLコードで修正するのが困難な場合が何度かありました。 私はWFテクノロジーに大きな自信を持ったことは一度もありませんでした。 本当に、800ポンドのゴリラと格闘しているような気がしました---一歩前進するごとに、私は2歩後退することになります。

バグについて詳しく説明してほしいというあなたの親切なリクエストで、それがあなたが探しているものではないことを私は知っています。 率直に言って、私はそれらのバグを回避することができました。 しかし、以前の投稿で言及した他のすべての理由で、最終的にWFを放棄しました。

あなたはこの努力の先頭に立っており、私はあなたに敬意を表します。 しかし、複雑なテクノロジーを改良しようとすると逆効果になるのは確かです。 このスレッド全体に続いて、私は単に進歩が非常に遅いと感じずにはいられません---仮にあったとしても---そして最終的にはこれらすべてから何も表示されません。 古いワークフローがここで作成されたものに移植できる可能性は非常に低いと思います。 このスレッドの人々は、クライアントベースのワークフロー（つまり、JavaScript）、REST互換性、依存関係の削減、クロスプラットフォームなどについて話しています。たとえば、XAMLは古いWFテクノロジーの非常に重要な部分であり、WFをコアに移植する用途は次のとおりです。 XAMLはその一部ではありませんか？

ダスティン、私はあなたにこれを尋ねる必要があります：ここで私たちはこのプロジェクトに18ヶ月間あり、実際の進歩がなされているというコンセンサスがないようです。 私はあなたの努力を尊重し、あなたが素晴らしいコーダーであることがわかります---しかし、ここに私の質問があります：このすべてのエネルギーと熱意を集めて新しいものを作成することははるかに理にかなっていますか？

@ccponyこのトピックでの議論は、WF .Net Standardをサポートすることであり、その逆ではありません。

興味があります... Sharepointの展開を実際に使用または見たことがありますか？ そうした場合、それが本当にWFに大きく依存していることがわかります。 BizTalkの展開を見たことがありますか？ 同じ。

これらは企業の世界で主要なMSFT製品であるため、そうです、WFを気にするユーザーがいて、その使用法があります。 あなたが言ったように、それは見捨てられた/落とされたプロジェクトではありません。

そうは言っても、 @ dmetzgarリポジトリを見ると、WFの古い化身からいくつかの動作が類似しているか、継承していることがわかります。また、軽量になるように再設計されていることもわかります。 永続性は分離されており、人々は新しいものを簡単に作成できます。 設計者は切り離されており、人々はすでに複数のテストを作成しています。

何か新しいものが欲しいというあなたの欲求不満を理解しています。 私を信じてください、私もそれが起こりたいです。 しかし、 @ dmetzgarと彼のチームを理解する必要があります。 顧客の95％は、基本的にBizTalkとSharepointで実行されている古いWFのユーザーであるため、これは優先事項ではありません。 私は古いWFを非常に高いtps環境（銀行および金融取引）で何年も使用しましたが、それは非常に役立ちました。

私の新しい技術は.NetCoreで動作していますが、現在それを再び使用していない唯一の理由は、.NetCore用にまだ使用していないためです。

私がすでに@dmetzgarに提案したのは、WFリポジトリを.Net Foundationに持ち込み、マイルストーンを定義し、そこにコードを配置し、Issuesとしてタスクを追加し、コミュニティがそれを開始できるようにup-for-grabsとしてタグ付けすることです。 ただし、それでもこの作業を実行するには彼のチームからの時間が必要であり、おそらくその時間は（まだ）利用できません。

@galvesribeiro私はあなたのポイントを取得します。 はい、SharePoint展開を作成しました。 そして、BizTalkの展開が実際に行われているのを見たことがあります（*シャッター*）。 SharePointとWFの関係を理解し​​ています。 （BizTalkがどういうわけかWFに依存していると提案したとき、あなたが何を意味するのかわかりません。そうではありません。）

しかし、私は1つの重要な点についてあなたと意見を異にする必要があります。それは、 WFは見捨てられた/取り下げられたプロジェクトです。 この時点で、SharePoint開発者の懸念を本当に理解しています。 MSがSharePointでWFの機能を強化すると信じる理由はありません。 @dmetzgarの取り組みがSharePoint（またはBizTalk）の将来と関係があるとあなたが考える理由がわかりません。 MSがSharePointを@dmetzgarのコードで改造するのとは異なります。 申し訳ありませんが、SharePointの将来は、ここで行われている取り組みとは何の関係もありません。

したがって、本当に重要なのは、これらすべてから優れたワークフローエンジンが生まれるかどうかです。 そして、WFのような巨大なものを未来に押し込もうとすることは最善の行動ではないというのが私の主張です。 ゼロから構築することをお勧めします。

@ccponyここには、このプロジェクトの実現を積極的に求めている人がたくさんいて、実際にそれを実現するために時間を割いている人もいます。 個人的にはWFをMicrosoftの失敗した製品と見なすかもしれませんが、それは引き続き.NETの一部であり、ここでは私たちだけでなく多くの人に使用されています。

このスレッドは、建設的な批判と移行を実現するためのインプットのためのものであり、他の人や製品自体を非難するものではありません。 あなたの見解は尊重されますが、それらはあなたのものであり、WFが彼らにとってどのように重要であるかに関して他の人が異なって考えるかもしれないことに注意してください。

製品を改善する方法と、その試みに積極的に参加している人々を支援する最善の方法についてのご意見を積極的に歓迎します。

ありがとう= ^ _ ^ =

@ccpony

（BizTalkがどういうわけかWFに依存していると提案したとき、あなたが何を意味するのかわかりません。そうではありません。）

申し訳ありませんが、私は自分自身をひどく表現しています（私はモバイルを使用しています）。 私は両方を一緒に使用するアプリケーションを持っていました、そして私は同様に使用する他の多くを知っています。

MSがSharePointでWFの機能を強化すると信じる理由はありません。

私はそうなると言っているのではありません。 WF Todayを使用するチームは、Sharepointの展開のサポートに完全に集中していると言っています。 Sharepointの最新バージョンでさえ、同じ/現在のバージョンのWFを使用しています。

@dmetzgarの取り組みがSharePoint（またはBizTalk）の将来と関係があるとあなたが考える理由がわかりません。

それがSharepointの将来に影響を与えると言っているのではありません。 私が正しく理解していれば、チームはSharepointのサポートに忙しいと言っています。 （ @dmetzgarは私が間違っている場合は私を修正することができます）

MSがSharePointを@dmetzgarのコードで改造するのとは異なります。 申し訳ありませんが、SharePointの将来は、ここで行われている取り組みとは何の関係もありません。

MSがSharepointvNextでWFvNextを使用するかどうかを決定できるのは、MSが確実にそれを伝えることができる場合だけです。 繰り返しますが、問題はWFチームが両方に対処できないことです。

したがって、本当に重要なのは、これらすべてから優れたワークフローエンジンが生まれるかどうかです。 そして、WFのような巨大なものを未来に押し込もうとすることは最善の行動ではないというのが私の主張です。 ゼロから構築することをお勧めします。

誰もそれをそのまま移植していません。 @dmetzgarのリポジトリは、ゼロから再設計されていることを証明しています。 繰り返しますが、問題は、チームが両方のことに対処しなければならないバックログと帯域幅です。 そのため、ドットネットファウンデーションで「オープン」にし、WFチームのガイダンスとキュレーションを使用して、コミュニティ主導の主要な取り組みにすることを提案しました。これにより、スケジュールへの影響をできるだけ少なくするようにしています。

繰り返しになりますが、 @ InariTheFoxと私が述べたように、このスレッドは移植の推進であり、必ずしもこのすべての機能を備えた古い発酵を新しいバージョンに強制的にプッシュすることを意味するわけではありません。 ただし、人々が現在のWFベースの製品に多大な労力（およびお金）を費やしていることを理解することは重要です。したがって、 @ dmetzgarは、古いワークフローとの可能な限りの互換性に関心を持っています。

Ok。 ここに情熱があります。 実際、私が前に述べたすべての問題に対処するWFの優れた代替品があれば、この会話はありません。 記録のために、私たちの多くはWFから離れて、次のことが起こるのを待ち望んでいました。 それは決してしませんでした。 私の知る限り、広く評価されている現在の、サポートされている、機能的な.Netベースのワークフロー/ステートマシンソリューションはありません。 理解してください：私は、WFはマイクロソフトの観点からは死んだテクノロジーであるという私の主張を支持しています。

しかし、そうは言っても、私が理解するのを手伝ってください。 @dmetzgarのレポはそのまま機能しますか？ それを使ってワークフローをどのように書くのですか？ サンプルコードが表示されず、ドキュメントもありません。 どのように進めますか？

WFを製品戦略の中心にした製品/企業はたくさんあると思います。サポートモードでのSharepointの依存関係だけではありません。現在の会社では、WFを中心技術とする自動化プラットフォームを開発しました（そして私は知っています）製品にWFを使用しているこの市場の他の2つの競合他社）; また、インシュアテックでそれを使用している人々と話し合ったので、WFの聴衆はまだそこにいると強く信じています。

そうは言っても、.net CoreはMicrosoftの重点分野の1つであるように思われ、次の期間には多くの技術革新がそれに入るでしょう。 WFを含まないのは大きな損失だと思います。

私の見解では、それを実現するための正しい方法は、WFコアをxamlから独立させ、他の形式（例：json）でもワークフローを（逆）シリアル化することを容易にすることです。 これにより、Webブラウザーでホストされるワークフローデザイナーのようなシナリオの実装も簡素化されます。 そして、 https：//github.com/dmetzgar/corewfリポジトリを使用すると、出発点があります。

WFの現在の状態（MSによって放棄されたとは思わない）の概要に関心のある方のために、しばらく前に、WFに関する利用可能な情報を投稿とプレゼンテーションで一元化しましたhttp://andreioros.com/blog / windows-workflow-foundation-rehosted-designer / ; 私はまだそれを最新の状態に保っています

私たちと私たちの顧客はWFに依存しており、サーバーだけでなくクライアントでもWFが機能することを心から望んでいます。 XAMLやその他の依存関係がなく、軽量であるが、MSでコミュニティサポートされている既存のWFの表現力を備えたWFは、確かにエキサイティングで価値のある製品です。

もう一度、質問させてください。 @ dmetzgarのポートを実行するにはどうすればよいですか？ 現在の状況は？

@dmetzgarのポートが現在の化身で実際に使用できることを知りませんでした...

上記の@ewinningtonから：

「今すぐドットネットコアでCoreWFを使用できるため-> https://github.com/dmetzgar/corewf 。中央のコンポーネントが移植されて機能します。.net標準2.0を待っていることがいくつかあります。」

その場合、私もその使用法について聞きたいです...

はい、それはコア機能のベアボーンです。 コードベースのワークフローを実行できます。 netstandard2.0に欠けている機能は、主にトランザクションのサポートに関連しています。

それは私がまだそれをオープンにして人々を中心的な場所に貢献させることを提案するもう一つの理由です。 それを広めると、将来、最終製品に到達するのがさらに難しくなります。

Coreの一部としての最新のRoslyn機能のテストとサポートを使用して、WFの書き換えに賛成票を投じてください。 サーバーレスとコンテナがアーキテクチャにどのように影響するか、特に個別のドメインコンテキストとビジネスプロセス内でのルールセットの展開とスケーリングにどのように影響するかを知りたいです。 個人的には、WYSIWYGデザイナーよりも簡潔なDSLの方が好きです。 私は個人的にデザイナーが大好きでしたが、ほとんどいつも風変わりな感じがしました。 WF自体は非常に堅実である可能性がありましたが、深い専門知識が必要でした。 ちなみに、WFManagerとSQLServerの永続化されたフローを含むWFの大規模な展開には、MSコンサルティングとバグ修正が必要でした。 私は過去数年間Javaチームをサポートしていますが、主にMS技術に焦点を当てて15年余り経った後、.NETに注目したいと思います。 ニック・ハリソンの「Code Generation with Roslyn」を読んでいて（彼や本とは何の関係もありません）、ビジネスルールエンジンのスペースにもう一度アプローチすることを考えたので、WFの運命についてもう一度疑問に思いました...正直なところ、Azure Functionsは、MSリソースと、どこでもWFへの深い投資をサポートするという一般的な企業の意欲の両方と競合していると思います。 彼らがあなたにそれを使って欲しいのは明らかなようです...したがって、おそらく解決策は、代わりにオープンソースの.NETバージョンのOpenWhiskに焦点を当てることです。 しかし、コンテナ化された世界では、...私はOpenWhiskをサービスとして使用することができます。 そう...

PSは、外部化された式をインポートする堅牢な方法をサポートするだけで、WFが必要と思われるアプリ要件の60％を解決できる可能性があります。 CSharpScriptでしたか？ 単純なAPIを使用して基本的なビジネスルール構成をインポートする簡単な方法は、大いに役立ちます（さまざまな永続性、取得、およびキャッシュオプション）。 使い捨ての仮想インフラストラクチャ（Infrastructure-、Container-、Platform-as-a-Serviceによる自動化）を使用すると、WF vNextは、バージョン変更をアプリにインライン化するよりも、サービスとして展開することに重点を置くことができます（つまり、WFのより優れたソリューション）。 WCFで）

私はこの会話に非常に興味があります。私のチームは、XAMLのフラストレーションにも取り組んできました。私たちのジレンマは、お客様がVisual Studioや再ホストされたデザイナーを必要とせずに独自のワークフローを作成できるように、独自のUIデザイナーを作成していることです。 XAMLのチャンクを再利用可能なビットに保存する機能が必要です。これにより、顧客はこれらのビットを常に書き換える必要がなくなります（ワークフロー関数と考えてください）。これには、XAMLのチャンクをマージする方法を知る必要がありますが、これは非常に苛立たしいことです。私たちが考えているのは、さまざまなアクティビティとそのリンクのデータベースモデルに依存し、XAMLを完全に無視する抽象化を作成することです。その後、ワークフローが実行されるたびに、プログラムでアクティビティなどを作成します。このアプローチを研究しているときに、私はこのスレッドに出くわしました。会話を続けてください、私は他の人の意見を聞くことに非常に興味があります。

@ erikcai8ワークフローデザイナーはとてもいいアイデアです。 ワークフローデザイナーのソースを入手できますか？

自動化プロジェクトでWFを5年以上使用していますが、それは素晴らしいことでした。 多くの開発者がこのリクエストをサポートし、実現することを願っています。 仕事を始めてからずっと.Nettechを使っていて、これからも使い続けたいと思っています。 ただし、クロスプラットフォームをサポートできることは会社の方向性であるため、.NetCoreで完全なWFが表示されることを本当に楽しみにしています。

ネット標準2.0の登場により、corewfの問題に関する最新情報を入手できると便利です。

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

追加されたAPIはどのように移植プロセスのブロックを解除し、何ができるでしょうか？

netstandard2.0に関係なく、このポートはIMHOと同じように動作するはずです...書き直して...外部のタスクスケジューラ、async / await / Task、およびその他の最新のものに対応できるようにします。 私はWFが大好きですが、現在のバージョンはかなり時代遅れです...

私はこれを何の軽蔑もなく意味します。 本音をいうと。 しかし、このプロジェクトが絶望的であることを理解しているのは私だけですか？ .Net用の優れたワークフローエンジンがどうしても必要ですが、それだけではありません。 ここで会話を変えてはいけませんか？

私は、新しい、より優れたワークフローエンジンを受け入れています。 結論として、.NETCoreに1つ必要です。 私たちは何年もの間WFを使用してきましたが、それは私たちにとって非常にうまく機能しているので、それが代替手段である場合は何もないよりはましです。

@kalokamgit 、ソースは参照ソースで入手できます。 それは2つのアセンブリにあります：
System.Activities.PresentationおよびSystem.Activities.Core.Presentation 。

残念ながら、参照ソースを公開するツールはC＃コードのみを実行します。 XAMLファイルは含まれていません。 これに関するフィードバックを[email protected]に提供したり、ユーザーの音声の問題に投票したりできます。

コードは.NETFrameworkに含まれているため、独自のツールで自由に使用できます。 いくつかの例は、 @ orosandreiのプロジェクトとここにあるサンプルプロジェクトです。

私はこれを何の軽蔑もなく意味します。 本音をいうと。 しかし、このプロジェクトが絶望的であることを理解しているのは私だけですか？ .Net用の優れたワークフローエンジンがどうしても必要ですが、それだけではありません。 ここで会話を変えてはいけませんか？

もしあなたが_本当に_無礼を意味しないのなら。 :)私はみんなの考えがフローの周りにあることに興味がありますか？ これは、「現代」の「ワークフロー」を考えるときに私が考えることです...また、Azureが最近かなり懸命に取り組んでいることでもあります。

私は本当に本当にそれを意味します:)

フローはZapierの成長への答えだと思いますか？ それがWWFにどのように取って代わるのか私にはわかりません。

WFは廃止されましたか、それともここで何かが足りませんか？ それはとても悲しいことです！

どこでWFに投票できますか？

この号のトップポストは最高の場所です。

@rjacobs （WFの第一人者）はこの問題についてどう思っているのだろうか。

@ronljacobsのことですか？

@dmetzgarおそらくそうです。 彼は真のWFヒーローです

これが私の答えです
https://github.com/danielgerlag/workflow-core

ロン・ジェイコブスは、何年にもわたって彼の心と魂をWFに注ぎ込んだ男でした。 彼はダーカム病にかかり、2013年にマイクロソフトを去りました。 （ここで）彼が去ったとき、それはWFのためでした。 もう一度、そしてうまくいけば最後に：WFは死んでいます。

そしてもう一度---私は誰もが上記のDanGerlagのプロジェクトを見るように勧めます。 それは雄弁で、美しく考案され、コア上で実行されます。 実行可能なワークフローソリューションに貢献したい人は誰でもそれを見る必要があります。

また、 Durable TaskFrameworkもご覧ください。 これはAzureFunctionsに追加されています。DurableFunctionsを参照してください。

@dmetzgarこのフレームワークは、WFの代替と見なされるおむつに含まれています。 マイクロソフトがこのようなことを提案するのは深刻ではないと思います。 車輪の再発明を行い、WFを.NET Coreに移行して、すべてのMicrosoftプロジェクトの基盤として再利用するよりも、はるかに優れているのではないでしょうか。 言葉の厳しさは申し訳ありませんが、WFの現状に非常に失望している多くの人々の感情を表していると思います。

@スリマン、フェアポイント

corewfリポジトリのreadmeを更新して、WFを.NETCoreに移植する際の内容を詳しく説明しました。 見ていただけませんか？

@dmetzgar明確にし、WFを.NETCoreに移植する方法を明確に示してくれてありがとう。 マイクロソフトがこの移行作業のすべてを行うわけではなく、コミュニティが行うことを望んでいるということから、私は理解していますね。 この質問への答えが鍵となります。回答に応じて、企業は別のルートを選択するか、Microsoftが行うべき作業を行うことができます。

Microsoftは、WFから.NETCoreへの公式移植を行いません。 私のチームと私は暇なときにこれに取り組みますが、公式の立場や予定されているリリースではありません。 リストされているすべての問題は、手に入れることができます。 私たちが行ういくつかのプロジェクトでは、このようなポートの用途があります。 それが私たちの貢献のほとんどが由来するところです。 今のところこの問題を閉じて、最新の作業をフォローするためにcorewfリポジトリを紹介するのは公平だと思います。

こんにちは、
Futureマイルストーンから2.1への変更は、MicrosoftがWFを.NET Coreに移植することを意味しますか？

クローズされた問題のマイルストーンの変更は、どのリリース中に問題がクローズされたかを反映しています。
この特定の問題は、基本的に「修正されない」としてクローズされました-上記の説明を参照してくださいhttps://github.com/dotnet/corefx/issues/2394#issuecomment -316170275

@karelzなんて残念だ。 しばらくの間、宝くじが私たちを襲ったように見えました。

WFに基づくソリューションがあります。 WFを使用してアクティビティのステップを作成しています。このワークフローはすべてのサブスクライバーに配信され、サブスクライバーはWFに基づいてアクションを処理します。 私たちはWFが大好きです。 クロスプラットフォームのサポートは、当社の方向性です。 .NETCOREにWFを搭載することに非常に興味があります。

.netコアに部分的に移植されたWorkflowFoundationのコードであるCoreWFがあります。 これで、WorkflowFoundationクロスプラットフォームを使用できます。 現時点では、XAMLベースのワークフローを使用することはできません。

Net Standard2.0に加えてDynamicActivityのサポートを追加することに取り組んだブランチがあります。

XAML解析プロセスでは、MicrosoftがSystem.XAMLを十分に開いて、ファイルの解析を正しく進めることができるようにする必要があります。

この問題の進行状況は、 https ：//github.com/dmetzgar/corewf/issues/6と、この問題に通知するためのさまざまな試みで追跡できます。
CoreFXの場合
ReferenceSourceで

.Net互換性パックには、System.XAMLの前面に「たぶん」があります。 しかし、その包含についてフィルタリングされたニュースはありません。 Ship .Net Framework互換性パックの問題には、現在System.XAMLの「計画なし」が記載されています。

おそらく、 Customer Adoption Epicの問題を使用して、Workflow Foundation（およびSystem.Xaml）を追加することで会社が製品を出荷する方法についてのストーリーを伝えることができます。

私の会社はWFにも投資しています。クライアントがWorkflowFoundationを使用してワークフローを作成するエネルギー会社向けの製品があります。

お返事ありがとうございます。
とても助かりました。

2017年11月2日18:22、「EricWinnington」 [email protected]は次のように書いています。

のコードであるCoreWFhttps：//github.com/dmetzgar/corewfがあります
WorkflowFoundationは部分的に.netコアに移植されました。 ワークフローを使用できます
ファウンデーションクロスプラットフォームになりました。 XAMLベースのワークフローを使用することはできません
現時点では。

ダイナミックアクティビティのサポートの追加に取り組んできたブランチがあります
Net Standard 2.0https：//github.com/ewinnington/corewfに加えて。

XAML解析プロセスでは、MicrosoftがSystem.XAMLを開く必要があります
ファイルの解析を正しく進めることができるように十分です。

ここで問題の進行状況を追跡できます：dmetzgar / corewf＃6
https://github.com/dmetzgar/corewf/issues/6そして私のさまざまな試みで
この問題に通知する場合：
CoreFXの場合
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
ReferenceSourceで
https://github.com/Microsoft/referencesource/issues/39

.Net互換性パック
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
System.XAMLの前面に「たぶん」があります。 しかし、そのニュースはフィルタリングされていません
インクルージョン。 Ship .NetFramework互換性パックの問題
https://github.com/dotnet/corefx/issues/24909は現在「いいえ
System.XAMLの「計画」。

多分また問題顧客養子縁組叙事詩
https://github.com/dotnet/corefx/issues/24751を使用して伝えることができます
Workflow Foundation（およびSystem.Xaml）を追加することでどのように可能になるかについてのストーリー
あなたの会社は製品を出荷します。

私の会社はWFにも投資しています：私たちはエネルギー会社向けの製品を持っています
クライアントがWorkflowFoundationを使用してワークフローを作成する場所。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
。

こんにちは、
これはマイクロサービスの世界であり、すべてのものがコンポーネントに分解されます。 これで、オーケストレーションを行う必要がある場合は、ワークフローにプレミアムを請求するAzureロジックアプリまたはその他の外部ベンダーに依存する必要があります。 NetflixConductorのような非.NETWF製品はほとんどありませんが、純粋な.NETコアバージョンで提供したいと考えています。 https://github.com/Netflix/conductorでNetflixコンダクターから手がかりを取得し、そこからビルドを開始できます。 これは、LogicAppsを使用できないAzureStackにアクセスできないプライベートクラウド開発者にとって大きな恩恵になります。

気づきのためにここに投稿すると思いました。 私は次のドキュメントを読んでいて、このスレッドについて考えさせられました。
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

Dynamics365とPowerAppsはマインドメルドを実行しており、ワークフロー処理のためにある程度の容量でWindowsWorkflowを使用しているようです。 もちろん、これはすべてWindowsのみですが、クロスプラットフォームなどの新時代では、これはどのくらい続くのでしょうか。

何を使うのかわかりません。 MSFTがこれを行うことを望みます。 マイクロソフトを明確にします。

@VenkateshSrini 、ケイデンスも調べる必要があります： https ：//github.com/uber/cadence
このモデルはAmazonのSWFに似ていますが、オープンソースです。 ただし、.NETクライアントはまだありません。

探している。 ネットコアバージョン

起こらないだろう。

差出人： [email protected]
送信日：2018年9月26日水曜日午前0時30分
宛先：dotnet / corefx [email protected]
Cc：Jeffrey Michelson [email protected] ; 言及@ noreply.github.com
件名：Re：[dotnet / corefx]ワークフローファウンデーションを.NETCoreに移植（＃2394）

探している。 ネットコアバージョン

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034で表示するか、スレッドhttps://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5uewLNgaJp

残念な

では、Microsoftが非Azureエコシステムのiftttまたはワークフローに提供しているものは何ですか。 Azureからmlのようなものを有効にしたい場合は、ワークフローを使用しないのはなぜですか

DanGerlagの作品をチェックしてください。

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

差出人： [email protected]
送信日：2018年9月26日水曜日8:34 AM
宛先：dotnet / corefx [email protected]
Cc：Jeffrey Michelson [email protected] ; 言及@ noreply.github.com
件名：Re：[dotnet / corefx]ワークフローファウンデーションを.NETCoreに移植（＃2394）

では、Microsoftが非Azureエコシステムのiftttまたはワークフローに提供しているものは何ですか。 Azureからmlのようなものを有効にしたい場合は、ワークフローを使用しないのはなぜですか

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799で表示するか、スレッドをミュートしますhttps://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY 。

.netコアへのワークフローファンデーションの移植版であるCoreWFがあります。 このポートは進行中です。 助けてくれる人を探しています。

次の主要な足がかりは、ロードされたワークフローをRoslynでコンパイルして、ワークフローパラメーターでコードを使用できるようにすることです。これは、XAMLで定義されたワークフローに必要です。 命令型コアでワークフローを定義すると、CoreWFを使用できるようになります。

@ewinningtonと@dmetzgarの作業に感謝します！ CoreWFのPortable.XAMLを介したXAMLサポートは、その取り組みにとって大きな問題です。 @dmetzgar新しいバージョンをNuGetにすぐに公開する予定ですか？

こんにちは、みんな、

これはすべて本番環境の準備ができていますか。 外部Uiから実行されるワークフロー定義を大いに楽しんでいます。 ただし、エンジンは定義をロードして、それ以降で動作できる必要があります。 iffftの種類の詳細

@VenkateshSrini 、マイクロソフトがクロスプラットフォームのワークフローフレームワークを提供する必要はないと思います。 .NET Frameworkの時代、Microsoftはすべてを提供しましたが、これはコミュニティ全体に悪影響を及ぼしました。 組織で採用され、「本番環境に対応」した.NETオープンソースライブラリをもっと見たいです。

@ watertree 、Portable.Xamlの新しいリリースを待っています。 CoreWFXAMLサポートに必要な重要な修正があります。

今のところ（永続性を備えた）長時間実行されるワークフローの代替手段は何ですか？ 有料のものだけ？

@ freerider7777

参考： https ：//github.com/danielgerlag/workflow-core

弊社で使用しており、非常に良い結果が得られています。

まだフォローしている人のために、 CoreWfプロジェクトは、動的にロードされたXAMLワークフローの実行を可能にするRoslynの統合により、重要なマイルストーンを前進させました。 それでもdotnetcoreでWorkflowFoundationが必要な場合は、それを確認してください。

こんにちは 、
つまり、既存のXAMLワークフローをそのまま使用できるということですか。 制限はありますか

制限はありますか

インスタンスストアはまだ移植されておらず、デザイナーはコア上になく、WCFサーバーがまだコア上にないため、WCFサービスは利用できません。

CoreWfリポジトリで問題を作成し、必要な要件をリストしてください。 そこで会話を続けることができます。

corewfの現在のnugetは古く、マージされたばかりのRoslynベースのランタイムXaml実行は含まれていません。 何が機能し、何が機能しないかを確認するためのフィードバックを引き続き探しています。

これは、それが決して起こらないことを意味しますか？

それは起こらないだろう。 それは決して起こらなかった---彼らの最善の努力をした人々への不快感はありません。 Dan Gerlagのプロジェクト（https://github.com/danielgerlag/workflow-core）またはbite-the-bulletをチェックして、AzureLogicAppsトレインに参加してください。

こんにちは、2020年10月の電話です。 .NETCoreのWorkflowFoundationに関するニュース/更新/リリースはありますか？

それとも私たちは皆エルザに移動する必要がありますか？ https://elsa-workflows.github.io/elsa-core/

@wstaelens MSの答えはかなり明確だったと思います：WFは正式に.NetCoreに移植されません。 推奨される代替手段はCoreWFです。