Runtime: من مؤسسة Port Workflow إلى .NET Core

cc: terrajobst ، joshfree ، weshaggard

نحتاج إلى فتح System.Xaml قبل بذل جهد جاد في النقل.

أنا أفهم jakesays .

النقطة المهمة هي أن WF يمكن أن يكون لها تعريفات سير العمل الخاصة بها في فئات C # بدلاً من XAML (في الوقت الحالي) ولا يستخدم الكثير من الأشخاص تمثيل XAML لها. لاحقًا عند فتح System.Xaml ، يمكننا أيضًا دمج المصمم المرئي وتعريفات XAML. أيضًا ، لقد عملنا على محرك سير العمل الذي يتبع استخدام / تنفيذ WF بدقة ولكن بدلاً من استخدام XAML كمخزن أساسي لتعريفات سير العمل ، فلدينا ذلك استنادًا إلى Json في المتجر ، مما يفتح الكثير من الفرص لمصممي سير العمل الجدد في أي الأنظمة الأساسية (ليس فقط VS أو مكون المصمم المستضاف لـ WPF / WForms) ولها العديد من الفوائد مثل القراءة / الكتابة بشكل أسرع ، وبساطة المخطط ، وعمليات التحميل / التجميع ووقت التشغيل بشكل أسرع. يمكن استخدامه أيضًا لدعم سير عمل العميل ، لتوجيه تدفقات واجهة المستخدم للتطبيق على تطبيقات Windows Phone / Store على سبيل المثال نظرًا لوقت تشغيله الخفيف.

أعتقد حقًا أن WF مكون قوي حقًا على منصة .Net ، ولكن بالنسبة لتقنيات اليوم ، لا يزال XAML "محددًا" له ، ولكن إذا كان القرار بشأن استراتيجية MS يمكننا الاحتفاظ به كما هو ومنفذ إلى CoreCLR.

شكرا

zhenlan يمكن التحدث نحو التفكير الحالي حول WF

galvesribeiro قد لا يستخدم العديد من الأشخاص xaml ، لكن الكثير منهم يستخدمه ، ويعتبر بالفعل جزءًا أساسيًا من WF. نحن نستخدم xaml على نطاق واسع ، لذلك أرى WF بدون دعم xaml لا يكاد يستحق الاستخدام.

أفضل أن نواصل الضغط على Microsoft لفتح System.Xaml.

واستخدام JSON كبديل ليس بالأمر الجذاب على الأقل.

galvesribeirojakesays نود حقًا معرفة مدى اهتمام عملاء WF بالحصول على إصدار .NET Core من WF لذلك من الرائع سماع التعليقات من المجتمع. إذا كان هناك طلب كافٍ ، فسيكون من المفيد لنا المضي قدمًا.

نحن في مرحلة مبكرة من تقييم الجدوى والتبعيات وأولويات الميزات وما إلى ذلك ، لذا سيكون من المفيد جدًا لنا معرفة السيناريوهات التي تدور في ذهنك ، ولماذا سيكون WF على .NET Core (مقابل WF بالكامل .NET) مفيدة لك وما هي ميزات WF التي ترغب في رؤيتها أولاً.

galvesribeiro في السيناريو الخاص بك مع بناء مهام سير العمل في التعليمات البرمجية وتخزين تلك التعريفات على هيئة JSON ، ما الذي تستخدمه (تخطط؟) للتعبيرات؟ هل تستخدم تعبيرات VB أو تعبيرات C # أو هل لديك أنشطة تعبيرات خاصة بك تعتمد على CodeActivity للتعامل مع التعبيرات؟

شكرا على الادخال.

jakesays لا مانع لي من استخدام XAML. أنا أهتم فقط بالأداء ...

zhenlan لدينا مفتاح دفع إلكتروني يعالج المليارات من معاملات بطاقات الائتمان / الخصم يوميًا لبعض البنوك هنا في البرازيل ، والبعض الآخر في الخارج. كنا مشغولين في أماكن العمل ونقوم بتحديث التكنولوجيا لتكون سحابية بالكامل ، ونقدمها كخدمة على Azure. لقد حصلنا على اتفاقية مؤسسة لاستكشاف كل ما نحتاجه من Azure هنا كمنصة معالجة مدفوعات متعددة المستأجرين لعملائنا.

نحن نحقق في استخدام NanoServer لـ و CoreCLR حتى نتمكن من تقليل البصمة وسطح الهجوم والصيانة التي يتم إنفاقها لتشغيل خدماتنا وقد لاحظنا أن coreCLR ليس لديه (على الأقل) نظام. تم نقل الأنشطة حتى الآن. بمعنى آخر ، لا يوجد أساس سير العمل.

محرك المعالجة الأساسي لدينا هو محرك أعمال مبني على أعلى WF ويحتوي على أكثر من 40 نشاطًا مخصصًا يركز على أعمالنا. يقوم هذا المحرك بمعالجة عملية / قواعد المعاملة في الوقت الفعلي من أجل الحصول على الموافقة على المعاملة. نحتاج إلى توسيع نطاقه على الطلب ، ونفعل ذلك مع التنفيذ الحالي لـ WF في السحابة ، دعنا نقول أنه غير ممكن.

نقله إلى .net core ، بدلاً من الاحتفاظ به على .net كامل (ملف تعريف الخادم) سيفتح إمكانيات تشغيل سير عمل العميل ، وهذا شيء نفتقده حقًا في أعمالنا. يمكن لعمليات سير عمل العميل هذه أن تجعل الأشخاص يطورون منطق عمل العميل التصريحي ، بطريقة يمكن للأجهزة الصغيرة مثل الهواتف الذكية ، والأجهزة القابلة للارتداء ، وإنترنت الأشياء ، وأجهزة الدفع الطرفية الخاصة بنا اتخاذ بعض القرارات دون كتابة تعليمات برمجية متكررة حقيقية.

نظرًا لأننا لم نعثر على أي جهود على WF لـ .net Core ، وحتى أنه لم يتغير لسنوات وما زال يعتمد على XAML ، فقد قررنا بدء محرك سير العمل الخاص بنا الذي يتصرف تمامًا مثل WF. نموذج الأنشطة نفسه ، ونمط الكود نفسه ، وما إلى ذلك ، ولكن أخف كثيرًا ويعتمد على Json كمخزن تعريف خاص بهم. هذا يسمح للأجهزة ذات القدرة الحسابية الصغيرة ، بمعالجة سير العمل دون عبء التعامل مع XAML / XML ، لذا فإن معظم الكود الخاص بنا المصمم لـ WF يعمل بدون العديد من التغييرات على تعريفات Json بدلاً من مهام سير العمل المستندة إلى XAML. أيضًا ، الابتعاد عن XAML ، سيفتح إمكانية لمصممي سير العمل الجدد ... ليس عالقًا في Visual Studio وتطبيقات WPF لإعادة استضافة مصمم VS.

ما أحاول اقتراحه هو أحد هذه الخيارات:

1. منفذ WF (مع XAML) كما هو. ستستغرق هذه الخيارات وقتًا أطول نظرًا لأن WF اليوم يعتمد على ملف تعريف خادم .Net ، مما سيجعلنا نقضي الكثير من الوقت في فصله من أجل جعله يعمل مع .Net core.
2. منفذ WF يعيد كتابته إلى .Net core. بهذه الطريقة ، يمكننا الحصول على المفاهيم الأساسية والتركيز على تصميم محرك خفيف الوزن يمكن تشغيله على الخوادم أو العملاء أو إنترنت الأشياء أو كل ما هو مطلوب مع الحفاظ على مبادئ التصميم والميزات التي يتم تنفيذها حاليًا على WF. وبهذه الطريقة ، نجعل عملية الترحيل من XAML (على سبيل المثال) إلى تعريفات سير العمل المستندة إلى Json هي عملية صغيرة جدًا وبدون احتكاك. يجب نقل جميع الأنشطة الحالية إلى النموذج الجديد.

أنا لا أطلب منك بناء فريق أو إشراك نفسك في منتج جديد. يمكن للمجتمع القيام بذلك كما يفعلون مع ASP.Net و Entity Framework. اجعله إطارًا خارجيًا ومساعدًا ، وليس مضمنًا في جوهره.

شكرا

jimcarley سيتم تجميع التعبيرات بنفس الطريقة التي هي عليها اليوم على XAML. في أحد تدفقات العمل لدينا لدينا هذا (يمكن أن يكون 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 لكن المبدأ هو نفسه. لديهم متغير مخطط $ أعلى القالب الذي يوجه بنية المستند ، خطوات عملية النشر التي يمكننا القيام بها كأنشطة. التصميم مشابه جدًا لـ WF ولكن هذا DSL يركز على نشر مجموعة الموارد. يمكننا أن نجعلها أكثر عمومية ، وأن نستخدم الأنشطة بنفس الطريقة التي يستخدمونها في تطبيق WF الحالي.

إذا قررت يا رفاق أن الأمر يستحق التصوير ، فيمكننا البدء في رسم بعض الوثائق حول مسألة أخرى والتي ستوجه بنية "WF الجديد". إذا كان الأمر يبدو جنونيًا جدًا وخرجت عن خططك ، فأعلمني بذلك ، فسنستمر في تطويره في نهايتنا لدعم .net core ، وإصداره لاحقًا باعتباره nuget للأشخاص. أحاول فقط جعل هذا الإطار الرائع مواكبًا للتقنيات الحالية (القادمة). هذا هو حقا حاجة عمل بالنسبة لنا. نحن نعتمد كثيرًا على WF ، ولكن إذا لم يصبح أسرع ومدعومًا على coreCLR ، فسنحتاج إلى البدء في إعداد إطار العمل الجديد هذا ، لذلك عندما يكون NanoServer + coreCLR هو RTM ، يمكننا التحرك من أجله.

يرجى إعلامي إذا كان لديك أي أسئلة.

شكرا

ملاحظة: أنا على قنوات gitter كل يوم إذا كنت بحاجة إلى الدردشة.

galvesribeiro إذن أنت تستخدم TextExpressionCompiler لتجميع التعبيرات بعد إنشاء كائن النشاط من تعريف سير العمل المخزن في JSON. حق؟

jimcarley ليس لدينا حتى الآن مترجم التعبير. ما زلنا نصممه باستخدام نفس مبادئ TextExpressionCompiler ولكن نعم ، يبدو أنه نفس المفهوم. يبدو أن عمليات التنفيذ الحالية مرتبطة بـ System.XAML حتى الآن. نظرًا لأنه ليس مفتوحًا ، لا يمكنني تأكيد ما إذا كان سيعمل بنفس الطريقة (داخليًا) مثل TextExpressionCompiler ولكن نعم ، بعد تحميل النشاط ، يجب علينا تقييم / ترجمة التعبيرات (إذا لم تكن موجودة بالفعل في ذاكرة التخزين المؤقت) وكشف كائن Expression يتم تقييمه من قبل مستهلكي النشاط (إذا لزم الأمر).

في العام الماضي ، قمت ببعض الأعمال على جانب التعبير لتمكين دعم تعبير C # في مصممي WF المستضافين ذاتيًا. كان يعتمد على أجزاء من nrefactory و roslyn. يمكنني البحث عنها إذا كان أي شخص مهتم.

galvesribeiro بعد التفكير أكثر في نهج json الخاص بك ، أعتقد في النهاية أنه لن يكون مهمًا حقًا للتطوير الجديد. إذا لم يفتح MS دعم xaml ، فقد ينجح ذلك.

zhenlan أتفق مع galvesribeiro في أننا لا نبحث بالضرورة عن MS لتشكيل فريق لمنفذ WF. هذا بالتأكيد شيء يمكن أن يفعله المجتمع بتوجيه من فريقك ، وما إلى ذلك.

jakesays أتفق معك في أن التخزين لا يهم في الواقع إذا كنا ننشئ WF مرة أخرى لـ coreclr.

النقطة المهمة هي ، لماذا تستمر في استخدام XML بدلاً من Json نظرًا لأن لدينا العديد من الاختبارات حول الويب لمقارنة أداء التسلسل (de) لكليهما و json أسرع بكثير ويستهلك موارد أقل منه؟ (على سبيل المثال مقارنة Newtonsoft's Json.Net مع مُسلسل XML عادي) إذا تم تشغيل WF على جهاز عميل صغير الحجم (أي إنترنت الأشياء) ، فإن كل بايت ذاكرة مهمة.

أيضًا ، مع json ، هو أسهل كثيرًا للحصول على مصممي WF على الويب على الفور. ليس من الصعب تنفيذ تجميع التعبير وتنفيذه. هو تقريبا محلل من السلسلة لبناء كائن التعبير. الجزء الصعب (imho) ، هو التعرف على VS للأنواع المستخدمة أثناء تصميم WF ، لكنني متأكد تمامًا من أن Roselyn والخدمات اللغوية يمكن أن تساعدنا في ذلك وأن VS لديها بنية تحتية لها.

galvesribeiro ، لقد ذكرت أنك قمت بالفعل ببناء محرك سير العمل الخاص بك باستخدام تعريف سير العمل المستند إلى JSON والتسلسل. إذا تم نقل WF إلى Core ، فهل ستستخدمه بالفعل؟

dmetzgar بدأنا في تطويره واختباره كإثبات للمفهوم يمكننا تحقيق نتيجة أفضل في WF أكثر نظافة مع عدم وجود أي اعتمادات تقريبًا على إطار العمل ، وهو أمر جيد لجعله يعمل على coreclr. ليس لدينا استعداد.

أود ألا أضطر إلى إنشاء محرك خاص بي والاستمرار في استخدام WF حتى إذا كان يعتمد على XAML ولكن تم نقله إلى coreclr وإذا كان يتبع نفس مفهوم إصدارات coreclr من EntityFramework و ASP.Net على سبيل المثال (لا تعتمد على مكتبات الخادم ويعمل في كل مكان).

النقطة المهمة هي أنه إذا كان لا يزال يعتمد على XAML وعلى ملف تعريف الخادم ، فسيظل بطيئًا (يتطلب الكثير من الموارد) ، ومحدودًا على خيارات المصمم ، وما إلى ذلك.

اقتراحي هو نقله إلى coreclr باستخدام Json ، وإزالة الكثير من التبعيات الموجودة به اليوم مما يترك المستخدم قادرًا على تشغيله في أي مكان يريده بنفس الطريقة التي يمكنك بها تشغيل ASP.Net vNext على جهاز IoT ARM (قريبًا بمجرد دعم ARM انتهى!) ولا تقلق بشأن التبعيات والاستهلاك الكبير للموارد.

تم إنشاء جميع مهام سير العمل لدينا اليوم بالإصدار الحالي مع كتابة بعضها برمز خالص والبعض الآخر باستخدام XAML buth في كلتا الحالتين ، لا يزال لدينا تبعيات.

IMHO ، قم بنقله إلى coreclr كما هو ، لا يجلب الكثير من الفوائد ما لم يأتي شخص ما بمحرك فائق الوزن خفيف الوزن لتحليل / عرض XAML / XML لكل من وقت التشغيل ووقت التصميم. ولكن إذا قررت يا رفاق النقل كما هو ، فسوف نستمر في استخدامه على أي حال ، لأنه سيجعل مهام سير عمل XAML الخاصة بي تعمل (آمل) من اليوم 0 ، حتى لو كنت أعلم أنه لن يجلب أي فوائد عملية ...

مرة أخرى ، يمكنني (ربما jakesays ومستخدمي WF الآخرين) أن أساعد في هذا المنفذ بطريقتين (XAML أو JSON) بغض النظر عنكم يا رفاق. أريد فقط التأكد من أن هذا المنفذ ليس مجرد نسخ ولصق وإصلاح لتشغيله ، وبدلاً من ذلك ، فإنه يجلب فوائد حقًا للأشخاص الذين يستخدمونه باتباع نفس فكرة coreclr ويمكن تشغيله في كل مكان دون نقاط الألم.

شكرا

galvesribeiro أوافق على أن XAML مدمج بإحكام شديد في WF. بالعودة إلى كتاب دارما الأصلي حول سير العمل ، كان لديه عينة أنشأت سير عمل من Visio. على الأقل مع النقل إلى النواة ، يمكننا تقسيمه بحيث يكون وقت التشغيل منفصلاً عن XAML. يسمح لنا ذلك بالمتابعة مع أو بدون نقل فريق XAML إلى المركز ويمكننا دائمًا إضافة دعم سير عمل XAML لاحقًا كمشروع GitHub / حزمة NuGet منفصلة. أنا بالتأكيد جميعًا من أجل إتاحة إمكانية تحديد مهام سير العمل بأي تنسيق والاستمرار فيها. شكرا ، هذه التعليقات مفيدة.

dmetzgar ليس لدي شك في أنه في يوم من الأيام سيتم نقل XAML إلى النواة ... إذا تم تشغيل .net core على هاتف windows أو أي جهاز محمول يعمل بنظام windows 10 ، فسيحدث ذلك في وقت ما وأنا أتفق معك تمامًا على أنه يمكننا البناء نواة جديدة ، وإضافة الإصرار على كل من التعريفات وحالة سير العمل لاحقًا أيضًا.

إذن ، ما الذي يتعين علينا القيام به لبدء نقله؟ (لقد وقعنا بالفعل اتفاقية المساهم ولدينا اتفاقيات عدم إفشاء أخرى كشركة مع MS ، إلخ)

شكرا

galvesribeiro أقدر الحماس! بقدر ما هو مغري لفتح GitHub repo والبدء في القرصنة ، فهناك بضع خطوات متضمنة. أيضًا ، ليس System.Xaml فقط هو الذي يجب اقتطاعه. هناك تبعيات أخرى متأصلة بعمق في WF مثل System.Transactions وبعض المكونات المشتركة مع WCF. نحن نبحث في كل من هؤلاء.

اني اتفهم. حسنًا ، لا أريد أن أدفعكم يا رفاق ، أنا فقط قلق بشأن الوقت. لدينا قرار نتخذه الآن للمضي قدمًا في البناء بمفردنا ، أو الانضمام إلى المجتمع هنا ونقل WF إلى coreCLR حتى يتمكن من تلبية الجدول الزمني الخاص بنا لمنتجنا.

dmetzgar هل فكرت في نشر الأجزاء التي يمكن فتحها الآن على https://github.com/Microsoft/referencesource؟ أعتقد أن هذا يمكن أن يكون أبسط بكثير من إنشاء مشروع كامل مفتوح المصدر يعمل بالفعل.

بهذه الطريقة ، يمكنك أن تأخذ وقتك مع الإصدار المناسب ، ويمكن للآخرين إنشاء إصداراتهم الجزئية / المخصصة في غضون ذلك.

تم بالفعل نشر مكونات svick WF في .NET بالكامل على مراجع جيثب منذ فترة. على سبيل المثال ، يمكنك العثور على https://github.com/Microsoft/referencesource/tree/master/System .

zhenlan نعم ، المشكلة في ذلك هي أن بعض التبعيات ليست "قابلة للحل" ... لا أستطيع أن أرى ما هو سلوك بعض الفئات بشكل صحيح ، بسبب اعتمادها على System.Xaml غير العام ...

يمكننا دائمًا معرفة ذلك بنهايتنا ، لكن هذا يعني أننا لا نعرف على وجه اليقين ما إذا كنا نتبع نفس الطريقة.

dmetzgar System. المعاملة شيء غير مفتوح (حتى الآن؟) ، لكن أعتقد أنه يمكننا التعامل معه (في الوقت الحالي). فيما يتعلق بـ WCF ، تظهر لي شجرة التبعية فقط الأنشطة ومضيف خدمات سير العمل. لا شيء في جوهر (IIRC) يعتمد على WCF ...

galvesribeiro الوضع مع System.Transactions أكثر تعقيدًا من ذلك. يتم رشه طوال وقت تشغيل WF ويعتمد بشكل كبير على التثبيت الدائم ، حيث توجد الفئات الأساسية للمثابرة. تم دمج WCF و WF في نفس الفريق حول الإطار الزمني الصافي 4.0 لذلك لدينا أشياء مثل System.ServiceModel.Internals يستخدمها كل من WCF و WF. .Net core يحتوي على الكثير من الأشياء الكبيرة ، ولكن هناك الكثير من الأشياء المفقودة. قد يتطلب العمل على القطع المفقودة تغييرات في التصميم أو إعادة كتابة الميزات.

لا يمكن التغلب على أي من هذه المشاكل ، ولا أريد التقليل من أهمية الجهود. ينطبق هذا على الكود وكل ما يدور حوله مثل الحصول على الموافقة القانونية ، وبناء البيئات ، واختبار البنية التحتية ، وما إلى ذلك. نريد بالتأكيد من المجتمع المساعدة ونحن نعمل على تحقيق ذلك. ما إذا كان يجب عليك كتابة المنفذ الخاص بك أو انتظار المنفذ "الرسمي" يعتمد على الإطار الزمني الخاص بك. يعد تشغيل مهام سير العمل على خادم Nano أحد أكبر السيناريوهات لدينا وأود أن أحصل على مساعدتك في ذلك.

dmetzgar لقد فهمت ، دائمًا ما كان لدي بعض التأخير عندما كان يجب إعادة توجيه أي سؤال إلى العلاقات العامة أو الشؤون القانونية عندما أكون بجانبك :)

حسنًا ، إذا كان لدينا على الأقل فكرة عن إطار زمني معين ، فيمكننا تحضير أنفسنا وانتظارها. أنا أكره فكرة عدم تنفيذ شيء ما في "المكان الخطأ" أو عندما تكون هناك بالفعل بعض الجهود التي يتم إنفاقها في مكان ما يمكننا توحيد قواها للقيام بعمل أفضل.

يرجى إعلامي إذا كان هناك أي شيء يمكننا القيام به ، أو إذا كان لديك أي أخبار ، أو اتصل بي إذا كنت بحاجة إلى أي اقتراح بخصوص التصميم / المنفذ.

شكرا

مع زيادة وضوح الإطار الزمني ، سأقوم بإجراء تحديثات على هذا الموضوع. سأكون سعيدًا لسماع السيناريوهات الأخرى التي يهتم بها الناس. WF on Nano هو السيناريو الأساسي في الوقت الحالي ، ولكن سيكون من الجيد معرفة ما يفعله الآخرون.

مرحبًا يا شباب ، بالإضافة إلى XAML و JSON ، هناك طريقة رائعة لتأليف الأنشطة: البرمجة الوصفية. ألق نظرة على مشروعي التجريبي: Metah.W: A Workflow Metaprogramming Language (https://github.com/knat/Metah).

jakesays هل يمكنك تقديم بعض الإرشادات حول كيفية تمكين دعم تعبير C # في WF المستضاف ذاتيًا.

من فضلك احتفظ Xaml. :) كائنات JSON المتسلسلة ستكون مثيرة للاهتمام أيضًا. لكنني أفضل أن أرى مقدمي الخدمة الذين تم تكوينهم بطريقة ما في إطار العمل لاختيار التنسيق المفضل.

dmetzgar (وأشخاص آخرين من MSFT) هل هناك أي أخبار بخصوص هذا الموضوع؟
شكرا

لقد عملنا على هذا الأمر وحققنا الكثير من التقدم. XAML غير متوفر حاليًا في Core لذلك نحن نركز على وقت التشغيل. نحن نبحث في الانفتاح على المسلسلات الأخرى. لذا بدلاً من اختيار الجوانب بين JSON أو XAML ، نفضل السماح لك بإحضار جهاز التسلسل الخاص بك. لا يزال هناك المزيد من الامتثال والأشياء القانونية للموافقة عليها. نظرًا لعدم قيام الكثير من العملاء بالضغط من أجل هذا المنفذ ، فقد كان له أولوية أقل.

dmetzgar الحلو! سأكون أكثر من سعيد للمساهمة فيه ولكن يمكنني ذلك إذا أصبح هذا مشروعًا أساسيًا ... سواء كان ذلك مصممًا لسير عمل الويب وما إلى ذلك. يبدو أن xaml لا يحتاج إلى أن يكون موجودًا لتنسيق التعريف ... متحمس للاستماع عن هذا العمل!

مرحبا شباب ، عيد ميلاد سعيد وسنة جديدة سعيدة!

إذن ، هل لدينا أي تحديث على هذا المنفذ أو على الأقل إصدار OSS للعمل الحالي حتى نتمكن من المساعدة في ذلك؟

شكرا

galvesribeiro سأحاول شرح الوضع بأفضل ما أستطيع. في حماستي للحصول على WF إلى .NET Core ، فشلت في مراعاة الجانب التجاري من هذا الأمر برمته. لا يتم نقل WPF / XAML إلى .NET Core وهذا يمثل جزءًا كبيرًا من WF. على الرغم من أن XAML ليس ضروريًا لوقت التشغيل ، فهو الطريقة التي يبني بها معظم العملاء مهام سير العمل. هذا يحد من الجمهور الذي قد يجد WF on Core مفيدًا. أحد المخاوف هو إطلاقنا WF على Core وليس هناك الكثير من مشاركة المجتمع. هذا يضيف إلى تكلفة الدعم لدينا ولا يحسن الوضع بالنسبة لمعظم عملاء WF. في حين أنه من الرائع رؤية WF يعمل على جهاز Linux ، فمن الصعب إثبات أن أي شخص سيستخدمه بالفعل.

أنا على علم بـ OmniXAML وتمكنا من إقناع المؤلف بالتغيير إلى ترخيص MIT. لذلك من خلال بعض الاستثمار ، يمكننا تشغيل XAML. ولكن لا يزال هناك سؤال حول كيف يفيد ذلك عملاء WF الحاليين. إذا جاء عميل كبير مثل SharePoint أو Dynamics في يوم من الأيام وقال إنه ينتقل إلى Nano ، فعندئذ سيكون لدينا حالة مقنعة. هذا كل ما في الأمر إذا قرر فريق .NET Framework إنشاء حزمة يمكنها تشغيل إطار العمل الكامل على Nano.

إذا كان هناك ما يكفي من اهتمام المجتمع وكان هناك شخص ما على استعداد لدعم المشروع ، فيمكننا محاولة القيام بذلك بهذه الطريقة. نوع من مثل Open Live Writer. الجزء الصعب هناك هو أنه بينما سيساهم فريقي في هذا قدر الإمكان ، فإن هذا النوع من المشاريع لن يأتي بدعم Microsoft. أظن أن معظم عملاء WF يستخدمون WF بشكل أساسي لأن Microsoft تدعمه.

أعتقد أنه من المهم إبراز أن .NET Core و .NET Framework الكامل هما منتجان مختلفان. .NET Framework لا يحتضر بأي حال من الأحوال. سنستمر في دعمه وإضافة ميزات وما إلى ذلك. لذا فليس الأمر كما لو كان يتعين علينا نقل WF إلى .NET Core من أجل إبقائه على قيد الحياة. سيكون WF on Core منتجًا جديدًا بشكل أساسي. من الصعب التوصل إلى تبرير عمل قوي. قد تكون حتى مسألة توقيت. نظرًا لأن المزيد من الشركات تستخدم خوادم Nano ، فقد تكون هناك حالة أقوى.

dmetzgar ماذا عن Portable.Xaml ، هل يمكن أن يكون بديلاً؟ https://github.com/cwensley/Portable.Xaml تم استخراجه للاستخدام من قبل مؤلف مشروع Eto.Forms الرائع لـ Eto. وهي مرخصة من معهد ماساتشوستس للتكنولوجيا (وكذلك مكتبات الفصل التي تشتق منها في المشروع الأحادي).

dmetzgar ،

سأحاول شرح الموقف بأفضل ما أستطيع. في حماستي للحصول على WF إلى .NET Core ، فشلت في مراعاة الجانب التجاري من هذا الأمر برمته. لا يتم نقل WPF / XAML إلى .NET Core وهذا يمثل جزءًا كبيرًا من WF. على الرغم من أن XAML ليس ضروريًا لوقت التشغيل ، فهو الطريقة التي يبني بها معظم العملاء مهام سير العمل. هذا يحد من الجمهور الذي قد يجد WF on Core مفيدًا. أحد المخاوف هو إطلاقنا WF على Core وليس هناك الكثير من مشاركة المجتمع. هذا يضيف إلى تكلفة الدعم لدينا ولا يحسن الوضع بالنسبة لمعظم عملاء WF. في حين أنه من الرائع رؤية WF يعمل على جهاز Linux ، فمن الصعب إثبات أن أي شخص سيستخدمه بالفعل.

أعتقد أن الدافع الأكبر لمستخدمي WF الحاليين هو Nano server و Micro Services وليس Linux. سيضيف Linux المزيد من المستخدمين ، لكن ليس هذا هو الدافع الحقيقي.

ولكن لا يزال هناك سؤال حول كيف يفيد ذلك عملاء WF الحاليين.

نحن في أيام السحاب. تذكر ، "السحابة أولاً ، الجوّال أولاً ..." وأحد أهم التقنيات التي تنمو هي الحاويات ، وخدمات Micro ، وعرضًا كبيرًا من MS لكل ما هو Nano Server.

إذا جاء عميل كبير مثل SharePoint أو Dynamics في يوم من الأيام وقال إنه ينتقل إلى Nano ، فعندئذ سيكون لدينا حالة مقنعة.

حتى مع وجود أكبر نشر لـ Sharepoint أو Dynamics على الأرض ، فلن نصل أبدًا إلى نفس العدد من المستخدمين ، بل ويمكنني أن أقول نفس مستوى الإيرادات ، مقارنة بالمستوى الذي يتم إجراؤه باستخدام تقنية السحابة.

هذا كل ما في الأمر إذا قرر فريق .NET Framework إنشاء حزمة يمكنها تشغيل إطار العمل الكامل على Nano.

لا يتألف DNX اليوم (بقدر RC1) من CoreCLR فقط. يحتوي على إطار العمل الكامل أيضًا (dnx451) حتى نتمكن حاليًا من استخدام WF على DNX ولا يتعلق الأمر بالمشكلة هنا. نحن نتحدث عن coreCLR (dnxcore50)

إذا كان هناك ما يكفي من اهتمام المجتمع وكان هناك شخص ما على استعداد لدعم المشروع ، فيمكننا محاولة القيام بذلك بهذه الطريقة. نوع من مثل Open Live Writer.

لن أقارنه بما تم إنشاؤه في Open Live Writer ... أعتقد أن هذا هو إلى حد ما ما تم إنشاؤه باستخدام ASP.Net و MVC و Entity Framework. "المنتجات" الأساسية من عائلة .Net وهذا اليوم مفتوح المصدر.

الجزء الصعب هناك هو أنه بينما سيساهم فريقي في هذا قدر الإمكان ، فإن هذا النوع من المشاريع لن يأتي بدعم Microsoft. أظن أن معظم عملاء WF يستخدمون WF بشكل أساسي لأن Microsoft تدعمه.

في الواقع ، يستخدم عملاء WF عقود دعم MS ... خاصة عملاء Dynamics و Sharepoint يفعلون ذلك ، ومع ذلك ، هناك الكثير من التطبيقات خارج هذا العالم والتي لا تزال تتطلب الدعم. إن القول بأن الأشخاص يستخدمونه فقط بسبب الدعم وأن OSS غير مدعوم ، يكاد يكون هو نفسه القول بأن CoreCLR و EF و ASP.Net لن يحظى بدعم من MS. على الرغم من أن هذه المشاريع أصبحت الآن برمجيات المصدر المفتوح ، إلا أنها تخضع للمراقبة الشديدة والإشراف من قبل فرق MS.

على سبيل المثال ، بدأت كمستخدم في مشروع MS Orleans. تعمل على تشغيل جميع خدمات Halo السحابية لمدة 7 سنوات تقريبًا. Skype و Outlook والعديد من خدمات MS العامة / السحابية الأخرى تستفيد منها بطريقة ما. قبل بضع سنوات ، كان OSSed من MS Research ويتم صيانته الآن بواسطة 343 Studios ، وبعض الأشخاص من MSR ، والبعض الآخر من مجموعات أخرى داخل MS ولكن في الغالب يحتفظ بها المجتمع. واليوم ، أعتبر نفسي مساهمًا نشطًا في هذا المشروع وأدعم المستخدم الجديد جنبًا إلى جنب مع الأشخاص الآخرين الذين ليس لديهم MS وغير MS هناك. لدينا حتى أشخاص سابقون (مثلي) وغير موظفين داخل فريق GH في أورليانز. هل هذا يعني أنه ليس لدينا دعم؟ حسنًا ، لم أشتري أورليانز ، لذا أطلب دعمًا قانونيًا داخل عقدي مع MS for Orleans على وجه التحديد ، ومع ذلك ، يمكنني فعل ذلك من خلال استهداف إطار عمل .Net أو أي منتج آخر مرتبط بذلك ، فأنا لا أوافق حقًا على بيانك.

من الصعب التوصل إلى تبرير عمل قوي.
أتفق معك إذا كنت تبحث فقط عن عملاء Sharepoint و Dynamics.

حسنًا ، نحن ، مثل العديد من الشركات الأخرى حول العالم ، نحافظ على اتفاقيات مؤسسة كبيرة (EA) مع Microsoft باستخدام معظم المنتجات المتغيرة في تلك العقود. في حالتنا ، نقوم بمعالجة الملايين من المعاملات المالية (بطاقة الائتمان / الخصم) يوميًا ، وتمثل كل واحدة مثيلًا واحدًا من WF يعمل فوق أورليانز وداخل Microsoft Azure. لا أعرف ما هو الحجم الكبير بالنسبة لك لكي تكون بمثابة تبرير تجاري.

أعتقد فقط أن جوهر (System.Activities) ، بدون XAML ، يمكن نقله إلى coreCLR ويمكن إنشاء المصممين عند الطلب لـ XAML ، Json ، HTML ، XML ، أي شيء. من خلال فصل هذه التبعية ، يتم فتح إمكانيات أخرى.

كما قلت في بداية هذا الموضوع ، فإن العمل الشاق الذي نريده الآن هو الحصول عليه OSSed وإتاحة شخص ما (على الأقل في البداية) من MSFT لمراجعة العلاقات العامة. الحس السليم هنا هو إعادة كتابة WF وليس فقط نسخه وتجاوزه لـ coreCLR لذلك نتوقع مساهمات كبيرة في ذلك.

إذا كان هذا شيئًا لن يحدث ، أعتقد أنه يمكننا إغلاق هذه المشكلة وسيبدأ الأشخاص على الأقل في البحث عن OSS أخرى أو حتى محركات سير العمل المدفوعة التي ستحصل في النهاية على دعم CoreCLR. أنا فقط أعتقد أنها خسارة كبيرة لا تملكها داخل CoreCLR ...

يمكنني أن أعطي سببًا قويًا للغاية لضرورة تحويل WF إلى NET Core.

تقوم Microsoft بتوجيه المطورين نحو منصة UWP. ستكون UWP منصة Windows للمستقبل. لا علاقة له بالفكرة الخيالية المتمثلة في نقل التطبيقات إلى Linux وما إلى ذلك. هناك حاجة ماسة إلى تشغيل WF على أجهزة Windows 10 ، و UWP هو مستقبل نظام التشغيل Windows 10.

نبني تطبيقات متصلة أحيانًا. لدينا نهاية خلفية .Net وواجهة أمامية UWP. حاليًا ، تتم مشاركة كل منطق الأعمال عبر .Net و UWP. لكننا نرغب في إدخال التعليمات البرمجية لمنطق الأعمال في WF. سيعمل هذا بشكل جيد في .Net ، لكن WF غير مدعوم حاليًا بواسطة UWP ، لذلك يتم جعل WF عديم الفائدة لأنه ما لم يكن المستخدم متصلاً بالإنترنت ، فلن يتمكن من إجراء مكالمات يتم التحقق من صحتها بواسطة منطق WF.

يحتوي UPW على XamlReader ، لذا فإن تحليل XAML ليس بالأمر المهم حقًا ...

أتفق معك MelbourneDeveloper مع جميع الأسباب ، ولكن ضع في اعتبارك أن UWP و .Net Core (على الأقل الآن) ليسوا تحت نفس اللقب ، مما يعني أنه حتى أنهم يشاركون نفس واجهات برمجة التطبيقات ذات المستوى الأدنى ، ولديهم نفس سطح API (و. Net Core هو OSS بينما UWP ليس كذلك) ، فهما ليسا نفس الشيء وغير متوافقين. بمعنى آخر ، لا يمكنك إضافة تجميع .Net Core إلى أحد أنظمة UWP. ستتخلص هذه الاختلافات (IMHO) في النهاية ، لكنها لا تزال موجودة في الوقت الحالي ...

نعم. مفهوم. كان مع افتراض العمل أنه سيتم الجمع بين هذين الأمرين في المستقبل. إذا لم يكونوا كذلك ، أعاننا الله!

أيضًا Xaml الخاص بـMelbourneDeveloper UWP هو إصدار مختلف تمامًا ومختلط من .NET's Xaml. يتخلل برنامج UserVoice الخاص بـ WindowsDev (ما لا يزال يتم تجاهله ، كما هو الحال مع كل شيء UWP على ما يبدو - فلا عجب لماذا لديهم حتى UserVoice لتبدأ به) أصوات لتحسين نظام 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

نأمل أن يفعلوا الشيء الصحيح ويتجمعون خلف منفذ Mono Xamlcwensley و / أو OmniXaml كما هو مقترح. يعد نظام Xaml الخاص بـ UWP بشكله الحالي مزحة حقًا وهو جزء من سبب كون معدل اعتماده فظيعًا للغاية.

إلى جانب هذه الملاحظة ، لدي حالة استخدام عمل لـ MSFTies للنظر فيها: NodeJS. كلما طالت مدة خدشنا جميعًا في مكاسبنا الجماعية بشأن هذه المشكلة ، زادت القيمة المتراكمة لـ NodeJS في السوق ، حيث إنها حقًا منصة متعددة الوجود في كل مكان حقًا ، وهو أمر لا تستطيع تقنية MSFT المطالبة به في الوقت الحالي (أو في المستقبل المنظور). يعمل NodeJS على الخادم والعميل (كلهم) ويتيح إعادة استخدام الكود بين الاثنين. سيعمل أحد قواعد الكود في سيناريوهات أصلية (عبر كوردوفا) وشبكة الويب (عبر مستعرض HTML5 القياسي) ، وهو أرخص بكثير مما قد يتعين عليك فعله باستخدام حل قائم على MSFT.

سيصل قريبًا إلى النقطة التي مفادها أن إعادة إنشاء نظام في NodeJS والتخلي عن MSFT تمامًا سيصبح أكثر قبولا (ومن الواضح أنه أقل تكلفة) من انتظار (ما يشبه) فرق مختلة لمواكبة الحقائق الاقتصادية للسوق.

أذكر هذا أيضًا كما ورد أنه يبدو أن MSFT تعتمد على UWP لمنصة عملائها ، لكنها تصل إلى جزء بسيط من السوق الذي تقوم به NodeJS. وعندما أقول كسر ، قد يكون ذلك مبالغا فيه. نحن نتحدث عن 200 مليون (آخر عدد تثبيت معروف لنظام التشغيل Windows 10) مقابل حوالي 3 مليار (مليار) من الأجهزة التي يمكن أن تصل إليها التطبيقات المستندة إلى nodejs.

لا تفهموني خطأ هنا ، أنا أحب MSFT. لقد استثمرت أكثر من 15 عامًا من حياتي بتقنياتها وأنا مستثمر بالكامل هنا شخصيًا. ومع ذلك ، يأتي مع هذا الاستثمار الشغف لرؤية الجميع على النحو الصحيح وأن نفخر بالقرارات والجهود المبذولة هنا مع العصر الجديد من المصادر المفتوحة والذهول عبر الأنظمة الأساسية. أريد أيضًا أن يكون الجميع على دراية بتهديد السوق الذي يلوح في الأفق (وربما أيضًا للتحقق / تأكيد مخاوفي).

أخيرًا ، إذا سارت الأمور على ما يرام ، فلدينا مشكلة كبيرة أخرى مع الوضع الحالي الخاص بنا عبر النظام الأساسي Xaml ، مثل Portable.Xaml يختلف عن OmniXaml ، لذلك في مرحلة ما ، سيتعين علينا كمجتمع معرفة كيفية التوفيق بين الاثنين قواعد التعليمات البرمجية ... من الناحية المثالية. :)

@ Michael-DST أتفق معك في جميع النقاط. أحد الأهداف التي نريد تشغيل WF لتحقيقها هي العملاء (خاصة الأجهزة المحمولة والمدمجة). نريد تقليل رمز العميل لقواعد الأعمال المحلية عن طريق إضافة WF عليه. من خلال العملاء ، لا أتحدث بدقة عن UWP مثل أجهزة Windows (الهاتف والأجهزة اللوحية وإنترنت الأشياء) ...

أعتقد أن هناك منتجات رئيسية تعتمد على WF مثل BizTalk و Sharepoint ولكن لا يزال بإمكانهم الاعتماد على الإصدار الكامل من .Net بينما يمكن للأشخاص الذين يستخدمون .Net Core (ولاحقًا UWP) الاعتماد على واجهات برمجة تطبيقات WF / XAML الجديدة تمامًا. أعلم أنه سيتضمن الكثير من #ifs حول مصدر الشفرة ، ولكن هذا سيكون السبيل للذهاب ...

galvesribeiro شكرًا لك على التحقق / الدعم. يبدو الأمر وكأنني أتزلج صعودًا في بعض الأحيان حيث لا يبدو أن أحدًا يدرك هذه المشكلة الحقيقية (الوجودية؟) التي تواجه .NET. في الواقع ، تساعد قيادة .NET في تفاقم هذه المشكلة من خلال التوصية بإقران .NET مع AngularJS لتطبيقات الويب ، حيث تجرؤ المؤسسات بشكل أساسي على التبديل إلى NodeJS تمامًا! (الإفصاح الكامل كتبت ذلك.: ع).

أتردد في نشر الكثير هنا بخصوص NodeJS ، حيث أن WF هي أكثر من مجرد تقنية من جانب الخادم ، ولكن الطريقة التي أراها (والمؤسسات الأخرى) تؤثر على جميع المجالات وتهدد .NET في جميع المجالات. إنه ببساطة أكثر فعالية من حيث التكلفة (وكفاءة في الوصول إلى السوق) لاستخدام NodeJS كمكدس حلول في الوقت الحالي ونحن (مرة أخرى ، أكره أن أكرر نفسي - ولكن ليس في الحقيقة) نرى هذا ينعكس في المؤسسات بسبب التكنولوجيا التي يختارونها.

الخلاصة: يجب أن أضع قلقي في مكان ما وهذا الخيط هو الضحية. : P #sorrynotsorry

بخصوص #if defs ... yuck ، سأقتبس بيان MvvMCross هنا: "# للتويتر ، وليس الكود." : ص

أخيرًا ، لقد نسيت وضع علامة على SuperJMN لأنه يجب أن يكون على دراية بهذا الموضوع / المناقشة أيضًا (مثل مؤلف OmniXaml) - لا يقصد عدم الاحترام ، يا صاح! سأقوم بمعالجة مشكلة OmniXaml مقابل Portable.Xaml شخصيًا في الأسبوع المقبل أو نحو ذلك.

@ Michael-DST نعم ... في الواقع ، #if هو مجرد طريقة واحدة ... اتخذ فريق Net Core نهج "Native Shims" حيث يتم تجريد التنفيذ الحقيقي (الخاص بنظام التشغيل) على طبقة سفلية رفيعة من الكود الأصلي. في حالة WF ، يمكن أن يكون رقاقة لـ .Net Full وآخر لـ .Net Core على سبيل المثال ...

لست من محبي Node.js ولا جافا سكريبت (أميل إلى الاعتقاد بأنها لا تزال لغة برمجة ، وليست لغة برمجة ولكن هذا هو اختياري الخاص بي) ، لكن يجب أن أوافق على أنه في الوقت الحاضر ، لا يوجد شيء يقارن بها من حيث xplat. تستخدمه Microsoft نفسها لوكلاء البناء الخاصين بها على VSTS (فقط لتسمية حالة واحدة ، هناك آخرون على MS) حيث يتم تشغيلها على أي نظام أساسي على سبيل المثال ...

أعتقد أن WF هي قطعة رائعة من التكنولوجيا التي كان من المفترض أن تكون النسخة الحالية مستخدمين على جانب الخادم ، ومع ذلك ، مع .Net Core ، ويمكنها تمامًا على العملاء أيضًا ...

galvesribeiro ... أنا معك 100٪. EF Core 1.0 هي نفسها ... تقنية تقليدية من جانب الخادم يمكن استخدامها الآن من جانب العميل أيضًا. سيكون من السهل جدًا توفير WF بهذه الطريقة أيضًا.

أيضا ، من الجيد أن نسمع عن الحشوات. الكثير من الموافقة. :)

أخيرًا ، لا أريد إخراج سلسلة الرسائل عن مسارها / اختطافها (كثيرًا) هنا ، ولكن للتأكد من إعادة: JavaScript: أنا موافق كلغة برمجة نصية. ومع ذلك ، فهي أيضًا "لغة" مرنة جدًا يمكن استخدامها في أشكال أخرى ، وعلى الأخص كود البايت (ish). كما أنا متأكد من أنك رأيت ، هناك سحر مترجم LVVM متاح لـ C ++. السؤال المتزايد / الشائع في مجتمع مطوري .NET هو أن يفعل الشيء نفسه مع .NET (تحويل .NET إلى JS على أساس رسمي). هذا من شأنه أن يصحح حقًا جميع الشرور (الرئيسية) الحالية في مناخ مطور MSFT الحالي.

على أي حال ، عد إلى البرمجة المجدولة المنتظمة. : ف شكرا للحوار والأفكار!

أنتم يا رفاق تتطرقون إلى بعض الأشياء التي كنت أتعامل معها منذ 9 سنوات. هناك شيء لا يدركه الكثير من الأشخاص الذين يعملون مع تقنيات Microsoft ؛ وهي مفهوم الحوسبة الموزعة. من المتطلبات الأساسية لبرنامجنا منذ البداية أنه يعمل في وضع متصل أحيانًا. بمرور الوقت ، اتخذت Microsoft خطوات مختلفة في توفير الأدوات لذلك ، ولكن لم يتم تطوير إطار عمل شامل على الإطلاق. لدينا القليل من إطار عمل المزامنة هنا ، وقليلًا من قاعدة بيانات LINQ هناك ، ولكن لا توجد مجموعة أدوات شاملة لجعل كل شيء يعمل معًا.

على مدى السنوات التسع الماضية ، قمنا بتطوير إطار عمل خاص بنا متصل أحيانًا. يعمل الآن على .Net و Silverlight و UWP. لقد حاولنا جاهدين الاستفادة من أطر عمل Microsoft مثل EF و WF ، ولكن لم يتم تقديم أي دعم لهذه التقنيات على منصات تكنولوجيا العميل مثل Silverlight. لقد أنشأنا حرفيًا إطار عمل ORM الخاص بنا والمزامنة لـ Silverlight والذي يتوافق الآن مع UWP.

عندما كان هناك الكثير من الضجة حول WF في المقام الأول ، كان الأمر مثيرًا للغاية لأنه قدم طريقة لمنطق عمل الكود البرمجي بدون رمز. ولكن ، مع مرور الوقت ، أصبحت أقل ميلًا إلى التفكير في أنه سيكون هناك منفذ لتكنولوجيا جانب العميل مثل Silverlight. لقد قمت بنشر العديد من الأسئلة حول هذا الموضوع في المنتديات ، ولكن كانت الإجابة هي نفسها دائمًا: WF هي تقنية من جانب الخادم ، فلماذا تريد استخدامها في Silverlight؟

كما قال جالفيسريبيرو

"أعتقد أن WF هي قطعة تقنية رائعة كان من المفترض أن تكون النسخة الحالية مستخدمين على جانب الخادم ، ولكن مع .Net Core ، ويمكنها تمامًا على العملاء أيضًا ..."

و

"أحد الأهداف التي نريد تشغيل WF من أجلها هي العملاء (خاصة الأجهزة المحمولة والمضمنة). نريد تقليل رمز العميل لقواعد الأعمال المحلية عن طريق إضافة WF عليه. من خلال العملاء ، لا أتحدث بشكل صارم عن UWP مثل أجهزة Windows (الهاتف والأجهزة اللوحية وإنترنت الأشياء) "

ما يجب أن يفهمه الناس هو أنه عندما يتعلق الأمر بالحوسبة الموزعة ، لا يوجد تمييز بين تقنية العميل والخادم. فكر في طريقة عمل Git. رمز Git هو نفسه بغض النظر عما إذا كنت تبحث في الريبو المركزي أو عقدة على الشبكة في مكان ما. يتم تكرار الرمز في كل مكان. إنه نفس الشيء مع إطار عملنا. يتم تكرار منطق الأعمال على كافة العقد. هذا لأنه حتى إذا لم يكن المستخدم متصلاً بالشبكة ، فلا يزال يتعين عليه الخضوع لمنطق العمل نفسه. في الحوسبة الموزعة ، يكون كل كمبيوتر حرفياً خادمًا. يقوم حرفيا بتشغيل نفس رمز الخادم.

لم نتمكن أبدًا من الاستفادة من WF ، لأننا لم نتمكن من تشغيل كود WF في Silverlight ، والآن لا يمكننا تشغيله في UWP. إنه لمن المشجع رؤية EF يتم نقلها إلى UWP. ربما تكون هذه بداية فهم Microsoft أن الحوسبة الموزعة ضرورة. ولكن ، تحتاج Microsoft إلى الانضمام إلى الحوسبة الموزعة وتضمين WF كجزء من إطار عمل الحوسبة الموزع بالكامل. ربما بعد ذلك ، سنتمكن من حذف إطار عمل الحوسبة الموزعة ، ولن أضطر إلى الاحتفاظ بهذا الرمز بعد الآن.

منظور وأفكار رائعة حقًاMelbourneDeveloper. شكرا لمشاركتك معهم. كنت أيضًا من أشد المعجبين بسيلفرلايت وقد كنت أخدشها منذ ذلك الحين (ومن ثم تصويتي الناتج و- حقًا- الموقع أعلاه). أيضًا ، لدي فضول بشأن ما هو رأيك في Azure Mobile Services وما إذا كنت قد فكرت في استخدام ذلك في قصتك غير المتصلة بالإنترنت؟ أنا مبتدئ في الحوسبة الموزعة (لكن احفر ما لديك لتقوله) ، لكنني أتطلع حقًا للدخول فيه هذا العام المقبل (أسمع أيضًا الكثير من الخدمات المصغرة ، والتي أعتقد أنها أحدث ما يعادل هذا؟) .

ما يجب أن يفهمه الناس هو أنه عندما يتعلق الأمر بالحوسبة الموزعة ، لا يوجد تمييز بين تقنية العميل والخادم.

نقطة جيدة حقا. في هذه المرحلة ، يتعلق كل شيء بالمكان الذي تستضيف فيه التكنولوجيا. وهذا يعني أنك مقيد حقًا بمضيف التقنية التي تحاول "توزيعها" أود أن أقول (ومرة أخرى لست خبيرًا في هذا الأمر). المضيف الأكثر انتشارًا (أو متاحًا بسهولة) هو التطبيق الموزع / الذي يمكن الوصول إليه بشكل أفضل. Annnnnd .... أعتقد أنك تعرف إلى أين أنا ذاهب مع ذلك. : ص

على أي حال ، يبدو أننا جميعًا نطرح اتفاقًا حول _ شيء ما _ هنا مع هذه المناقشة وهذا تغيير / إنجاز مرحب به بالنسبة لي. ؛)

تضمين التغريدة

ضع في اعتبارك أن UWP و .Net Core (على الأقل الآن) ليسوا تحت نفس اللقب ، مما يعني أنه حتى أنهم يشاركون نفس واجهات برمجة التطبيقات ذات المستوى الأدنى ، ولديهم نفس سطح API (و .Net Core هو OSS بينما UWP ليس كذلك) ، فهما ليسا نفس الشيء وغير متوافقين. بمعنى آخر ، لا يمكنك إضافة تجميع .Net Core إلى أحد أنظمة UWP. ستتخلص هذه الاختلافات (IMHO) في النهاية ، لكنها لا تزال موجودة في الوقت الحالي ...

ألق نظرة على موقع العلاقات العامة dotnet / corefx # 5760 ، وآمل أن يوضح هذا بعض الأشياء.

الجانب .NET من UWP _is_ .NET Core. ومع ذلك ، يوفر .NET Core أوقات تشغيل متعددة. تستخدم UWP وقت التشغيل المستند إلى AOT ، لذلك لا يتم دعم بعض الوظائف التي تتطلب JIT (مثل LCG أو RefEmit). ومع ذلك ، فإنهم يشتركون في نفس التجميعات و (المضي قدمًا) في حزم NuGet نفسها. لقد صممنا المكدس خصيصًا للسماح بتجميعات الإحالة المرجعية (والحزم) من UWP و ASP.NET Core.

بالطبع ، هناك أدوات VS فوق هذا يسمى مكتبات الفئة المحمولة (PCL) التي تحاول مساعدتك في بناء مكتبات تعمل على مجموعة من الأنظمة الأساسية. هناك اختيارات شديدة يمكنك القيام بها في مربع حوار استهداف PCL والتي تؤدي جميعها إلى أن يكون النظام الثنائي لديك متوافقًا مع .NET Core. ومع ذلك ، نظرًا لأنه يتم تحديد قابلية النقل في VS من خلال النظر في الأنظمة الأساسية ، فلن تتمكن من الرجوع إلى PCL من تطبيق UWP ما لم يذكر PCL أنه يمكنه استهداف UWP. هذا السلوك حسب التصميم لأن الفكرة هي أن أدوات PCL تساعدك على عدم استخدام وظائف غير مدعومة عن طريق الخطأ في كل مكان حيث تحتاج إلى التشغيل. على العكس من ذلك ، يمكنك فقط الرجوع إلى PCLs من الأنظمة الأساسية التي تقول إنها تستهدفها.

نظرًا لأنك ذكرت الألقاب صراحةً ، فلنتحدث عن هذا لثانية أيضًا. تصميم اللقب (TFM) هو أنه يمثل كامل مساحة السطح. يوجد في أدواتنا لقبان:

• TargetPlatformMonikers (TPM)
• TargetFrameworkMoniker (TFM)

فكر في TFM على أنها تحدد مجمل مساحة السطح المُدارة ، والمضمنة في الصندوق ، بينما تمثل TPM نظام التشغيل الأساسي ، أي مجموعة واجهة برمجة التطبيقات التي يوفرها نظام التشغيل.

نظرًا لأننا صممنا .NET Core ليكون محمولًا على العديد من الأنظمة الأساسية ، فإن TFM التقليدي ليس له معنى كبير حقًا. لهذا السبب يوجد مفهوم جديد ، يسمى Standard Platform ، يسمى سابقًا الأجيال.

هل هذا يساعد؟

ومع ذلك ، فإنهم يشتركون في نفس التجميعات و (المضي قدمًا) في حزم NuGet نفسها.

تحتوي معظم التجميعات على نفس تطبيق DLL لتطبيق BINARY لكل من هدف NuGet 'netcore50' (تطبيق WIndows UWP Store) و 'dnxcore50' NuGet Target (ASP.NET v5 / ASP.NET Core 1.0).

ومع ذلك ، فإن بعض حزم NuGet مثل العديد من حزم مكتبة System.Net. * لها تطبيقات مختلفة لهدف 'netcore50' مقابل هدف 'dnxcore50'. على سبيل المثال ، تستخدم مكتبة System.Net.Http التي تحتوي على "netcore50" تطبيق WinRT Windows.Web.Http أسفله. يستخدم تنفيذ "dnxcore50" شيئًا آخر (WinHTTP الأصلي).

ومع ذلك ، فإن بعض حزم NuGet مثل العديد من حزم مكتبة System.Net. * لها تطبيقات مختلفة لهدف 'netcore50' مقابل هدف 'dnxcore50'

نعم ، كان يجب أن أذكر ذلك. الطريقة التي أرى بها ذلك هي أن حزمة NuGet توفر حاوية تسمح للمنتج بتوفير تطبيقات مختلفة لبيئات تنفيذ مختلفة بينما لا يحتاج المستهلكون إلى معرفة ذلك. وبهذا المعنى ، فإن حزم NuGet هي التجميعات الجديدة.

شكرًا لك terrajobst و davidsh على مشاركة هذا الشرح الأعمق ومسألة المرجع ولكن ، ما الخطأ في ما قلته بأن "تجميعًا واحدًا من منصة واحدة لا يمكن الرجوع إليه بواسطة أخرى"؟

الطريقة التي أرى بها ذلك هي أن حزمة NuGet توفر حاوية تسمح للمنتج بتوفير تطبيقات مختلفة لبيئات تنفيذ مختلفة بينما لا يحتاج المستهلكون إلى معرفة ذلك. وبهذا المعنى ، فإن حزم NuGet هي التجميعات الجديدة.

هذا المفهوم ليس جديدًا في الواقع ... يقوم الأشخاص بالفعل بإنشاء حزمة Nuget واحدة والتي لا تعدو كونها إشارة إلى مجموعة من الحزم الأخرى - ما يسمى "الحزم الوصفية". هناك عدة طرق لجعل PCL يعمل على العديد من الأنظمة الأساسية. أشهر استخدامات العديد من المكتبات الشعبية (مثل Newtonsoft's Json.Net) هي Bait and Switch حيث يكون لديك nuget بواجهة عامة (سطح API) وتجميع واحد لكل منصة محددة (التنفيذ الحقيقي لسطح API) والتي يمكن أن تحتوي على تبعيات مختلفة عن بعضها البعض وفي وقت التشغيل ، سيتم تحديد التجميع الصحيح لتلك المنصة. يتمثل الاختلاف الآن في أنه بدلاً من وجود عدة قطع صغيرة "داخل" حاوية كتلة واحدة حيث يجب أن تكون جميعها في نفس النظام الأساسي أو مجموعة واجهة واحدة يتم استخدامها للتو من قبل التطوير والتي ستتحول إلى واحدة محددة في وقت التشغيل ، لدينا مزيج منه! 1 nuget عبارة عن حاوية وفي نفس الوقت الواجهة العامة لجميع الشبكات المحددة الخاصة بالمنصة المرتبطة بها.

أعتقد أننا نتحدث نفس الشيء ، لقد عبرت عن نفسي بشكل سيء في المقام الأول: ابتسم:

على أي حال ، بالعودة إلى WF ... أعتقد أنه من المعروف أن الناس يريدون نقله إلى WF ليس فقط "يتسبب في جعله رائعًا" لتشغيله على لينكس أو على خادم نانو. يريد الناس استخدامه بطريقة خفيفة الوزن على العملاء أيضًا.

مرة أخرى ، أعتقد أن هناك عددًا كافيًا من الأشخاص من المجتمع يتجهون لإجراء هذا المنفذ ...

ملاحظة: بالنسبة لأولئك المهتمين بالحوسبة الموزعة (الحقيقية وليس قصة العميل غير المتصل بالإنترنت) ، يرجى إلقاء نظرة على مشروعنا الآخر في أورليانز والذي يعد في الواقع حالة استخدام جيدة لـ WF على .Net Core والذي يمكّن خدمات Microsoft الكبيرة اليوم مثل Skype ، Halo5 ، والتي أستخدمها شخصيًا كتقنيتي الأساسية لمنصة معالجة المعاملات المالية الخاصة بي والتي تعالج مليارات المعاملات بطريقة موزعة ...

تضمين التغريدة

ما الخطأ في ما قلته "لا يمكن الرجوع إلى تجميع واحد من منصة بواسطة أخرى"؟

ليس الأمر أن بيانك خاطئ ؛ إنه ليس صحيحًا أيضًا: ابتسم: في العادة ، لست من النوع الذي يحب أن يمارس لعبة nitpick ، ​​لكن ما طردني كان هذا الجزء:

بمعنى آخر ، لا يمكنك إضافة تجميع .Net Core إلى أحد أنظمة UWP.

أريد تجنب إعطاء الانطباع بأن UWP و .NET Core هما نظامان أساسيان مختلفان لـ .NET ، مثل .NET Framework و Silverlight. لقد قمنا بتصميم NET Core خصيصًا بحيث يمكنك تأليف تجميعات تعمل على جميع الأنظمة الأساسية. على سبيل المثال ، System.Collections.Immutable وجميع Roslyn تقريبًا عبارة عن تجميعات .NET Core ستعمل بشكل جيد في UWP أيضًا.

لإعادة الصياغة: هدفنا هو بناء منصة حيث يمكن للمكونات البسيطة القائمة على MSIL أن تستخدم حرفيًا نفس النظام الثنائي على جميع الأنظمة الأساسية القائمة على .NET Core. في الحالات التي لا يكون فيها ذلك ممكنًا ، على سبيل المثال ، بسبب التبعيات الأصلية أو عمليات التنفيذ المختلفة ، فإننا نفعل بالضبط ما وصفه بول بيتس ببلاغة مثل Bait and Switch PCLs : مساحة سطح محمولة ، وتطبيقات مختلفة لكل نظام أساسي ، و NuGet مثل الحاوية و محدد.

في عالم .NET Core ، لا تعد مكتبات System مميزة حقًا. يمكن لأي شخص استخدام نفس الأسلوب للتأكد من أن معظم المستهلكين لا يضطرون إلى نقل قاعدة الكود الخاصة بهم باستخدام توجيهات #if .

أعتقد أننا نتحدث نفس الشيء ، لقد عبرت عن نفسي بشكل سيء في المقام الأول: ابتسم:

أعتقد أننا أنشأنا عالماً يسهل فيه إرباك الناس - والذي يشملنا بشكل واضح: الابتسامة: لهذا السبب أحاول جاهدًا أن أكون دقيقًا بشأن كيفية بناء NET Core والمشكلات التي حاولنا حلها.

نعم كلامك صحيح. الانطباع هو ما يهم.

آمل أن نسمي يومًا ما .Net Core على UWP أيضًا حتى ينتهي هذا ... لذلك ، ما زلنا بحاجة إلى system.xaml

على الرغم من الارتباط ، أعتقد أن System.Xaml هو مكون منفصل يضيف قيمة في حد ذاته. لقد قدمت dotnet / corefx # 5766 لتتبع ذلك بشكل منفصل.

شكرا مايكل- DST

لدي فضول أيضًا بشأن ما هو رأيك في Azure Mobile Services (https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/) وإذا كنت قد فكرت في استخدام ذلك في قصتك غير المتصلة بالإنترنت؟

سؤال ممتاز. يطالب هذا بقليل من درس التاريخ حول تجربة شركتنا مع الحوسبة الموزعة المعروفة أيضًا بالتطبيقات المتصلة أحيانًا وكيف يرتبط ذلك بخدمات Azure Mobile Services والحوسبة الموزعة باستخدام تقنية Microsoft.

إذا لم ير الناس موقع الويب المذكور أعلاه ، فإنني أوصي بشدة بالنظر إليه. يحتوي على فيديو جيد عن Azure Mobile Services.

منذ حوالي 8 سنوات ، أنشأنا تطبيقًا لمنصة Windows Phone الأصلية. المدرسة القديمة ذات الإطار الصافي المضغوط. قد يسخر الناس من ذلك ، ولكن في بعض النقاط الرئيسية كانت هذه المنصة أكثر تقدمًا من منصة UWP الحالية فيما يتعلق بالتكنولوجيا المتصلة أحيانًا. على الرغم من أنه يبدو أن UWP تلحق بالركب. كانت مفاتيح نجاح التطبيقات المتصلة أحيانًا على هذا النظام الأساسي هي:

1) تطبيق كامل لقاعدة بيانات SQL (SQL Server CE)
2) تطبيق Sync Framework بين SQL Server (الخلفية) و SQL Server CE (الجهاز المحمول). كان هذا الإصدار 1 من Sync Framework.

كان هذا التطبيق ناجحًا. قمنا بكتابة طبقة بيانات فوق أعلى SQL CE و SQL Server تم نشرها على الخادم وتم نشرها على الأجهزة. كادت أن تصل إلى الحد الأقصى من الذاكرة لكنها عملت. كان العمال الميدانيون قادرين على التقاط البيانات في الميدان ، وتمت مزامنة البيانات مرة أخرى إلى قاعدة البيانات المركزية.

شعرنا بالرعب عندما تم إصدار Windows Phone 7 بسبب وجود مشكلة حرجة: جميع قواعد البيانات في السوق كانت قواعد بيانات غير SQL. تم تنفيذها في الغالب مع LINQ. لم يكن هذا متوافقًا مع طبقة البيانات الخاصة بنا ، ولم يكن EF موجودًا لـ Windows Phone 7. لذلك ، لم نتمكن من إنشاء إطار عمل غير متصل في بعض الأحيان لـ Windows Phone 7 على الرغم من أننا كنا قادرين على بناء حل كامل للأصل. منصة Windows Phone.

كان سيلفرلايت عاملا في تغيير قواعد اللعبة. مرة أخرى ، صادفنا قاعدة بيانات SQL كاملة. ولكن ، لم تقم Microsoft بتنفيذ إطار عمل المزامنة لـ Silverlight ، أو لقاعدة البيانات المضمنة المعنية. لذلك ، شرعنا في كتابة إطار عمل المزامنة الخاص بنا على غرار إطار عمل المزامنة الخاص بـ Microsoft. يعتمد إطار عمل مزامنة Microsoft على الطوابع الزمنية. هذا ما قمنا بتطبيقه في إطار عمل المزامنة الخاص بنا. مرة أخرى ، حققنا نجاحًا كاملاً مع Silverlight. كان العمال الميدانيون قادرين على إخراج أجهزة Windows اللوحية إلى الميدان ، والتقاط البيانات ، ثم مزامنتها مرة أخرى مع قاعدة البيانات المركزية. كانت المشكلة أن هذا لا يتوفر أبدًا للهواتف. نظام قاعدة البيانات الأساسي غير موجود لنظام التشغيل Windows Phone 7.

كما ذكرت سابقًا ، أردنا تطبيق منطق العمل مع WF ، ولكن تم التخلي عن Silverlight ولم يتحدث أحد حتى عن إمكانية نقل WF إلى Silverlight.

أخيرًا ، وصلنا إلى UWP. تمت كتابة غلاف لـ SQLite لـ UWP ، ومع بعض الاختراقات في الغلاف ، تمكنت من توسيع الواجهة باستخدام SQLite للسماح لنا بالعمل مرة أخرى مع قاعدة بيانات SQL كاملة. هذا يعني أن طبقة البيانات لدينا متوافقة معها. تعمل الآن طبقة البيانات وطبقات المزامنة على .Net و Silverlight و UWP ، مع SQL Server و SQLite ومنصة قاعدة بيانات أخرى غير مسماة.

اليوم هي المرة الأولى التي أرى فيها أي مزامنة تحدث مع تقنية Microsoft الخالصة بفضل Michael-DST. في الأساس ، يمكنني القول أن مزامنة Azure Mobile Services هي مجرد إعادة تسمية لـ Microsoft Sync Framework. يحتوي على واجهة API مختلفة قليلاً ، لكن الأساسيات هي نفس إطار عمل مزامنة Windows Phone الأصلي الذي استخدمناه لإجراء المزامنة للعمل منذ حوالي 8 سنوات. أستطيع أن أرى أنه يستخدم نفس حقلي الطابع الزمني لتتبع تغييرات البيانات. تم تقديم هذه في SQL Server كميزة أساسية في SQL Server 2008. يعمل إطار عمل المزامنة الخاص بنا بشكل أو بآخر بنفس طريقة إطار عمل مزامنة Microsoft.

لذا ، للإجابة على سؤال مايكل ، سأبحث في هذه التكنولوجيا. سأرى ما إذا كان يمكن أن يحل محل إطار عمل المزامنة الخاص بنا. أود التخلص منه والسماح لشخص آخر بالحفاظ عليه. بالنظر إلى أنهم قد ذكروا أنه سيدعم SQLite ، يبدو الأمر واعدًا لأنه يبدو أننا سنكون قادرين على اختراق غلاف SQLite لمواصلة استخدام قاعدة بيانات SQL الكاملة ، وبالتالي نكون قادرين على الاستمرار في استخدام طبقة البيانات الخاصة بنا. إذا كان الأمر كذلك ، فسيتم نقل رمز إطار المزامنة لأكثر من 5 سنوات إلى سلة المهملات.

على أي حال ، فإن النقطة المهمة هي أن Microsoft تبدو وكأنها تقر مرة أخرى بأهمية الحوسبة الموزعة. إذا كان الأمر مهمًا ، فيجب نقل WF إلى UWP. UWP هو المستقبل ، وبالتالي فهو أيضًا مستقبل الحوسبة الموزعة باستخدام تقنية Microsoft. يحتاج مستقبل التكنولوجيا الموزعة إلى WF.

في حين أنه مرتبط ، أعتقد أن System.Xaml هو مكون منفصل يضيف قيمة في حد ذاته. لقد قدمت dotnet / corefx # 5766 لتتبع ذلك بشكل منفصل.

شكرا جزيلا لكterrajobst! لا أتفق مع كل ما تنشره على الإنترنت / تويتر ، لكنني معجب جدًا بكيفية تسهيل الحوار والتواصل بين المطورين / المجتمع وسأوافق دائمًا على ذلك. :) هذا يعني حقًا الكثير بالنسبة لي شخصيًا لأنه يبدو أنه أكثر من عام من التزلج على المنحدرات للحصول على أي شيء من MSFT (ونعم ، أدرك أنه ليس التزامًا ولكن في هذه المرحلة أي شيء له معنى).

لذا ، للإجابة على سؤال مايكل ، سأبحث في هذه التكنولوجيا.

رائع MelbourneDeveloper ، يسعدني تقديم المساعدة! أشعر أن Azure لديها حقًا مقبض قوي في مجموعتهم. إلى جانب VSO / VSTS ، يستمعون حقًا إلى مطوريهم ويحصلون على * _lot * _ تم. في الواقع ، يبدو أن هذا هو الحال مع كل مجموعة في MSFT _ باستثناء _ لمجموعة UWP ، والتي لا يبدو أنها تفعل الكثير ولا يبدو أنها تفهم التكنولوجيا الخاصة بها (ودعنا لا ندخل حتى في تعريفهم لـ "Xaml").

نستخدم حاليًا WF للعديد من خدماتنا الأساسية ، ونقوم الآن بتوسيع استخدامنا بشكل أكبر لأن لدينا تجربة رائعة مع Workflow ووجود منطق أعمالنا في مثل هذا الشكل المرئي السهل الفهم.

مثل قال MelbourneDeveloper

على أي حال ، فإن النقطة المهمة هي أن Microsoft تبدو وكأنها تقر مرة أخرى بأهمية الحوسبة الموزعة. إذا كان الأمر مهمًا ، فيجب نقل WF إلى UWP. UWP هو المستقبل ، وبالتالي فهو أيضًا مستقبل الحوسبة الموزعة باستخدام تقنية Microsoft. يحتاج مستقبل التكنولوجيا الموزعة إلى WF.

لا تحظى WF بالتقدير الكافي من قِبل العديد من مطوري .NET لأنهم ربما لم يروا قيمتها في ذلك الوقت (لم أكن في الماضي ولكني الآن من أشد المعجبين بـ WF لأنني أدرك مدى قوتها be!) ولكن في عصر الحوسبة الموزعة ، يمكن الآن أكثر من أي وقت مضى أن يتألق WF وأتمنى أن يتم نقله في النهاية.

أعتقد أن هناك مساحة صغيرة للخلاف حول هذا الموضوع.

يقال بالتأكيد أن البرمجة التصريحية والمرئية مثل WF ليست فعالة مثل كتابة الكود. حتى أنني أميل إلى الموافقة. ولكن ، من المؤكد أن وجود WF كأداة في مجموعة الأدوات لتقريب نظام أساسي قابل للتكوين سيكون أمرًا جيدًا. يرغب العملاء * _DO * _ في رؤية سير العمل المرئي ، ومن المؤكد أن تمكين العملاء من تعديل سير العمل الخاص بهم أمر جيد.

حان الوقت لإنجاز هذا!

أعتقد أن هناك مساحة صغيرة للخلاف حول هذا الموضوع.

HahaMelbourneDeveloper هل قابلت مطور برامج من قبل؟ أم حقا الجنس البشري؟ ؛ ص

أنا شخصياً أشعر أن المصمم المرئي لـ WF والأدوات الحالية قد أساءت إلى XAML ، حيث أن الملفات المطولة بشكل مفرط التي تم إنشاؤها لسير عمل MSBuild قد أعطت حقًا اسمًا سيئًا لـ Xaml في هذا الصدد. هذا حقًا ما يقرنه المطورون بـ Xaml ("الملفات المتضخمة") وساعدوا في نشر الرحلة إلى ملفات JSON "الأبسط" وملفات الإنشاء "النصية". ناهيك عن العملية الغامضة والصعبة والمرهقة بأكملها (ما زلت لا أستطيع حتى أن أجعلها تعمل بشكل كامل في مشاريعي) حتى لإنشاء مشروع لعرض ملف Xaml لتبدأ به.

في الواقع ، عندما كانت طريقة عمل WF هي "الطريقة الصحيحة" طوال الوقت. كان مرضه الحقيقي في أدواته.

على هذا النحو ، إذا كانت أداة المصمم أكثر ودية (وربما قامت بعمل أفضل مع تسلسل الملفات بطريقة أكثر تنظيماً / مجمعة) ، فسيكون هذا ليس مشكلة (أو أقل من مشكلة).

أنا من أشد المعجبين بمسار هدف WF ، لكن يجب تشديده قليلاً ومعالجة أدواته وتحسينها. حقًا ، في نهاية المطاف ، تكون التقنية جيدة مثل أدواتها الداعمة - المصممين وجميعهم. كلما كانت الأدوات / المصممون أفضل ، كلما كان الوصول / الفهم أسهل كلما كانت التكنولوجيا أفضل ، كان الاعتماد أفضل.

أود بالتأكيد أن أرى WF يصبح أشبه بـ EF ويمكن الوصول إليه في أي سيناريو .NET ، وتحسين الأدوات لتسهيل ذلك بالضبط.

ما أفهمه هو أن إحدى الرؤى الأصلية لـ WF كانت دعم أنواع ملفات متعددة لسير العمل ، وليس فقط XAML. بشكل عام ، بخلاف بعض المراوغات هنا وهناك ، لم أواجه مشكلات مع XAML. لقد استغرق الأمر بعض الوقت فقط حتى ألتف حوله وأكون مرتاحًا لتحريره يدويًا عند الضرورة ، وأنا متأكد من أنه يمثل حاجزًا أمام دخول العديد من الأشخاص. لذلك ، بينما أعتقد أن XAML يحتاج إلى الصيانة من أجل التوافق مع الإصدارات السابقة (على المدى القصير على الأقل) ، فأنا أحب حقًا أن أرى أنواع ملفات سير العمل الأخرى تبدأ في التطور (مثل JSON). يمكنني رؤية بعض مساهمات المنتدى الرائعة على هذا الصعيد! (مهام سير العمل مكتوبة في Whitespace أي شخص؟: ابتسامة:)

@ Michael-DST أتفق معك تمامًا. كنت أنا وفريقي مؤخرًا نراجع إبداءات الإعجاب / عدم الإعجاب / الرغبات لـ Workflow وتقريبًا كل ما أردنا رؤيته يتحسن كان حول المصمم وليس بالضرورة WF الأساسي نفسه. أعتقد أن Microsoft قامت بعمل رائع مع ما أنشأته في WF وأعتقد أن بعض التحسينات وبعض الكرازة يمكننا أن نرى حياة جديدة تنفخ فيها. أعتقد أنها أداة تحتاج إلى الوجود وقد حصلت على الكثير من القيمة من WF وأريد أن أراها تستمر لفترة طويلة.

قامت مؤسستنا باستثمارات كبيرة في WF وهي الآن تقنية محورية لأعمالنا. نظرًا لالتزام MIcrosoft الأخير بفتح المصدر و .NET Core ، يبدو أن نقل WF هو أفضل خطوة تالية لهذه التقنية. نحن بحاجة إلى هذا!

لقد كان سير العمل أداة ذات فوائد عديدة لنا كمطورين داخل مؤسستنا. إذا كانت Microsoft ستوحد أطر عملها ، فسوف تجعل حياتنا أسهل أن يكون لدينا WF في إطار العمل الأساسي.

HahaMelbourneDeveloper هل قابلت مطور برامج من قبل؟ أم حقا الجنس البشري؟ ؛ ص

هاها ، أنا مطور برمجيات. الجنس البشري غير مهم بالنسبة لي.

مايكل- DST

أنا شخصياً أشعر أن المصمم المرئي لـ WF والأدوات الحالية قد أساءت إلى XAML ، حيث أن الملفات المطولة بشكل مفرط التي تم إنشاؤها لسير عمل MSBuild قد أعطت حقًا اسمًا سيئًا لـ Xaml في هذا الصدد. هذا حقًا ما يقرنه المطورون بـ Xaml ("الملفات المتضخمة") وقد ساعدوا في نشر الرحلة إلى ملفات JSON "الأبسط" وملفات الإنشاء "المبرمجة"

ربما أنت على حق. لكن ، أنا شخصياً أعتقد أن هناك الكثير من التركيز على Xaml هنا. عندما جربت WF (قبل أن أدرك أننا لا نستطيع استخدامه لأنه غير موجود في Silverlight) ، قمت ببناء تطبيق WPF. هذا التطبيق متصل بخدمات WCF لدينا وقام بتخزين Xaml لـ WF في جدول في قاعدة البيانات الخاصة بنا. هذه هي الطريقة التي حققنا بها التشفير الناعم لـ WF.

ولكن ، تم التلاعب بـ Xaml بالكامل باستخدام أداة المصمم WPF WF. المستخدم لم ير Xaml أبدًا. كان xaml غير ذي صلة بالمستخدم. فكر في الأمر مثل ترميز HTML خلف صفحة الويب. قد يكون معقدًا للغاية ، ولكن طالما أن المستخدم النهائي يحب صفحة الويب ، فلا يهم حقًا. أعتقد أنك إذا كنت تتلاعب بـ Xaml مباشرة كنص ، فأنت لا تستخدم WF بالطريقة المقصودة على أي حال ...

الجنس البشري غير مهم بالنسبة لي.

لطيف. ب)

ولكن ، تم التلاعب بـ Xaml بالكامل باستخدام أداة المصمم WPF WF. المستخدم لم ير Xaml أبدًا.

صيح. هذه هي بالضبط الطريقة التي يعمل بها MSBuild ويكرهها المستخدمون النهائيون بسبب حجم الملفات الكبيرة التي ينشئها (خاصة عند مقارنتها بملفات "البرامج النصية" البسيطة الأساسية والخطية جدًا). أنا أتفق معك على أن هذه مشكلة تتعلق بالأدوات / المصمم ، وأود أن أقول أيضًا أنه يمكن تحسين الأدوات / المصمم بشكل كبير باستخدام WF.

مثال على ذلك: منشورات المدونة ونسخ / لصق الكود (أو بالفعل ، نسخ / لصق _workflow_: ابتسامة :). كانت هناك عدة مرات قمت فيها ببعض البحث عبر الإنترنت عن WF ، وتعثرت في منشور مدونة لطيف أظهر بعض الخطوات التي يجب تنفيذها لوضع مكون سير عمل (على الأرجح لـ MSBuild). حسنًا ، من أجل القيام بذلك ، كان علي تكرار مجموعة من الخطوات. عادةً ما يكون الرمز متاحًا في منشور مدونة للترميز لنسخ / لصق بسيط. ليس الأمر كذلك مع WF. عليك القيام بذلك خطوة بخطوة حتى يظهر على جهازك بالضبط كيف يبدو في منشور المدونة. من الواضح أن هذا أمر ممل للغاية وعرضة للخطأ (ويشعر تمامًا وكأنه أخذ خطوة إلى الوراء ، من منظور C #).

المشكلة الأخرى التي واجهناها مع MSBuild هي حجم الملف ، ليس فقط بالبايت ولكن أيضًا في المصمم نفسه: كان من الصعب حقًا التنقل في سير عمل معقد. يبدو هذا كشيء يجب حسابه بطريقة شاملة للغاية (وبديهية).

أخيرًا ، أريد أن أختم شيئًا بشأن حجم الملف. لست متأكدًا مما إذا كنت على دراية بـ WordML و / أو MSFT Frontpage من الخلف في اليوم. لكنها ستنشئ HTML الأكثر تضخمًا في العالم. على الرغم من أن المستخدمين عمومًا لا يضعون أيديهم في الترميز الناتج ، إلا أنهم يحبون وضع أنوفهم فيه للتعرف على مدى "نظافتها". أول شيء ينظرون إليه هو الحجم الموجود على القرص ، ثم ثانيًا فتح الملف لمعرفة كيفية تنسيقه ، وما إلى ذلك.

مرة أخرى ، أنا أوافق على أن كيفية إنشاء هذه الملفات هي مشكلة أدوات / مصمم بشكل صارم ، لكن المطورين يشعرون بالفضول ويجب مراعاة ذلك أيضًا. :)

نعم. كل النقاط الجيدة. أعتقد أن المصمم سيحتاج إلى التنظيف حتى لا يقوم بإنشاء Xaml المطول.

من لديه بالفعل سلطة اتخاذ القرار بشأن ما إذا كان WF سيتم نقله إلى .Net Core أو UWP؟ هل الأمر يتعلق فقط ببعض المطورين الذين يكتبون الكود في مكان ما ، ثم يرسلون هذا التصحيح إلى مسؤولي ريبو .Net Core codebase؟ ما هي السياسة حول هذا؟ ألا يوجد فريق أساسي من المطورين يتأثرون بـ Microsoft؟ هل من موظفي Microsoft؟ ما زلت لا أحصل على الإعداد الكامل حقًا. من الذي يجب أن نقنعه؟

في الواقع MelbourneDeveloper فقط من خلال المشاركة في هذا الموضوع ، فأنت تساعد في جعل الحجة. هناك فريق في MS يمتلك WF ، وأنا حاليًا ، لكننا لا نتخذ قرارًا بإصدار WF على Core. علينا أن نجعل دراسة الجدوى. المناقشة هنا تساعدني على فعل ذلك.

من المثير للإعجاب حقًا كيف بدأ الناس عام 2016 بدعم هذا الموضوع :)

كما أن https://github.com/dotnet/corefx/issues/5766 من terrajobst أصبح أكثر انشغالًا هذه الأيام :)

dmetzgar ، آمل أن تحصل على أكبر قدر ممكن من التعليقات / تحتاجها من تلك المناقشة حتى يكون لديك حالات كافية من أجل OSS.

أنا متأكد تمامًا من أنه إذا تم فتح dotnet / WF repo إذا تمت إضافته إلى corefx ، فسيقوم الأشخاص بتثبيته بسرعة كبيرة.

في الواقع MelbourneDeveloper فقط من خلال المشاركة في هذا الموضوع ، فأنت تساعد في جعل الحجة

هذا يجعلني أشعر بالدفء والغموض.

فقط لمعلوماتك dmetzgar - أنا أكثر من سعيد لتوثيق تجاربنا وتقديم حالة مقنعة إلى الأمام للمساعدة في بناء أدلة لحالة أعمال الميناء.

لقد تعمقت في تقنية Microsoft منذ عام 2000. لقد شاهدت جميع التقنيات الرئيسية ذات الصلة بهذا الموضوع تتطور وتتلاشى. بينما أنا منغمس في تقنية Microsoft ، ما زلت أراها من وجهة نظر موضوعية وأعتقد أن WF هي واحدة من التقنيات الرئيسية التي من شأنها أن تساعد في تطوير شراء الأعمال / الحكومة إلى منصات .Net Core و Windows UWP.

لا شيء يجعل العميل أكثر حماسًا من المخططات الانسيابية! لا شئ!

يجب أن أقول أيضًا إن تقنية Microsoft على أعتاب شيء كبير.

لسنوات عديدة ، كنت أشاهد التكنولوجيا الجيدة وهي ترتفع وتنخفض. السبب الرئيسي وراء تراجع التكنولوجيا عن الطريق هو بسبب مشهد الجهاز المتغير. في الماضي ، كانت الإستراتيجية هي بناء منصة لكل عائلة من الأجهزة. لم يكن هناك أي خطأ بطبيعته في هذا النهج. ولكن ، هذا يعني نقل التقنيات بين المنصات. هذا أمر مرهق ، وليس من غير المألوف أن تسقط التقنيات على جانب الطريق لأن المنصة تصبح فجأة غير مستساغة (سعال - سيلفرلايت).

تتخلف Microsoft الآن عن .Net Core و UWP. على الرغم من أنني أعتقد أن هذين النظامين يجب أن يكونا واحدًا واحدًا ، إلا أنني ما زلت متفائلًا جدًا أنه عند إنشاء تقنية معينة أو صيانتها ، فإنها ستعمل عبر العديد من الأنظمة الأساسية. Xamarin يعزز تفاؤلي.

يبدو حقًا أنه لأول مرة في التاريخ ، قد نحدق تمامًا في مجموعة من التقنيات التي تعمل عبر نطاق واسع جدًا من وحدات المعالجة المركزية وبيئات التشغيل. إذا ضغطت Microsoft على هذا الأمر بقوة ، فسيكون WF جزءًا من ذلك.

هذا يجعلني أشعر بالدفء والغموض.

: +1: على ذلكMelbourneDeveloper و @ dmetzgar . هذا هو نوع المشاركة والحوار الذي أحب أن أراه شخصيًا من MSFT ، بدلاً من المناشدات التي تم تجاهلها والنداءات التي لم يتم الرد عليها من قاعدتها المتحمسة ( وهذا يعني فقط ، أي الرجل اللئيم ).

جانبا عشوائي هنا: بالنسبة لي من وجهة نظري ، فإن NodeJS هو حالة العمل / التهديد الوحيد الذي تحتاجه ، لقد تحدثت عن مقالة عشوائية مؤخرًا .

أخيرًا ، إلى وجهة نظري "إذا كان NET Core جيدًا بما يكفي لـ EF ، فيجب أن يكون جيدًا بما يكفي لـ WF" ... إذا انتقل WF إلى .NET Core ، فهل هناك طريقة ما لدمجها مع EF بحيث تخدم EF كخلفية لها بطريقة أو بأخرى؟ هذه حالة مقنعة هناك ، إذا كان الأمر كذلك. إذا لم يكن الأمر كذلك ، فلا يزال يستحق التفكير (انظر: المناقشة / الحوار / العصف الذهني / إلخ). :)

أخيرًا ، إلى وجهة نظري "إذا كان NET Core جيدًا بما يكفي لـ EF ، فيجب أن يكون جيدًا بما يكفي لـ WF" ... إذا انتقل WF إلى .NET Core ، فهل هناك طريقة ما لدمجها مع EF بحيث تخدم EF كخلفية لها بطريقة أو بأخرى؟ هذه حالة مقنعة هناك ، إذا كان الأمر كذلك. إذا لم يكن الأمر كذلك ، فلا يزال يستحق التفكير (انظر: المناقشة / الحوار / العصف الذهني / إلخ). :)

هذه فكرة مثيرة للاهتمام. ما هي حالة استخدامك لدمج EF و WF؟ يمكنك ان تعطي مثالا؟ هل هذا للإصرار؟

يمكنك ان تعطي مثالا؟ هل هذا للإصرار؟

على أقل تقدير يمكن استخدامه كنموذج دعم يعمل به سير العمل في مجال التطبيق. على الأكثر يمكن أن تعمل كآلية تخزين لسير العمل نفسه (لكنني لا أوصي بهذا - Xaml أكثر ملاءمة لذلك).

يمكنني رؤية نموذج WPF-esque هنا حيث يمكنك تحديد مهام سير العمل في Xaml ثم ربطها بخصائص عناصر سير العمل ، باستخدام بيانات من كيانات النموذج التي تم تحديدها وتعديلها وتخزينها في EF.

منحت ، تجربتي مع W / WF محدودة هنا (أولئك الذين لديهم خبرة واسعة قد يتناغمون هنا). ولكن ، إذا كان يعمل مع WPF ، فقد يعمل مع WF. في الواقع ، أنا أستخدم هذا النموذج نفسه (أي التطوير المستند إلى WPF-esque Xaml) لتطبيق وحدة التحكم الذي أستخدمه لمشروعي الحالي . من المؤكد أنه لا يستخدم روابط البيانات كما أقترح (حتى الآن) ، ولكن يتم إنتاجها بسهولة ، كما أوضحنا OmniXaml / Perspex. :نظارة شمسيه:

@ Michael-DST أفضل تجنب عمليات تكامل كثيرة. يجب أن يكون WF حزمة NuGet قائمة بذاتها. يجب أن يكون دمج WF و EF معًا مشروعًا منفصلاً. ابدأ في الجمع بين العديد من الأشياء وقد ينتهي بك الأمر مع أوسلو .

أتفق مع dmetzgar : +1:

إي أف هو مزود التخزين / الاستمرارية. يجب أن تكون حزمة NuGet مختلفة ويتم حقنها في وقت التشغيل. يجب أن يوفر WF مجموعة من الواجهات فقط وهذا كل شيء.

لقد فعلنا ذلك بشكل جيد مع موفري التخزين في Microsoft Orleans.

وافقdmetzgar (وgalvesribeiro). أنا لا أقترح تكاملًا مطلوبًا ، ولكن اقترح حالة استخدام / قيمة محتملة. (انظر: العصف الذهني.: ابتسم :)

ما هي حالة استخدامك لدمج EF و WF؟ يمكنك ان تعطي مثالا؟ هل هذا للإصرار؟

أريد أن أتجاذب أطراف الحديث مع هذا! مرة أخرى ، هذا يتعلق بتجربة شركتي. في النهاية ، نود استخدام EF لاستمرار البيانات في قواعد البيانات المضمنة مثل SQLite للتطبيقات المتصلة أحيانًا. في النهاية ، UWP / .Net Core ستعمل كل من EF و SQLite و Azure Mobile Services و WF في وئام. سأكرر نفسي إذا شرحت سبب رغبتنا في حدوث ذلك ، لكن يمكنني شرح سبب عمل EF و WF معًا بشكل جيد. على الرغم من أننا وجدنا قيدًا واحدًا في EF أوقفنا في مساراتنا في الماضي - وهذا هو السبب الآخر الذي دفعنا إلى إنشاء ORM الخاص بنا.

لدينا نظام يؤدي فيه الوصول إلى البيانات إلى تشغيل أحداث مثل "BeforeLoad" و "BeforeSave" وما إلى ذلك. نترك الخطافات في هذه الأحداث بحيث عندما يتم حفظ نوع سجل معين ، يمكننا وضع منطق عمل مخصص هناك. حاليًا ، قمنا بذلك عن طريق ربط مكتبات DLL الخاصة بمنطق الأعمال المخصص. كل عميل لديه مجموعة خاصة به من الأحداث المخصصة. قمنا أيضًا بتنفيذ مكالمات إلى WF. لذلك ، على سبيل المثال في حدث BeforeSave ، يمكننا إجراء بعض التحقق من الصحة من خلال إجراء مكالمة إلى WF للتحقق من صحة الحقول الإلزامية. بهذه الطريقة ، تم ترميز منطق التحقق بطريقة ناعمة لعميل معين. على المدى الطويل ، كان علينا التخلي عن WF لهذا الغرض لأنه لم يتم تنفيذه مطلقًا على Silverlight ، ولكن كان من الجيد وجوده هناك كخيار.

على أي حال ، أشعر أن هذا مطلب عالمي إلى حد ما لأي تطبيق. بشكل عام ، ستحتاج دائمًا إلى طبقة أعلى طبقة البيانات مباشرةً والتي تتحقق من صحة البيانات التي تدخل إلى قاعدة البيانات ، أو تقوم بعمل منطق عمل عام. على سبيل المثال ، لدينا منطق عمل لبعض العملاء الذين يرسلون رسائل بريد إلكتروني عند إضافة سجل من نوع معين إلى قاعدة البيانات. يمكن القيام بذلك في WF. سيكون من الرائع تنفيذ شيء مثل هذا مع عمل EF و WF بانسجام.

للأسف ، لم أجد أبدًا طريقة للقيام بذلك مع EF حتى على .Net. المشكلة التي وجدتها ، هي أن EF لا تخبرك عندما يكون سجل من نوع معين على وشك أن يتم حفظه. على سبيل المثال ، إذا قمت بإنشاء كائن "Task" جديد واستمرت في ذلك إلى قاعدة البيانات باستخدام EF ، فلا يوجد حدث تم إطلاقه بواسطة EF يحتوي على شيء مثل "RecordInserted". سيسمح لنا هذا ببناء روابط في الوصول إلى البيانات بحيث يمكن إدراج الأعمال المخصصة. لذلك ، هذا أحد الأسباب التي تجعلنا لا نذهب أبدًا مع EF. إنه لأمر مؤسف لأن بناء ORM الخاص بنا استغرق سنوات لتحسينه.

التحدث إلى "دراسة الجدوى" لـ NodeJS: كيف تهيمن NodeJS على .NET في 3 مخططات سهلة

بصبر انتظار ذلك GitHub repo. أدركت للتو أن WF لم يتم نقله إلى .NET Core مما أدى إلى حد كبير إلى القضاء على قابليته للتطبيق على منتجنا. وهو أمر مؤسف لأننا نحب التغييرات القادمة إلى ASP.NET الأساسي والنظام الأساسي الشامل بالكامل ، والمخفف ، والفكرة المعيارية لـ .NET Core ولكننا نحتاج إلى WF لأنه أساس منتجنا بالكامل.

أعتقد أنني بصراحة لا أهتم حقًا إذا كان هذا هو WWF ، أو إذا كان محرك سير عمل آخر مدعوم جيدًا ، لكنني أعتقد أنه لأغراض التمديد ، قد يكون سير العمل من نوع ما ضخمًا للغاية.

+1

استخدمنا التوليد الديناميكي (استنادًا إلى القواعد الخارجية المستوردة) وتحميل مهام سير العمل كخدمات WCF. سيكون رائعًا لو تمكنا من استخدام مثل هذا النموذج في .net core!
راجع للشغل - ما هي مشكلة استيراد التجميعات الكاملة .Net؟ إذا كان معظمه رمز IL ، فلماذا لا يعمل في .net core؟

+1

dmetzgar من المثير للغاية رؤية https://github.com/dmetzgar/corewf! من الملف التمهيدي ، فوجئت برؤية منفذ من قبل فريق WF لم يكتسب الكثير من الجذب. لا سيما بالنظر إلى منفذ Powershell الأخير الذي يحتوي على Powershell Workflow والذي سيقتصر على الإطار الكامل - من الواضح أن Linux و Mac ليسا هدفًا رئيسيًا ، لكن خادم Nano أتخيل أنه مهم للغاية لـ Powershell. يذكر أيضًا أنك تستكشف بدائل لـ XAML ، فهل يتضمن ذلك تطبيقات Xaml الأخرى مثل Portable.Xaml على سبيل المثال يدعم بالفعل الملف الشخصي 259 المتوافق مع CoreCLR؟

watertree Portable.Xaml وتطبيقات XAML الأخرى مع دعم .NET Core الذي رأيته حتى الآن جميعها بها ميزة مفقودة. إنهم لا يطبقون سمة x: Class = "". إنه غير ضروري لـ WPF ولكنه مهم لـ WF. يحتوي سير عمل XAML عادةً على

يحتوي PowerShell Workflow على طريقة رائعة حقًا لتحديد مهام سير العمل في البرنامج النصي. إنه أنظف بكثير من كتابة نفس الشيء بلغة XAML أو C #. ومع ذلك ، يحول PSWF هذا البرنامج النصي إلى ملف XAML خلف الكواليس. لكي يعمل PSWF على Nano ، سيتعين عليهم استبدال خط الأنابيب الحالي ووقت تشغيل WF بحيث لا يستخدم XAML. ولا يوجد ضغط كافٍ من العملاء للحصول على PSWF على Nano.

فيما يتعلق ببدائل XAML ، لدي الكثير من الآراء حول هذا الموضوع. مشكلتي مع XAML هي أنه مضمن في WF. مع إصدار WF القديم في .NET 3.5 ، كان هناك المزيد من التشجيع من فريق WF لتحويل أي تنسيق تريده إلى سير عمل. استخدموا مثال تحويل الرسوم التخطيطية في Visio إلى مهام سير عمل. ولكن عندما وصل WF الجديد في 4.0 ، كان كل شيء يركز على XAML. هل سبق لك أن حاولت كتابة سير عمل في XAML يدويًا؟ لم يحدث. ثم هناك رموز التصحيح و حالة العرض. وحاول مقارنة إصدار واحد من XAML بآخر باستخدام أداة فرق.

أعتقد حقًا أن استخدام XAML لتحديد مهام سير العمل يجب أن يكون مسألة تضمين حزمة NuGet. يجب تشجيع إنشاء وسائل أخرى لتخزين تعريفات سير العمل. ربما تحتاج إلى شيء ينضغط جيدًا. ربما تحتاج إلى الأمان وتسمح فقط بمجموعة محدودة من الأنشطة. أنا أفضل وجود خيارات.

إنهم لا يطبقون سمة x: Class = ""

في الواقع ، كان Xaml المترجم (baml؟) غائبًا بشكل واضح في جميع نكهات Xaml التي رأيتها. لقد فكرت في الغوص في هذا مع وقت فراغي الخاص ، لكن لدي شعور بأنه سيكون متاحًا في بعض الحالات قريبًا ، ربما في العام المقبل. أيضًا ، يدعم نظام Xamarin الخاص بـ Xamarin هذا ، ولكنه مغلق وغير قابل للتوسيع / ​​يمكن الوصول إليه على الإطلاق.

هل سبق لك أن حاولت كتابة سير عمل في XAML يدويًا؟ لم يحدث.

صحيح. ومن المفارقات أن WF هو المستفيد الأكثر شمولاً (إلى حد بعيد) لأي تكامل Xaml. ربما لخطأ. إنه لأمر مخز أن Xaml تم تصميمه ليكون صديقًا للغاية للمصمم ، ومع ذلك فإن الأدوات حول WF تعتبر باهظة بعض الشيء للسيناريوهات المكتوبة بخط اليد ، وحتى بالنسبة للمصمم نفسه. يبدو أنهم يهدفون حقًا إلى جعلها لغة برمجة مرئية ، ولكن بدون قدر كبير من الدعم / الموارد التي ستحتاجها لتحقيق النجاح.

أعتقد حقًا أن استخدام XAML لتحديد مهام سير العمل يجب أن يكون مسألة تضمين حزمة NuGet.

أنا أحب كيف تفكر! 👍

راجع للشغل ، إذا لم تكن قد فعلت ذلك بعد ، فالرجاء الانتقال إلى طلب / مشكلة منفذ System.Xaml والتصويت على المشكلة إذا استطعت. أرغب حقًا في رؤية نظام Xaml جديد مفتوح المصدر ومتعدد المنصات يأخذ أفضل الأنظمة المعروفة ويقدمها كنكهة رسمية وموثوقة. ألن يكون ذلك لطيفًا؟ 😛

على أي حال ، ما يصل إلى 74 صوتًا الآن. وهو أمر رائع بالنظر إلى أن التصويت بدأ قبل توفر ردود فعل GitHub:
https://github.com/dotnet/corefx/issues/5766

17 قلوب رائعة أيضًا. :)

شكرًا لك على أي دعم (وردود الفعل المستمرة)!

dmetzgar أشكركم على جهودكم! مجرد تعليق على XAML - اعتدت أن يكون لدي عرض سلبي للغاية لـ XAML لأن معظم الملفات التي تعاملت معها تم إنشاؤها باستخدام اللهجات المرئية الأولى للمصمم من XAML.

تغير كل ذلك عندما بدأت البرمجة باستخدام Xamarin.Forms التي تحتوي على واجهة برمجة تطبيقات C # توضيحية لطيفة جدًا بالإضافة إلى XAML. لا يوجد مصمم بصري (فقط عارض جاء بعد إصدار XF بكثير). من المثير للدهشة أنني أفضل العمل على لهجة XAML الخاصة بهم بدلاً من كود C #! لقد قاموا بعمل رائع ، وليس لديك الكثير من البيانات الوصفية الخاصة بالمصمم التي تلوث معنى الترميز. تساعد أطر العمل الداعمة مثل Prism.Forms أيضًا في قلب المقاييس بشكل كبير نحو XAML أيضًا لأنها تساعد في كتابة التعليمات البرمجية دون وجود رمز خلفها بسهولة بالغة.

لذلك لا أعتقد أن XAML في حد ذاته هي المشكلة ، لكن اللهجات المصممة لدعم المصممين أولاً - XF هي دليل مقنع جدًا بالنسبة لي.

أي تحديث في هذا الموضوع؟

حسنًا ، CoreWF حي وموجود على https://github.com/dmetzgar/corewf

يجب أن نرى ما إذا كان من الممكن الآن نقل DynamicActivity مع واجهات برمجة التطبيقات الجديدة الخاصة بالتكوين المضافة إلى Core و .net القياسي 2.0.

سيكون رائعا إذا سمعنا من فريق WF.

كان هناك العديد من التعليقات الشيقة والمفيدة حول هذا الموضوع. من ناحيتي ، أعتقد أن هناك قيمة في وقت تشغيل WF فقط وتتبع الأحداث (أي بدون XAML أو المعاملات أو بتات WCF) يتم نقلها إلى .NET Core ويسعدني أن هذا (نوعًا ما) تم القيام به.

أوافق على أن WF.Core يجب أن يكون موجودًا رسميًا. إذا كانت هناك القدرة على إنشاء طريقة أكثر مرونة لتحديد مهام سير العمل التي تناسب المطورين ، فأنا أعتقد أن هذا سيكون أفضل نهج. أوافق على أن XAML من الصعب كسرها إذا قالت MS إنها لن تقوم بمنفذ System.XAML ، لكنني أريد حقًا رؤية WF.Core في مشاريع .NET Core Web API الخاصة بي.

أعتقد أن الفيل الضخم في الغرفة هنا هو أنه لا يوجد ما يكفي من الجر لإطلاق هذا المشروع لأن MS وآخرون كانوا متشددون للغاية بشأن أي معلومات حول WF. من المؤكد أن هناك بعض العينات على MSDN ، ولكن هناك القليل جدًا من المعلومات في شكل كتب أو مواد صلبة أخرى (تم فحصها).

أنا بالتأكيد على استعداد لتخصيص الوقت للمساعدة في تحقيق ذلك.

لذا يجب أن يدعم OmniXAMLv2 (الموجود على فرع في مستودع جيثب) ، والذي لا يزال قيد التطوير ، سمات x: Class (https://github.com/SuperJMN/OmniXAML/issues/12). ربما يمكننا استخدامه لـ (الأساسية) WF؟

ewinnington شكرا لتوضيح ذلك!
هذا بالتأكيد جزء كبير منه. أيضًا ، يحتوي .NET Standard 2.0 على مجموعة من أنواع System.ComponentModel التي يستخدمها WF. النظام: المعاملات موجودة بالفعل في corefx. الشيء الوحيد المفقود هو WCF ServiceHost.

يمكن لمضيف خدمة WCF الانتظار IMHO. يجب أن يكون نموذج الاستضافة محايدًا تمامًا مثل أي شيء آخر في عالم Net Core / Asp.Net على ما أعتقد ...

galvesribeiro أتفق مع هذا ، نظرًا لوجود العديد من الطرق الأخرى التي يمكن أن يعمل بها WF في عالم .NET Core ، بما في ذلك Web API.

نعم. ومع ذلك ، أتفق مع dmetzgar على أن هناك مجموعة من العملاء يستخدمون WCF اليوم ، لذا فإن دعمه أمر لا بد منه ولكن مرة أخرى ، يمكن أن يتأخر ...

في الواقع ، يجب استخلاص الاستضافة و "لغة التصميم" من وقت التشغيل الأساسي ...

نحن نستخدم WCF مع WF ولكننا سننتقل إلى شيء مثل WebAPI إذا كان WF في Core. في الواقع ، كنا نمضي قدمًا وننتقل من WCF إلى بديل مريح بغض النظر. نحصل على طن من القيمة من Workflow وهو من تقنيات .NET المفضلة لدي!

أعتقد أيضًا أن WF في النواة لا يجب أن يعتمد على xaml أو wcf ، فمجرد امتلاك محرك wf ونموذج كائن سيكون ذا قيمة فائقة. يمكنك بعد ذلك تشغيل ذلك كبرنامج وسيط على نواة asp.net ، خاصةً مع عمل خط الأنابيب الجديد / غير http الذي يأتي إلى kestrel.

+1 لوجود ودعم محرك WF ونموذج الكائن في Core. يمكننا العمل حول XAML و WCF أيضًا.

XAML رائع - يتيح لك إجراء تكوين ديناميكي - في مشروع واحد نقوم بتحميل مهام سير عمل xaml من الملفات ويتم تمثيلها كنقاط نهاية WCF. ويتم إنشاء ملفات XAML هذه تلقائيًا من سجل الخدمات المتاحة. لذلك تحصل خدمات wcf على endponts:
https: // [base] / wcf / [service_id1]
https: // [base] / wcf / [service_id2] ...
سيكون من الجيد الحصول على هذه الوظيفة في. net core :)
أوه ... لقد كتبتها هنا من قبل ... :)))

نعم ، نظرًا لأنني أصبحت أكثر دراية بالأرض هنا ، فإن دعم Xaml في WF ليس مهمًا في حد ذاته ، ولكنه بالأحرى يحصل على System.Xaml هو الجزء المهم. نظرًا لأن هذا تم التقاطه بوضوح في صورة أخرى - ويسعدني جدًا أن أقول إنه شائع جدًا (لكن لا تدع ذلك يمنعك من التصويت ، @ freerider7777!: smile :) - المشكلة ، أنا أؤيد جعل WF تبعية مجانًا قدر الإمكان لضمان وصوله إلى .NET Core. 👍

@ Mike-EEE لقد صوتت هناك منذ وقت طويل !! :)

بالنظر إلى إمكانية إنشاء مهام سير العمل من خلال التعليمات البرمجية ، فهل سيكون استخدام Fluent API مشابه لـ EF Core خيارًا صالحًا لإضفاء الحيوية على WF Core؟ ثم يمكن إنشاء التسلسل / إلغاء التسلسل لوقت التشغيل بعد ذلك ويكون أسهل بكثير في التنفيذ؟

FluentAPIs ... حار جدًا الآن. أو على الأقل منذ أن استُقبلت. 😄

FluentAPIs ، Builder Pattern ، كلاهما متماثل بشكل أساسي. أعتقد أن توفير طريقة قائمة على الكود وقابلة للتسلسل وسهلة الاستخدام يجب أن يكون مبدأً قويًا وراء ذلك.

بدون مصمم كل شيء عديم الفائدة. بالطبع يمكننا ترميز كل شيء بأنفسنا - كل المنطق وكل السلاسل وما إلى ذلك (بطلاقة أو بدونها). ولكن ما هو رائع في WF - يمكنك أن ترى بصريًا تدفق المعالجة. إنه الرابط بين المديرين (و "أصحاب المصلحة" الآخرين) والمطورين! لا يفهم المديرون الكود ، لكن هذه المخططات عالية المستوى مفهومة من قبل الجميع. مع WF ، لا تحتاج إلى مخططات منفصلة (Visio أو غيره) إذا تم فصلها - فهي عادةً غير متزامنة مع التعليمات البرمجية الحقيقية :)

@ freerider7777 تسلسل تعريف WF لا يقتصر على xaml (انظر https://github.com/dmetzgar/corewf من dmetzgar ). يمكن تنفيذه لـ JSON أيضًا .. وهذا من شأنه أن يفتح إمكانية دمج / تفرع المشاريع الحالية مثل NodeRed http://nodered.org/ ، والتي تشبه من نواح كثيرة ميزات WF Designer و UX (+ ستعمل أيضًا في متصفح الويب ، وفتح حالات استخدام جديدة لـ WF)

أعتقد أنه من الأفضل نقل WF إلى .NET Standard وليس فقط .NET Core. يعمل وقت تشغيل WF المرتبط سابقًا بالفعل على .NET Standard 1.3 (يمكننا خفض مستوى التشغيل إذا أسقطنا نشاط WriteLine). مع طرح الإصدار القياسي 2.0 قريبًا ، سيكون لدينا القدرة على سد الكثير من فجوات الميزات مثل البيانات الوصفية التلقائية ، و DynamicActivity ، ونطاقات المعاملات. يجب أن نفصل المكونات في حزم مختلفة بحيث يكون هناك نموذج للدفع مقابل اللعب: إذا كنت تريد وقت التشغيل فقط ، فيمكنك الالتزام بـ 1.3 معيار ، ولكن إذا كنت تريد DynamicActivity ، فستحتاج إلى 2.0 القياسي وتحد من الأنظمة الأساسية الخاصة بك.

هناك بالتأكيد مجال كبير للتحسين في كود وقت تشغيل WF. على سبيل المثال ، سأستبدل ملحقات النشاط بحقن التبعية. سيكون Fluent API مثيرًا للاهتمام لكتابة سير العمل في الكود (وعلى طول هذه الخطوط ، انظر إلى https://github.com/knat/Metah بواسطةknat) لكنني أتفق مع @ freerider7777 على أن القدرة على التواصل مع إدارتك و BA باستخدام الرسوم البيانية المتولدة مما هو مستخدم بالفعل في الإنتاج هو إضافة كبيرة. helmsb لديه خبرة كبيرة في هذا (راجع http://dotnetrocks.com/؟show=1236).

يجب أن يكون المصمم الجديد تطبيق ويب. استهداف WPF أو UWP من شأنه أن يحد من الجمهور. إذا تم حل OmniXAML ، يمكن للأشخاص إنشاء / تحرير مهام سير العمل باستخدام نفس الأدوات التي يستخدمونها اليوم (VS أو حل مُعاد استضافته). تكمن المشكلة في أنه نظرًا لأن المصمم الحالي مدمج في .NET Framework ، فإن أي ميزات أو إصلاحات يجب أن تنتظر إصدار .NET Framework. من الجيد أن تبدأ ولكن ليس حلاً طويل الأمد. أجرى @ erikcai8 بعض التجارب مع مصمم ويب شبيه برأسه. سأرى ما إذا كان بإمكاني إقناعه بالمشاركة.

بالنسبة للواجهة الأمامية لمصمم سير العمل ، هناك محاولة أولى متاحة على github: https://github.com/gary-b/WF4JSDesigner ويمكنك استخدامها مباشرة http://gary-b.github.io/WF4JSDesigner/

هذا ما يبدو عليه بالفعل:

ewinnington : من الرائع رؤية مصمم سير عمل الويب POC. لقد قمت أيضًا ببناء واحدة أخرى كما هو موضح أدناه.

AWWWWW SNAP !!! إنه WF POC-OFF !!! 🎉

هيه هيه. Hey @ erikcai8 أين التصدير إلى Xaml ؟؟؟ ها ها. مجرد التقليب لك الحزن. سورتا. 👼

كلا المجهودات تبدو رائعة. من الجيد رؤية كلاهما يبدو هذا واضحًا نوعًا ما الآن ، ولكن ما مدى روعة وجود مصمم مرئي على شبكة الإنترنت في WF الأصلي؟ كل شيء مؤمن ومحمّل ، وجاهز للذهاب ، ما عليك سوى زيارة عنوان URL. أعتقد أن هذا كان سيساعد حقًا في الترويج للعلامة التجارية والتبني. لسوء الحظ ، يبدو أن الجميع قد وصلوا إلى المحرر المستند إلى TFS والذي كان من الصعب جدًا إعداده وأدى إلى مطول Xaml. كانت هذه تجربة سيئة للمطور النموذجي الذي كان عليه التعامل معها وأعطى أي شيء له علاقة بالتجربة (WF أو Xaml) اسمًا سيئًا.

هذا ، OTOH ، يبدو وكأنه نهج رائع. فلتبدأ النهضة!

عززت تجربة @ Mike-EEE My E2E محرك Workflow Core لتحميل سير عمل JSON محليًا بحيث لا يكون تنسيق XAML مطلوبًا. يمكن تصدير سير عمل XAML من Workflow Engine بمجرد تحميله لسير عمل JSON.

هذه هي النقطة. يجب ألا نربط وقت التشغيل ونموذج الكائن الخاص به بالمصمم والتنسيق المتسلسل بالطريقة التي كان عليها في WF 4.5 ...

galvesribeiro فهمت هذه النقطة. افترضت التجربة أن تنسيق JSON كان مدعومًا كخيار آخر لـ Workflow Core. كما نوقش أعلاه ، XAML ليست صديقة لأحدث تقنيات الويب حتى الآن.

نحن نحب WF يرجى نقله إلى .NetCore.

نحن بحاجة إلى مصمم سير عمل على شبكة الإنترنت. دعم .NET core ، لتشغيل مهام سير العمل سيكون رائعًا مضاعفًا. اذهب اذهب

يعمل Daniel Gerlag على محرك سير عمل لطيف وخفيف الوزن ومتوافق مع النواة هنا:

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

لقد قطع دانيال شوطًا طويلاً في فترة زمنية قصيرة جدًا. أود أن أشجعك بشدة على النظر إليه والمشاركة في هذا المشروع إذا وجدت ميزة فيه.

مع كل هذا الاهتمام ، لماذا لا نبني فقط محركًا متوافقًا مع Net Core من البداية؟

ccpony لأنه يمكنك استخدام CoreWF على dot net core الآن -> https://github.com/dmetzgar/corewf . المكونات المركزية تستدير وتعمل. هناك بعض الأشياء في انتظار .net القياسي 2.0.

ewinnington شكرًا على الرد ، لكني لا أفهم هذا. لم يكن WF منتجًا ناجحًا لـ MS ولم تفعل MS شيئًا لتحسينه لسنوات. المجتمع مليء بشهادات عن عمليات التنفيذ التي تمت تجربتها وفشلها. لم يتم اعتماده على نطاق واسع في المؤسسة. إنه غير عملي ، ومميزات زائدة ، ويصعب تعلمه و (لا يزال) عربات التي تجرها الدواب. واجهته سيئة على نطاق واسع. لقد فشلت في أن تصبح تقنية صديقة للمستخدم النهائي. الأجزاء الداخلية هي في الأساس صندوق أسود لا يمكن تحسينه بسهولة. إنه بطيء مع أي شيء آخر غير عمليات سير العمل البسيطة. من الصعب جدا اختبارها. يعتمد على التقنيات القديمة (WCF ، XAML). منذ أن مرض رون جاكوبس ، يعاني WF وليس له صديق في MS.

في تقديري ، حاول WF أن يكون كل شيء للجميع وفي الواقع ، تبين أنه صغير بالنسبة لأي شخص. مايكروسوفت قد أسقطتها كلها. لماذا نرغب في إحياء شيء من هذا القبيل؟ إذا دعت أي تقنية مهمة إلى إعادة التفكير وإعادة كتابة هذا هو.

انظر إلى مشروع دانييل جيرلاغ الوليد. إنه جديد وغير ناضج. ولكن الأمر يتطلب نهجًا حديثًا لسير العمل يكون من السهل تحسينه. إذا توقف الجميع هنا عن محاولة تعديل مشروع معقد ومؤرخ وبصراحة مفرط الهندسة ، وبدلاً من ذلك وضعوا جهودهم في شيء جديد وأفضل ، فسنحظى بفرصة أن ينتهي بنا المطاف في مكان يستحق العناء - - بناء تدريجي محرك سير عمل من الطراز العالمي بدلاً من محاولة إعادة كتابة عملاق من البداية. بصراحة ، أنا معجب بكل شخص هنا يرغب في الانخراط في جهد جدير بالاهتمام - - إنشاء ، أخيرًا ، أداة هندسية جيدة ، وظيفية ، خفيفة الوزن ، شرق للتعلم ، عبر النظام الأساسي (آلة الدولة؟). لكن ، يؤسفني أن أقول ، إذا استمرتم جميعًا في اتباع هذا المسار ، فستتلاشى كل جهودكم لتصبح لا شيء. MHO.

ccpony شكرا لتقاسم رأيك. هل تمانع في توضيح الأخطاء التي تشير إليها؟ إذا كان هناك شيء يمكننا القيام به لإصلاح المشكلات في .NET Framework ، فسيسعدني معرفة ذلك.

dmetzgar شكرا على الرد ، داستن. خلال الفترة الزمنية التي كنت أحاول فيها تطوير تطبيقات WF ، واجهت أخطاءً. ليس فقط سلوكيات غير متوقعة ، ولكن كانت هناك عدة مرات أن WF المعقد قد "ينفجر" ويولد أخطاء في XAML UI كان من الصعب إصلاحها في كود XAML. لم أقم أبدًا بتطوير ثقة كبيرة في تقنية WF. حقًا ، لقد وصلت إلى النقطة التي شعرت فيها أنني كنت أصارع غوريلا 800 رطل - - مقابل كل خطوة للأمام ، كنت سأنتهي بخطوتين.

أعلم أن هذا ليس ما تبحث عنه في طلبك اللطيف لي للتوسع في الأخطاء. بصراحة ، يمكنني التغلب على تلك الأخطاء. لكنني في النهاية تخلت عن WF لجميع الأسباب الأخرى التي أشرت إليها في رسالتي السابقة.

إنك تقود هذا الجهد وأنا أحييك عليه. لكن من المؤكد أن هناك نقطة عندما تصبح محاولة تعديل تكنولوجيا معقدة تؤدي إلى نتائج عكسية. باتباع هذا الموضوع بأكمله ، لا يسعني إلا أن أشعر أن التقدم بطيء جدًا - - إن وجد - - وفي النهاية لن يظهر أي شيء من كل هذا. أجد أنه من غير المحتمل جدًا أن تكون مهام سير العمل القديمة محمولة لأي شيء يتم إنتاجه هنا. يتحدث الأشخاص في هذا الموضوع عن سير العمل المستند إلى العميل (مثل JavaScript) ، وتوافق REST ، وتقليل التبعيات ، والنظام الأساسي المشترك ، وما إلى ذلك. على سبيل المثال ، يعد XAML جزءًا مهمًا من تقنية WF القديمة ، فما الفائدة من نقل WF إلى core لن يكون XAML جزءًا منه؟

لذا ، داستن ، أريد أن أسألك هذا: لقد أمضينا 18 شهرًا في هذا المشروع ولا يبدو أن هناك إجماعًا على إحراز تقدم حقيقي. أحترم جهودك وأستطيع أن أرى أنك مبرمج رائع - - ولكن هذا سؤالي: ألن يكون من المنطقي حشد كل هذه الطاقة والحماس وإنشاء شيء جديد؟

ccpony المناقشة في هذا الموضوع هي لدعم WF. صافي القياسية وليس العكس.

مجرد فضول ... هل سبق لك استخدام أو شاهدت نشر Sharepoint أثناء العمل؟ إذا قمت بذلك ، فسترى أنها شديدة التأثير على WF. هل سبق لك أن رأيت نشر BizTalk؟ نفس الشيء.

هذه هي منتجات MSFT الرئيسية في عالم المؤسسات ، لذا نعم ، هناك مستخدمون يهتمون بـ WF وهناك استخدام له. إنه ليس مشروعًا متروكًا / متخلفًا كما قلت.

مع ذلك ، إذا نظرت إلى dmetzgar repo ، فسترى أن الكثير من الأشياء متشابهة أو موروثة بعض السلوكيات من التجسد القديم لـ WF ، سترى أيضًا أنه تم إعادة تصميمه ليكون خفيف الوزن. المثابرة تنفصل ويمكن للناس بسهولة إنشاء أخرى جديدة. تم فصل المصمم وقام الأشخاص بالفعل بإنشاء اختبارات متعددة.

أتفهم إحباطك من رغبتك في شيء جديد. صدقني ، أريد أن يحدث ذلك أيضًا. لكن عليك أن تفهم dmetzgar وفريقه. هذه ليست أولوية لأن 95 ٪ من العملاء هم من مستخدمي WF القديم الذي يعمل بشكل أساسي على BizTalk و Sharepoint كما ذكرت. لقد استخدمت WF القديم لسنوات في بيئة tps عالية جدًا (المعاملات المصرفية والمالية) وقد خدمني جيدًا.

تعمل تقنيتي الجديدة مع .Net Core ، والسبب الوحيد الذي جعلني لا أستخدمه مرة أخرى الآن ، هو أننا لا نمتلكه لـ .Net Core حتى الآن.

ما اقترحته بالفعل على dmetzgar ، هو إحضار WF repo إلى .Net Foundation ، وتحديد المعالم ، ووضع الكود هناك وإضافة المهام كمشكلات ووضع علامة عليها كـ up-for-grabs حتى يبدأ المجتمع في القيام بذلك. ومع ذلك ، لا يزال هذا يتطلب بعض الوقت من فريقه لإنجاز هذا العمل وربما لم يتوفر لديهم هذا الوقت (حتى الآن).

galvesribeiro أحصل على وجهة نظرك. نعم ، لقد كتبت عمليات نشر SharePoint. وقد رأيت عمليات نشر BizTalk قيد التشغيل (* مصراع *). أفهم العلاقة بين SharePoint و WF. (لا أعرف ما تقصده عندما تقترح أن تعتمد BizTalk بطريقة ما على WF. إنها لا تفعل ذلك).

لكن لا بد لي من الاختلاف معك في نقطة واحدة مهمة: WF هو مشروع مهمل / مهمل. إنني أتفهم حقًا مخاوف مطوري SharePoint في هذه المرحلة. لا يوجد سبب للاعتقاد بأن MS سيعزز قدرات WF في SharePoint. لا أفهم لماذا تعتقد أن جهود dmetzgar سيكون لها أي علاقة بمستقبل SharePoint (أو BizTalk). ليس الأمر كما لو أن MS ستقوم بتعديل SharePoint مع كودdmetzgar . عذرًا ، لكن مستقبل SharePoint لا علاقة له بالجهود المبذولة هنا.

لذا ، كل ما يهم حقًا هو ما إذا كان محرك سير عمل جيد سيخرج من كل هذا. ومن وجهة نظري أن محاولة فرض عملاق مثل WF في المستقبل ليس أفضل مسار للعمل. من الأفضل البناء من الصفر.

ccpony أود أن أذكرك أن هناك العديد من الأشخاص هنا الذين يسعون بنشاط لرؤية هذا المشروع ينبض بالحياة ، والبعض الآخر يخصص الوقت بالفعل لتحقيقه. بينما يمكنك شخصيًا أن تنظر إلى WF على أنه منتج فاشل من Microsoft ، إلا أنه يظل جزءًا من .NET ويستخدمه أكثر من نحن هنا.

يجب أن يكون هذا الخيط للنقد البناء والمساهمة في جعل الانتقال حقيقة واقعة وليس انتقادًا للآخرين أو المنتج نفسه. بينما يتم احترام آرائك ، لاحظ أنها آرائك وأن الآخرين قد يفكرون بشكل مختلف فيما يتعلق بمدى أهمية WF بالنسبة لهم.

نرحب بشدة بمدخلاتك حول طرق تحسين المنتج وأفضل طريقة لمساعدة أولئك الذين يشاركون بنشاط في المحاولة.

شكرا = ^ _ ^ =

تضمين التغريدة

(لا أعرف ما تقصده عندما تقترح أن تعتمد BizTalk بطريقة ما على WF. إنها لا تفعل ذلك).

آسف ، أنا أعبر عن نفسي بشكل سيء (أنا على الهاتف المحمول). كان لدي تطبيق يستخدم كلاهما معًا وأعرف الكثير مما يفعله أيضًا.

لا يوجد سبب للاعتقاد بأن MS سيعزز قدرات WF في SharePoint.

أنا لا أقول أنها ستفعل. أنا أقول إن الفريق الذي يعمل مع WF Today يركز تمامًا على دعم عمليات نشر Sharepoint. حتى أحدث إصدار من Sharepoint يستخدم نفس / الإصدار الحالي من WF.

لا أفهم لماذا تعتقد أن جهود dmetzgar سيكون لها أي علاقة بمستقبل SharePoint (أو BizTalk).

أنا لا أقول أنه سيؤثر على مستقبل Sharepoint. أقول إن الفريق مشغول بدعم Sharepoint إذا فهمت بشكل صحيح. ( @ dmetzgar يمكن أن يصححني إذا كنت مخطئا)

ليس الأمر كما لو أن MS ستقوم بتعديل SharePoint مع كودdmetzgar . عذرًا ، لكن مستقبل SharePoint لا علاقة له بالجهود المبذولة هنا

إذا كانت MS ستستخدم أو لا تستخدم WF vNext على Sharepoint vNext ، فإنهم وحدهم من يستطيعون التأكد من ذلك. مرة أخرى ، المشكلة هي أن فريق WF غير قادر على التعامل مع كليهما.

لذا ، كل ما يهم حقًا هو ما إذا كان محرك سير عمل جيد سيخرج من كل هذا. ومن وجهة نظري أن محاولة فرض عملاق مثل WF في المستقبل ليس أفضل مسار للعمل. من الأفضل البناء من الصفر.

لا أحد يصورها كما هي. يعد الريبو الخاص بـdmetzgar دليلًا على إعادة تصميمه من الألف إلى الياء. مرة أخرى ، تكمن المشكلة في التراكم والنطاق الترددي الذي يتعين على الفريق التعامل معه مع كلا الأمرين. لهذا السبب اقترحت "فتحه" على أساس dotnet وجعله جهدًا رئيسيًا يحركه المجتمع مع توجيه وتوجيه فريق WF لذلك نحاول التأثير بأقل قدر ممكن على جداولهم.

مرة أخرى ، مثل InariTheFox وأنا ذكرت ، هذا الخيط عبارة عن دفع للأمام للمنفذ ، والذي لا يعني بالضرورة دفع النسخة القديمة بكل هذه الميزات إلى الإصدار الجديد. ومع ذلك ، من المهم أن نفهم أن الأشخاص يبذلون الكثير من الجهد (والمال) على منتجاتهم الحالية القائمة على WF ، لذا فإن مخاوف dmetzgar بشأن keey قدر الإمكان من التوافق مع تدفقات العمل القديمة ، هي بالفعل شيء يجب الاهتمام به.

موافق. أرى المشاعر هنا. في الواقع ، إذا كان هناك بديل جيد لـ WF الذي عالج جميع المشاكل التي ذكرتها من قبل ، فلن نجري هذه المحادثة. للتسجيل ، ابتعد الكثير منا عن WF وانتظروا في الوريد حتى يأتي الشيء التالي. لم تفعل. على حد علمي ، لا يوجد حل آلي لسير العمل / الحالة قائم على شبكة الإنترنت يتم اعتباره على نطاق واسع. يرجى تفهم ما يلي: أنا متمسك بزعمي أن WF هي تقنية ميتة من منظور Microsoft.

ولكن بعد قولي هذا ، الرجاء مساعدتي في الفهم. هل يعمل الريبو الخاص بـ dmetzgar كما هو؟ كيف يكتب المرء سير العمل معها؟ لا أرى أي مثال على الكود ولا توجد أي وثائق. كيف يمكنني المضي قدما؟

أعتقد أن هناك العديد من المنتجات / الشركات التي جعلت WF مركزيًا لاستراتيجية منتجاتها ، فهي ليست مجرد تبعية Sharepoint في وضع الدعم: في شركتي الحالية قمنا بتطوير منصة أتمتة مع WF كونها التكنولوجيا المركزية (وأنا أعلم متنافسان آخران من هذا السوق يستخدمان أيضًا WF في منتجاتهما) ؛ لقد ناقشت أيضًا مع الأشخاص الذين يستخدمونها في تكنولوجيا التأمين .. لذلك أعتقد بقوة أن جمهور WF لا يزال موجودًا.

ومع ذلك ، يبدو أن .net core هو أحد مجالات تركيز Microsoft وسيتناوله الكثير من الابتكارات التقنية في الفترة المقبلة ؛ أعتقد أنه سيكون خسارة كبيرة لعدم وجود WF كجزء منه.

من وجهة نظري ، فإن المسار الصحيح لتحقيق ذلك هو جعل جوهر WF مستقلاً عن xaml وتسهيل (إلغاء) تسلسل تدفقات العمل بتنسيقات أخرى أيضًا (على سبيل المثال: json). سيؤدي ذلك أيضًا إلى تبسيط تنفيذ السيناريوهات مثل مصممي سير العمل المستضافين في متصفحات الويب. ومع https://github.com/dmetzgar/corewf repo ، لدينا نقطة انطلاق.

بالنسبة للراغبين في الحصول على نظرة عامة حول الحالة الحالية لـ WF (التي لا أرى أنها تخلى عنها MS) ، قمت منذ فترة بتجميع المعلومات المتاحة بخصوص WF في منشور وعرض تقديمي http://andreioros.com/blog / windows-workflow-Foundation-rehosted-designer / ؛ ما زلت أبقيها محدثة

نعتمد نحن وعملائنا على WF ونود بشدة أن نراه يعمل على العميل وكذلك الخادم. إن WF الخالي من XAML والاعتمادات الأخرى ، المصمم ليكون خفيف الوزن ولكن مع التعبير عن WF الحالي الذي يدعمه المجتمع أيضًا مع MS ، سيكون منتجًا مثيرًا وقيِّمًا بالفعل.

مرة أخرى ، اسمح لي أن أسأل: ماذا يفعل المرء بمنفذdmetzgar ليعمل على تشغيله؟ ما هو الوضع الحالي؟

لم أكن أعرف أن منفذ dmetzgar كان قابلاً للاستخدام بالفعل في تجسده الحالي ...

من ewinnington ، أعلاه:

"لأنه يمكنك استخدام CoreWF على dot net core الآن -> https://github.com/dmetzgar/corewf . المكونات المركزية يتم نقلها وتعمل. هناك أشياء قليلة تنتظر .net القياسي 2.0."

في هذه الحالة أود أيضًا أن أسمع عن استخدامه ...

نعم ، إنها أعمدة الوظائف الأساسية. يمكنك تشغيل مهام سير العمل المستندة إلى التعليمات البرمجية. الميزات المفقودة من netstandard2.0 تتعلق في الغالب بدعم المعاملات.

هذا أحد الأسباب التي ما زلت أقترح البدء بها وجعل الناس يساهمون في مكان مركزي. إن انتشاره سيجعل الوصول إلى الأشياء أكثر صعوبة في منتج نهائي يومًا ما في المستقبل.

قم بالتصويت لصالح إعادة كتابة WF مع الاختبارات ودعم ميزات Roslyn الحديثة كجزء من Core. أود أن أرى كيف يمكن أن تؤثر الحاويات بدون خادم على البنية ، وخاصة نشر مجموعات القواعد وتوسيع نطاقها ضمن سياقات المجال والعمليات التجارية المتميزة. أنا شخصياً أفضل استخدام DSL موجز على مصمم WYSIWYG. لقد أحببت المصمم شخصيًا ، لكنه شعرت أنه غريب طوال الوقت تقريبًا. WF نفسها لديها القدرة على أن تكون قوية للغاية ، لكنها تتطلب خبرة عميقة. في السهولة ، تطلبت عملية طرح كبيرة لـ WF والتي تضمنت WF Manager والتدفقات المستمرة في SQL Server استشارة MS وإصلاحات للأخطاء. على الرغم من أنني الآن أدعم فرق Java في السنوات العديدة الماضية ، إلا أنني أحب أن أراقب .NET بعد ما يزيد قليلاً عن 15 عامًا من التركيز بشكل أساسي على تقنية MS. كنت أقرأ "Code Generation with Roslyn" من تأليف Nick Harrison (ليس لدي أي علاقة به أو بالكتاب) وتساءلت عن إعادة الاقتراب من مساحة Business Rule Engine مرة أخرى ، مما دفعني إلى التساؤل عن مصير WF مرة أخرى ... بكل صدق ، أعتقد أن وظائف Azure تتنافس مع كل من موارد MS بالإضافة إلى استعداد الشركة العام لدعم الاستثمارات العميقة في WF في أي مكان. يبدو واضحًا أنهم يريدون منك استخدام ذلك ... لذا ، ربما يكون الحل هو التركيز بدلاً من ذلك على إصدار .NET مفتوح المصدر من OpenWhisk. ولكن ، في عالم مليء بالحاويات ، ... يمكنني فقط استخدام OpenWhisk كخدمة. لذا...

قد يؤدي دعم PS ببساطة لطريقة قوية لاستيراد التعبيرات الخارجية إلى حل 60 ٪ من متطلبات التطبيق التي تعتقد أنها قد ترغب في WF. هل كان CSharpScript؟ هناك طريقة بسيطة لاستيراد تكوينات قواعد العمل الأساسية باستخدام واجهة برمجة تطبيقات مباشرة من شأنها أن تقطع شوطًا طويلاً (خيارات متنوعة للمثابرة والاسترداد والتخزين المؤقت). من خلال البنية التحتية الافتراضية التي يمكن التخلص منها (التشغيل الآلي عبر البنية التحتية والحاوية والنظام الأساسي كخدمة) ، يمكن لـ WF vNext التركيز على نشر تغييرات الإصدار كخدمة بدلاً من محاولة تضمينها في التطبيقات (أي حل أفضل لـ WF على WCF)

أنا مهتم للغاية بهذه المحادثة. كان فريقي يتعامل مع الإحباط الناتج عن XAML أيضًا. معضلتنا هي أننا نقوم بإنشاء مصمم واجهة المستخدم الخاص بنا للسماح لعملائنا بإنشاء مهام سير العمل الخاصة بهم دون الحاجة إلى Visual Studio أو المصمم المعاد تعيينه. نحن بحاجة إلى القدرة على حفظ أجزاء من XAML في وحدات بت قابلة لإعادة الاستخدام بحيث لا يحتاج العميل دائمًا إلى إعادة كتابة هذه البتات (فكر فيها كوظائف لسير العمل). هذا يتطلب منا معرفة كيفية دمج أجزاء من XAML معًا ، الأمر الذي تعلمنا أنه محبط للغاية. ما نفكر في القيام به هو إنشاء فكرة مجردة حيث نعتمد ببساطة على نموذج قاعدة بيانات لأنشطتنا المختلفة وروابطها ونتجاهل XAML تمامًا. سنقوم بعد ذلك بإنشاء الأنشطة ، وما إلى ذلك بشكل برمجي في كل مرة يتم فيها تنفيذ سير العمل. أثناء البحث عن هذا النهج ، عثرت على هذا الموضوع. استمر في المحادثة ، أنا مهتم جدًا بسماع آراء الآخرين.

@ erikcai8 مصمم سير العمل فكرة لطيفة جدا. هل يمكنني الحصول على مصدر مصمم سير العمل الخاص بك؟

لقد كنت أستخدم WF لأكثر من 5 سنوات حتى الآن في مشاريع الأتمتة الخاصة بي وكان ذلك رائعًا. آمل أن يدعم الكثير من المطورين هذا الطلب وينفذونه. لطالما استخدمت .Net tech منذ أن بدأت العمل وأريد الاستمرار في ذلك. ومع ذلك ، فإن التمكن من دعم الأنظمة الأساسية هو اتجاه الشركة ، وبالتالي فأنا أتطلع حقًا إلى رؤية WF بالكامل في .Net Core.

مع وصول net standard 2.0 ، سيكون من الرائع الحصول على تحديث حول مشكلات corewf:

تضمين التغريدة
https://github.com/dmetzgar/corewf/issues/3
https://github.com/dmetzgar/corewf/issues/4

كيف قامت واجهة برمجة التطبيقات المضافة بإلغاء حظر عملية النقل وماذا يمكننا أن نفعل للمساعدة؟

أعتقد أنه بغض النظر عن netstandard2.0 ، يجب أن يذهب هذا المنفذ كما كان يذهب IMHO ... مع إعادة الكتابة ... مما يجعله صديقًا لجدولة المهام الخارجية ، غير المتزامن / انتظار / المهمة ، والأشياء الحديثة الأخرى. بقدر ما أحب WF ، فإن الإصدار الحالي قديم جدًا ...

أعني هذا دون أي ازدراء على الإطلاق. بكل صراحه. لكن هل أنا الوحيد هنا الذي يفهم أن هذا المشروع ميؤوس منه؟ نحن بحاجة ماسة إلى محرك سير عمل جيد لـ .Net ، لكن هذا ليس هو الحال. ألا يجب علينا تغيير الحديث هنا؟

أنا منفتح على محرك سير عمل جديد أفضل. خلاصة القول نحن بحاجة إلى واحد في .NET Core. لقد استخدمنا WF لسنوات وقد نجح بالفعل بالنسبة لنا ، لذا فهو أفضل من لا شيء إذا كان هذا هو البديل.

kalokamgit ، المصدر متاح في مصدر مرجعي. إنه في مجموعتين:
System.Activities.Presentation و System.Activities.Core.Presentation .

لسوء الحظ ، فإن الأداة التي تنشر المصدر المرجعي لا تستخدم سوى كود C #. لا يتضمن أيًا من ملفات XAML. يمكنك تقديم ملاحظات حول هذا الأمر إلى [email protected] و / أو التصويت على مشكلة صوت المستخدم .

الكود موجود في .NET Framework لذا يمكنك استخدامه بحرية في أدواتك الخاصة. بعض الأمثلة هي مشروع orosandrei ومثال لمشروع هنا .

أعني هذا دون أي ازدراء على الإطلاق. بكل صراحه. لكن هل أنا الوحيد هنا الذي يفهم أن هذا المشروع ميؤوس منه؟ نحن بحاجة ماسة إلى محرك سير عمل جيد لـ .Net ، لكن هذا ليس هو الحال. ألا يجب علينا تغيير الحديث هنا؟

حسنًا ، إذا كنت _ حقًا_ لا تقصد عدم الاحترام. :) لدي فضول لمعرفة ما يدور حوله الجميع حول Flow ؟ هذا ما أفكر به عندما أفكر في "سير العمل" لـ "العصر الحديث" ... أيضًا ما تروج له Azure بشدة هذه الأيام.

أنا أعني ذلك حقًا :)

Guess Flow هو الحل لنمو Zapier؟ لا أرى كيف سيحل محل الصندوق العالمي للطبيعة بأي شكل من الأشكال.

هل توقف WF أو أفتقد شيئًا ما هنا؟ سيكون ذلك محزنًا جدًا!

أين يمكنني التصويت لصالح WF؟

أعلى وظيفة في هذه القضية هي أفضل مكان.

أتساءل ما رأيrjacobs (WF guru) في هذا الأمر.

هل تقصدronljacobs؟

dmetzgar على الأرجح نعم. إنه بطل WF الحقيقي

هذا هو جوابي
https://github.com/danielgerlag/workflow-core

كان رون جاكوبس هو الرجل الذي وضع قلبه وروحه في WF لسنوات وسنوات. أصيب بمرض ديركوم وترك Microsoft في عام 2013. (هنا) عندما غادر ، كان هذا لصالح WF. مرة أخرى ، ونأمل للمرة الأخيرة: WF ميت.

ومرة أخرى - - أود أن أشجع الجميع وأي شخص على النظر إلى مشروع Dan Gerlag أعلاه. إنها بليغة ومصممة بشكل جميل وتعمل على Core. يحتاج أي شخص يرغب في المساهمة في حل سير عمل قابل للتطبيق إلى البحث عنه.

يرجى أيضًا إلقاء نظرة على إطار العمل الدائم . تتم إضافة هذا إلى وظائف Azure ، راجع الوظائف الدائمة .

dmetzgar هذا الإطار موجود في الحفاضات ليكون بديلاً عن WF. لا أعتقد أنه من الجاد أن تقترح Microsoft هذا النوع من الأشياء. ألن يكون ذلك أفضل بكثير بدلاً من إعادة اختراع العجلة ، وترحيل WF إلى .NET Core وإعادة استخدامه كأساس في جميع مشاريع Microsoft؟ آسف لقسوة كلماتي ، لكنني أعتقد أنها تمثل مشاعر العديد من الأشخاص الذين يشعرون بخيبة أمل كبيرة من الوضع الحالي لمؤسسة WF.

Suriman ، نقطة عادلة

لقد قمت بتحديث الملف التمهيدي على corewf repo للحصول على وصف أفضل لما ينطوي عليه نقل WF إلى .NET Core. هل تمانع في إلقاء نظرة؟

dmetzgar شكرًا على التوضيحات ولإظهار الطريق بوضوح إلى منفذ WF إلى .NET Core. أفهم مما تقوله أن Microsoft لن تقوم بكل أعمال الترحيل هذه وأنها تأمل أن يقوم المجتمع بذلك ، أليس كذلك؟ الإجابة على هذا السؤال هي المفتاح ، اعتمادًا على الرد ، يمكن للشركات اختيار طريق بديل أو القيام بالعمل الذي يجب على Microsoft القيام به.

لن تقوم Microsoft بعمل منفذ رسمي من WF إلى .NET Core. سأعمل أنا وفريقي على هذا في أوقات فراغنا ، ولكن ليس بصفة رسمية أو مع أي إصدارات مجدولة. جميع القضايا المدرجة معروضة للبيع. هناك استخدامات لمثل هذا المنفذ في بعض المشاريع التي نقوم بها. سيكون هذا هو المكان الذي تأتي منه معظم مساهماتنا. أعتقد أنه من العدل إغلاق هذه المشكلة في الوقت الحالي وتوجيه الأشخاص إلى repo corewf لمتابعة آخر عمل.

مرحبا،
التغيير من المرحلة المستقبلية إلى 2.1 ، هل يعني أن Microsoft ستقوم بنقل WF إلى .NET Core؟

يعكس التغيير الرئيسي للإصدارات المغلقة فقط أثناء إغلاق الإصدار.
تم إغلاق هذه المشكلة تحديدًا باعتبارها "لن يتم إصلاحها" - راجع الشرح أعلاه https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275

@ karelz يا للأسف. للحظة ، بدا أن اليانصيب قد أصابنا.

لدينا حل يعتمد على WF. نحن نقوم بإنشاء خطوات للأنشطة باستخدام WF وسيتم تسليم سير العمل هذا إلى جميع المشتركين وسيقومون بمعالجة الإجراءات بناءً على WF. نحن نحب WF كثيرًا. دعم عبر منصة هو اتجاه شركتنا. نحن مهتمون جدًا بالحصول على WF على .NET CORE.

يوجد CoreWF وهو رمز مؤسسة Workflow تم نقله جزئيًا إلى .net core. يمكنك استخدام منصة Workflow عبر النظام الأساسي الآن . لا يمكنك استخدام مهام سير العمل المستندة إلى XAML في هذا الوقت.

لدي فرع عملت فيه على إضافة دعم للنشاط الديناميكي فوق Net Standard 2.0 .

تتطلب عملية تحليل XAML من Microsoft فتح System.XAML بشكل كافٍ حتى نتمكن من إحراز تقدم في تحليل الملفات بشكل صحيح.

يمكنك تتبع التقدم المحرز في هذه المشكلة هنا: https://github.com/dmetzgar/corewf/issues/6 وفي محاولاتي المختلفة لتقديم إشعار لهذه المشكلة:
على CoreFX
على ReferenceSource

تحتوي حزمة التوافق .Net على "ربما" على واجهة System.XAML. لكن لم يتم تصفية أي أخبار حول إدراجه. تسرد مشكلة حزمة توافق إطار عمل .Net Ship حاليًا "لا توجد خطط" لـ System.XAML.

ربما أيضًا المشكلة التي يمكن استخدام ملحمة تبني العملاء لإخبار قصتك عن كيفية إضافة Workflow Foundation (و System.Xaml) إلى السماح لشركتك بشحن منتج.

تستثمر شركتي أيضًا في WF: لدينا منتج لشركات الطاقة حيث ينشئ عملاؤنا تدفقات عمل باستخدام Workflow Foundation.

شكرا لك على الرد.
كان من المفيد جدا نقدر ذلك.

في 2 تشرين الثاني (نوفمبر) 2017 الساعة 18:22 ، كتب "إريك وينينجتون" [email protected] :

يوجد CoreWF https://github.com/dmetzgar/corewf وهو رمز
تم نقل مؤسسة سير العمل جزئيًا إلى .net core. يمكنك استخدام سير العمل
عبر منصة الأساس الآن . لا يمكنك استخدام مهام سير العمل المستندة إلى XAML
في هذا الوقت.

لدي فرع عملت فيه على إضافة دعم للنشاط الديناميكي
أعلى Net Standard 2.0 https://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

حزمة التوافق
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
يحتوي على "ربما" على واجهة System.XAML. لكن لم يتم تصفية أي أخبار بشأنه
تضمين. إصدار حزمة توافق إطار عمل Ship .Net
https://github.com/dotnet/corefx/issues/24909 يسرد حاليًا "لا
الخطط "لـ System.XAML.

ربما أيضًا مشكلة ملحمة تبني العملاء
يمكن استخدام https://github.com/dotnet/corefx/issues/24751 للإخبار
قصتك عن كيفية السماح بإضافة Workflow Foundation (و System.Xaml)
شركتك لشحن منتج.

شركتي مستثمرة أيضًا في WF: لدينا منتج لشركات الطاقة
حيث ينشئ عملاؤنا تدفقات عمل باستخدام Workflow Foundation.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

مرحبا،
هذا عالم من الخدمات الصغيرة ويتم تقسيم كل العناصر إلى مكونات. الآن إذا كان علينا تنسيق ذلك ، فسيتعين علينا الاعتماد على تطبيقات Azure المنطقية أو بعض البائعين الخارجيين الآخرين الذين يفرضون رسومًا إضافية على سير العمل. على الرغم من وجود القليل جدًا من المنتجات بخلاف .NET WF مثل Netflix Conductor ، إلا أننا نود أن يكون لدينا منتج في إصدار .NET الأساسي النقي. يمكنك أخذ القرائن من موصل Netflix على https://github.com/Netflix/conductor والبدء في بناء واحدة من هناك. سيكون هذا نعمة كبيرة لمطوري السحابة الخاصة الذين ليس لديهم إمكانية الوصول إلى Azure Stack الذين لا يمكنهم استخدام تطبيقات Logic.

اعتقدت أنني سوف أنشر هنا من أجل الوعي. كنت أقرأ الوثائق التالية وجعلتني أفكر في هذا الموضوع:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

يبدو أن Dynamics365 و PowerApps يقومان بعمل مزيج ذهني ويستخدمان Windows Workflow في بعض القدرات لمعالجة سير العمل الآن. كل هذا بالطبع يعمل بنظام Windows فقط ، ولكن في العصر الجديد من الأنظمة الأساسية المتعددة ، وما إلى ذلك ... إلى متى سيستمر هذا؟

لا أعرف ما الذي من المفترض أن أستخدمه. أتمنى أن تقوم MSFT بذلك. تحقيق الوضوح مايكروسوفت.

VenkateshSrini ، يجب أن تنظر أيضًا في الإيقاع: https://github.com/uber/cadence
النموذج يشبه إلى حد كبير SWF من أمازون ولكنه مفتوح المصدر. لا يوجد عميل .NET حتى الآن على الرغم من.

تبحث عن. النسخة الأساسية الصافية

لن يحدث.

من: VenkateshSrini [email protected]
تاريخ الإرسال: الأربعاء 26 سبتمبر 2018 الساعة 12:30 صباحًا
إلى: dotnet / corefx [email protected]
نسخة إلى: Jeffrey Michelson [email protected] ؛ أذكر [email protected]
الموضوع: Re: [dotnet / corefx] Port Workflow Foundation to .NET Core (# 2394)

تبحث عن. النسخة الأساسية الصافية

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 ، أو كتم صوت سلسلة المحادثات https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5M

سيء جدا

إذن ما الذي تقدمه Microsoft لـ ifttt أو سير العمل في النظام البيئي غير Azure. عندما يريدون تمكين أشياء مثل ml من Azure ، فلماذا لا يتم سير العمل

تحقق من عمل دان جيرلاغ.

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

من: VenkateshSrini [email protected]
تاريخ الإرسال: الأربعاء 26 سبتمبر 2018 الساعة 8:34 صباحًا
إلى: dotnet / corefx [email protected]
نسخة إلى: Jeffrey Michelson [email protected] ؛ أذكر [email protected]
الموضوع: Re: [dotnet / corefx] Port Workflow Foundation to .NET Core (# 2394)

إذن ما الذي تقدمه Microsoft لـ ifttt أو سير العمل في النظام البيئي غير Azure. عندما يريدون تمكين أشياء مثل ml من Azure ، فلماذا لا يتم سير العمل

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 ، أو كتم صوت السلسلة https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY .

يوجد CoreWF وهو منفذ أساس سير العمل إلى .net core. هذا المنفذ يتقدم. نحن نبحث عن أشخاص للمساعدة.

تتمثل الخطوة الرئيسية التالية في تجميع مهام سير العمل المحملة باستخدام Roslyn حتى نتمكن من استخدام التعليمات البرمجية في معلمات سير العمل ، وهذا ضروري لسير العمل المحدد في XAML. إذا قمت بتعريف سير العمل في Imperative core ، يمكنك استخدام CoreWF الآن.

شكرا لعملك ewinnington و @ dmetzgar ! يعد دعم XAML من خلال Portable.XAML في CoreWF صفقة ضخمة لهذا الجهد. dmetzgar هل تخطط لنشر إصدار جديد لـ NuGet قريبًا؟

أهلا بكم،

هل هذا كل الإنتاج جاهز. نحن نتدلى في تعريف تدفق العمل الذي يتعين القيام به من واجهة المستخدم الخارجية. لكن يجب أن يكون المحرك قادرًا على تحميل التعريف والعمل من جديد. أكثر من نوع iffft

VenkateshSrini ، لا أعتقد أنه من الضروري لشركة Microsoft توفير إطار عمل لسير العمل عبر الأنظمة الأساسية. في أيام .NET Framework ، قدمت Microsoft كل شيء على حساب المجتمع ككل. أود أن أرى المزيد من مكتبات .NET مفتوحة المصدر التي اعتمدتها المنظمات وجعلت "الإنتاج جاهزًا".

watertree ، أنا في انتظار إصدار جديد من Portable.Xaml. هناك إصلاح حاسم مطلوب لدعم CoreWF XAML.

ما هو البديل لمهام سير العمل طويلة المدى في الوقت الحالي (مع المثابرة)؟ المدفوعة فقط؟

تضمين التغريدة

لمعلوماتك: https://github.com/danielgerlag/workflow-core

نستخدمه في شركتنا بنتائج جيدة جدًا.

بالنسبة لأولئك الذين ما زالوا يتابعون ، فإن مشروع CoreWf قد تقدم للتو معلمًا هامًا مع تكامل Roslyn للسماح بتنفيذ مهام سير عمل XAML المحملة ديناميكيًا. إذا كنت لا تزال بحاجة إلى Workflow Foundation على dotnet core ، فتحقق من ذلك.

مرحبا ،
هل هذا يعني أنه يمكنني أخذ تدفق عمل XAML الحالي واستخدامه كما هو. هل لدينا أي قيود

هل لدينا أي قيود

لم يتم نقل مخزن المثيل بعد ، والمصمم ليس في المركز وخدمة WCF غير متاحة نظرًا لأن خادم WCF لم يكن موجودًا في النواة حتى الآن.

يرجى إصدار مشكلة في CoreWf repo وسرد المتطلبات التي لديك. يمكننا مواصلة الحديث هناك.

nuget الحالي لـ corewf قديم ولا يتضمن تنفيذ Xaml لوقت التشغيل المستند إلى Roslyn والذي تم دمجه للتو. ما زلنا نبحث عن التعليقات لمعرفة ما يصلح وما لا يصلح.

هل هذا يعني أنه لن يحدث أبدًا؟

انها لن يحدث. لن يحدث ذلك أبدًا - - لا إهانة لأولئك الذين بذلوا قصارى جهدهم. تحقق من مشروع Dan Gerlag (https://github.com/danielgerlag/workflow-core) أو bite-the-bullet والقفز على متن قطار Azure LogicApps.

مرحبًا ، هذا هو أكتوبر 2020. أي أخبار / تحديثات / إصدارات حول Workflow Foundation على .NET Core؟

أم يجب أن ننتقل جميعًا إلى إلسا؟ https://elsa-workflows.github.io/elsa-core/

wstaelens أعتقد أن إجابة MS كانت واضحة جدًا : لن يتم نقل WF رسميًا إلى NET Core. البديل المقترح هو CoreWF .