Runtime: पोर्ट वर्कफ़्लो फाउंडेशन से .NET कोर

cc: @terrajobst , @joshfree , @weshaggard

पोर्टिंग पर गंभीर प्रयास किए जाने से पहले हमें System.Xaml को खोलने की आवश्यकता है।

मैं @jakessays को समझता हूं।

मुद्दा यह है कि WF की वर्कफ़्लो परिभाषाएँ XAML (अभी के लिए) के बजाय C# कक्षाओं में बनाई जा सकती हैं और बहुत से लोग इसके XAML प्रतिनिधित्व का उपयोग भी नहीं करते हैं। बाद में जब System.Xaml खोला जाता है, तो हम विज़ुअल डिज़ाइनर और XAML परिभाषाओं को भी एकीकृत कर सकते हैं। इसके अलावा, हमारे पास वर्कफ़्लो इंजन पर काम कर रहा है जो सख्ती से डब्ल्यूएफ उपयोग/कार्यान्वयन का पालन करता है लेकिन वर्कफ़्लो परिभाषाओं के लिए बेस स्टोरेज के रूप में एक्सएएमएल का उपयोग करने के बजाय, हमारे पास स्टोर के लिए जेसन पर आधारित है, जो किसी भी पर नए वर्कफ़्लो डिजाइनरों के लिए बहुत सारे अवसर खोलता है प्लेटफॉर्म (न केवल वीएस या डब्ल्यूपीएफ/डब्ल्यूफॉर्म के लिए होस्टेड डिजाइनर घटक) और तेजी से पढ़ने/लिखने, स्कीमा की सादगी, तेज लोडिंग/संकलन और रनटाइम संचालन के रूप में कई लाभ हैं। इसका उपयोग क्लाइंट वर्कफ़्लोज़ को सशक्त बनाने के लिए भी किया जा सकता है, उदाहरण के लिए इसके हल्के रनटाइम के कारण विंडोज़ फोन/स्टोर ऐप्स पर एप्लिकेशन UI प्रवाह को निर्देशित करने के लिए।

मुझे सच में लगता है कि डब्ल्यूएफ नेट प्लेटफॉर्म पर वास्तव में एक शक्तिशाली घटक है, लेकिन आज की प्रौद्योगिकियों के लिए, एक्सएएमएल अभी भी इसका "सीमक" है, लेकिन अगर एमएस के रणनीति निर्णय के लिए हम इसे वैसे ही रख सकते हैं और कोरसीएलआर को पोर्ट कर सकते हैं।

धन्यवाद

@zhenlan WF . के आसपास वर्तमान सोच की ओर बात कर सकते हैं

@galversibeiro बहुत से लोग xaml का उपयोग नहीं कर सकते हैं, लेकिन कई लोग करते हैं, और इसे वास्तव में WF का मुख्य भाग माना जाता है। हम बड़े पैमाने पर xaml का उपयोग करते हैं, इसलिए मैं xaml समर्थन के बिना WF को शायद ही उपयोग करने लायक देखूंगा।

मैं चाहूंगा कि हम System.Xaml को खोलने के लिए Microsoft की पैरवी करना जारी रखें।

और JSON को प्रतिस्थापन के रूप में उपयोग करना कम से कम आकर्षक नहीं है।

@galvesribeiro @jakessays हम वास्तव में यह जानना चाहते हैं कि WF के ग्राहक WF के .NET कोर संस्करण में कितनी रुचि रखते हैं, इसलिए समुदाय से प्रतिक्रिया सुनना बहुत अच्छा है। अगर पर्याप्त मांग है तो हमें आगे बढ़ने में मदद मिलेगी।

हम व्यवहार्यता, निर्भरता, फीचर प्राथमिकताओं आदि का मूल्यांकन करने के शुरुआती चरण में हैं। इसलिए यह जानना हमारे लिए बहुत मददगार होगा कि आपके दिमाग में कौन से परिदृश्य हैं, क्यों .NET कोर पर WF (बनाम WF पूर्ण .NET) होगा आपके लिए उपयोगी है और आप सबसे पहले कौन सी WF सुविधाएँ देखना पसंद करते हैं।

@galversibeiro कोड में वर्कफ़्लो बनाने और JSON के रूप में उन परिभाषाओं को संग्रहीत करने के साथ आपके परिदृश्य में, आप अभिव्यक्ति के लिए क्या (योजना बना रहे हैं?) का उपयोग कर रहे हैं? क्या आप वीबी अभिव्यक्तियों, सी # अभिव्यक्तियों का उपयोग कर रहे हैं, या क्या आपके पास अभिव्यक्तियों से निपटने के लिए कोडएक्टिविटी पर आधारित अपनी अभिव्यक्ति गतिविधियां हैं?

इनपुट के लिए धन्यवाद।

@jakesays मेरे लिए XAML का उपयोग करना ठीक है। मुझे केवल प्रदर्शन की परवाह है ...

@zhenlan हमारे पास एक इलेक्ट्रॉनिक भुगतान स्विच है जो ब्राजील में कुछ बैंकों और विदेशों में कुछ अन्य बैंकों के लिए एक दिन में अरबों क्रेडिट/डेबिट कार्ड लेनदेन की प्रक्रिया करता है। हम पूर्ण ऑन-प्रिमाइसेस थे और हम पूरी तरह से क्लाउड होने के लिए तकनीक को अपडेट कर रहे हैं, और Azure पर एक सेवा के रूप में पेश किया गया है। हमारे ग्राहकों के लिए एक बहु-किरायेदार भुगतान प्रसंस्करण मंच के रूप में यहां Azure से हमें जो कुछ भी चाहिए, उसका पता लगाने के लिए हमें एक एंटरप्राइज़ अनुबंध मिला है।

हम नैनोसर्वर और कोरसीएलआर के उपयोग की जांच कर रहे हैं ताकि हम अपनी सेवाओं को चलाने के लिए पदचिह्न, हमले की सतह और रखरखाव खर्च को कम कर सकें और हमने देखा कि कोरसीएलआर में (कम से कम) सिस्टम नहीं है। गतिविधियों को अभी तक पोर्ट किया गया है। दूसरे शब्दों में, कोई वर्कफ़्लो फ़ाउंडेशन नहीं।

हमारा कोर प्रोसेसिंग इंजन शीर्ष WF पर निर्मित एक व्यावसायिक इंजन है और इसमें हमारे व्यवसाय पर केंद्रित 40+ कस्टम गतिविधियाँ शामिल हैं। यह इंजन वास्तविक समय में लेन-देन की प्रक्रिया/नियमों को लेन-देन की स्वीकृति प्राप्त करने के लिए संसाधित करता है। हमें इसे मांग से अधिक बढ़ाने की आवश्यकता है, और क्या यह क्लाउड में WF के वर्तमान कार्यान्वयन के साथ है, मान लें कि यह संभव नहीं है।

इसे .net कोर में पोर्ट करने के बजाय, इसे .net full (सर्वर प्रोफाइल) पर रखने से क्लाइंट वर्कफ्लो चलाने की संभावनाएं खुल जाएंगी, यह ऐसी चीज है जिसे हम वास्तव में अपने व्यवसाय से चूक जाते हैं। वे क्लाइंट वर्कफ़्लो लोगों को क्लाइंट-बिज़नेस लॉजिक डिक्लेरेटिव विकसित कर सकते हैं, एक तरह से स्मार्टफोन, वियरेबल्स, IoT जैसे छोटे डिवाइस और हमारे पेमेंट टर्मिनल डिवाइस वास्तविक दोहराव वाले कोड को लिखे बिना कुछ निर्णय ले सकते हैं।

चूंकि हमें .net Core के लिए WF पर कोई प्रयास नहीं मिला, और यहां तक ​​कि यह वर्षों तक नहीं बदला और अभी भी XAML पर निर्भर करता है, हमने अपना स्वयं का वर्कफ़्लो इंजन शुरू करने का निर्णय लिया जो ठीक उसी तरह से व्यवहार करता है जैसे WF करता है। वही गतिविधियां मॉडल, समान कोड शैली, आदि, लेकिन बहुत हल्का और जेसन पर उनकी परिभाषा स्टोर के रूप में आधारित है। यह छोटे कंप्यूट पावर वाले उपकरणों को एक्सएएमएल/एक्सएमएल से निपटने के ओवरहेड के बिना वर्कफ़्लो को संसाधित करने की अनुमति देता है, इसलिए डब्ल्यूएफ के लिए बनाया गया हमारा अधिकांश कोड एक्सएएमएल-आधारित वर्कफ़्लो के बजाय जेसन परिभाषाओं पर कई बदलावों के बिना काम कर रहा है। साथ ही, एक्सएएमएल से दूर जाने से, नए वर्कफ़्लो डिज़ाइनरों के लिए संभावना खुल जाएगी... वीएस डिज़ाइनर को फिर से होस्ट करने के लिए विजुअल स्टूडियो और डब्ल्यूपीएफ अनुप्रयोगों पर अटका नहीं है।

मैं जो सुझाव देने की कोशिश कर रहा हूं वह उन विकल्पों में से एक है:

1. पोर्ट डब्ल्यूएफ (एक्सएएमएल के साथ) जैसा कि नेट कोर के लिए है। इस विकल्प में बहुत अधिक समय लगेगा क्योंकि WF आज .Net के सर्वर प्रोफाइल पर निर्भर करता है, जिससे हमें इसे .Net कोर के साथ काम करने के लिए इसे डिकूप करने में बहुत समय लगेगा।
2. पोर्ट WF इसे .Net कोर पर फिर से लिख रहा है। इस तरह, हम मूल अवधारणाओं को प्राप्त कर सकते हैं और एक अधिक हल्के इंजन को डिज़ाइन करने पर ध्यान केंद्रित कर सकते हैं जो सर्वर, क्लाइंट, IoT या जो कुछ भी डिज़ाइन सिद्धांतों और वर्तमान में WF पर लागू की गई सुविधाओं को ध्यान में रखते हुए आवश्यक है, पर चल सकता है। इस तरह हम XAML से (उदाहरण के लिए) Json आधारित वर्कफ़्लो परिभाषाओं में माइग्रेट करने के लिए इसे वास्तव में छोटा प्रयास और घर्षण-रहित प्रक्रिया बनाते हैं। सभी मौजूदा गतिविधियों को नए मॉडल में पोर्ट किया जाना चाहिए।

मैं आपको एक टीम बनाने या किसी नए उत्पाद में खुद को शामिल करने के लिए नहीं कह रहा हूं। समुदाय ऐसा कर सकता है जैसे वे ASP.Net और Entity Framework के लिए कर रहे हैं। इसे एक बाहरी और सहायक ढांचा बनाएं, कोर पर एम्बेडेड नहीं।

धन्यवाद

@jimcarley अभिव्यक्तियों को उसी तरह संकलित किया जाएगा जैसे वे आज एक्सएएमएल पर हैं। हमारे वर्कफ़्लो में से एक में हमारे पास यह है (यह एक वीबीवैल्यू भी हो सकता है, बस एक नमूना मिला है):
<mca:CSharpValue x:TypeArguments="x:Boolean">emvFinishOutputParameters == null || emvFinishOutputParameters.Decision == EMVFinishDecision.DeniedByCard</mca:CSharpValue>

आज एक्सएएमएल पर एक्सप्रेशन, ज्यादातर बूलियन लौटा रहे हैं, या कुछ वैरिएबल को कुछ वैल्यू असाइन करते हैं, इसलिए इसे उसी तरह से स्टोर किया जाएगा जैसे आज एक्सएएमएल पर स्टोर किया जाता है, लेकिन जेसन में और इसे उसी विचारों के बाद संकलित किया जा सकता है। आज।

यदि आप Azure संसाधन प्रबंधक (ARM) को देखें, तो उन्होंने पहले ही ऐसा कर लिया है! उनके पास Json टेम्प्लेट के रूप में संसाधन परिनियोजन है, जिसमें निर्भरता और प्रवाह है, और चर को अभिव्यक्ति के रूप में कहा जा सकता है। इस पर एक नज़र डालें:

"चर": {
"स्थान": "[संसाधन समूह ()। स्थान]",
"usernameAndPassword": "[concat('parameters('username'), ':', पैरामीटर्स('password'))]",
"AuthorizationHeader": "[concat('Basic', base64(variables('usernameAndPassword')))]"
}

ठीक है, वे जावास्क्रिप्ट फ़ंक्शन का उपयोग कर रहे हैं लेकिन सिद्धांत समान है। उनके पास टेम्पलेट के शीर्ष पर एक $schema चर है जो दस्तावेज़ संरचना, परिनियोजन प्रक्रिया के चरणों का मार्गदर्शन करता है जिसे हम गतिविधियों के रूप में बना सकते हैं। डिज़ाइन WF के समान ही है लेकिन यह DSL संसाधन समूह परिनियोजन पर केंद्रित है। हम इसे और अधिक सामान्य बना सकते हैं, और गतिविधियों का उपयोग उसी तरह कर सकते हैं जैसे वे वर्तमान WF कार्यान्वयन में करते हैं।

यदि आप लोग निर्णय लेते हैं कि यह एक शॉट के लायक है, तो हम किसी अन्य मुद्दे पर कुछ दस्तावेज तैयार करना शुरू कर सकते हैं जो "नए डब्ल्यूएफ" की वास्तुकला का मार्गदर्शन करेगा। अगर यह इतना पागल लगता है और आपकी योजनाओं से बाहर है तो मुझे बताएं, हम अभी भी इसे .net कोर का समर्थन करने के लिए विकसित करेंगे, और इसे बाद में लोगों के लिए एक नगेट के रूप में जारी करेंगे। मैं बस इस अद्भुत ढांचे को वर्तमान (आगामी) प्रौद्योगिकियों के साथ अद्यतित करने की कोशिश कर रहा हूं। यह वास्तव में हमारे लिए एक व्यावसायिक आवश्यकता है। हम WF पर बहुत अधिक निर्भर करते हैं, लेकिन अगर यह तेज़ नहीं होता है और coreCLR पर समर्थित नहीं होता है, तो हमें इस नए ढांचे को तैयार करना शुरू करना होगा ताकि जब NanoServer+coreCLR RTM हो, तो हम इसके लिए आगे बढ़ सकें।

कृपया मुझे बताएं कि क्या आपके कोई प्रश्न हैं।

धन्यवाद

पीएस: अगर आपको चैट की ज़रूरत है तो मैं हर दिन गटर चैनलों पर हूं।

@galversribeiro तो आप JSON में संग्रहीत वर्कफ़्लो परिभाषा से गतिविधि ऑब्जेक्ट बनाने के बाद अभिव्यक्तियों को संकलित करने के लिए TextExpressionCompiler का उपयोग कर रहे हैं। सही?

@jimcarley हमारे पास अभी तक अभिव्यक्ति संकलक काम नहीं कर रहा है। हम अभी भी TextExpressionCompiler के समान सिद्धांतों का उपयोग करके इसे डिज़ाइन कर रहे हैं लेकिन हाँ, यह बहुत ही समान अवधारणा जैसा दिखता है। वर्तमान कार्यान्वयन ऐसा लगता है कि अभी तक System.XAML से जुड़ा हुआ है। चूंकि यह खुला नहीं है, इसलिए मैं पुष्टि नहीं कर सकता कि टेक्स्टएक्सप्रेस कॉम्पाइलर के समान ही (आंतरिक रूप से) काम करेगा, लेकिन हां, गतिविधि लोड होने के बाद, हमें अभिव्यक्तियों का मूल्यांकन/संकलन करना चाहिए (यदि पहले से कैश में नहीं है) और एक अभिव्यक्ति वस्तु का पर्दाफाश करें उस पर गतिविधि के उपभोक्ताओं द्वारा मूल्यांकन किया जाएगा (यदि आवश्यक हो)।

पिछले साल मैंने स्व-होस्ट किए गए डब्ल्यूएफ डिजाइनरों में सी # अभिव्यक्ति समर्थन को सक्षम करने के लिए अभिव्यक्ति पक्ष पर कुछ काम किया था। यह nrefactory और roslyn के बिट्स पर आधारित था। अगर किसी को दिलचस्पी है तो मैं इसे खोद सकता हूं।

@galversibeiro आपके जेसन दृष्टिकोण पर और सोचने के बाद, अंत में मुझे लगता है कि यह वास्तव में नए विकास के लिए कोई फर्क नहीं पड़ता। यदि MS xaml सपोर्ट नहीं खोलेगा तो यह काम कर सकता है।

@zhenlan मैं @galversribeiro से सहमत हूं कि हम जरूरी नहीं कि MS को WF पोर्ट करने के लिए एक टीम बनाने के लिए देख रहे हों। यह निश्चित रूप से कुछ ऐसा है जो समुदाय आपकी टीम आदि के मार्गदर्शन से कर सकता है।

@jakesays मैं आपसे सहमत हूं कि भंडारण वास्तव में कोई फर्क नहीं पड़ता अगर हम कोरक्लर के लिए फिर से डब्ल्यूएफ बना रहे हैं।

मुद्दा यह है कि, Json के बजाय XML का उपयोग क्यों करते रहें क्योंकि हमारे पास वेब के चारों ओर कई परीक्षण हैं जो दोनों के (डी) क्रमांकन प्रदर्शन की तुलना करते हैं और json बहुत तेज है और इससे कम संसाधनों का उपभोग करते हैं? (उदाहरण के लिए न्यूटनसॉफ्ट के Json.Net की तुलना नियमित एक्सएमएल सीरिएलाइज़र) यदि डब्ल्यूएफ एक छोटे पदचिह्न क्लाइंट डिवाइस (किसी भी आईओटी) पर चलता है, तो प्रत्येक मेमोरी बाइट मायने रखती है।

इसके अलावा, जेसन के साथ, नए वेब आधारित डब्ल्यूएफ डिजाइनरों को तुरंत प्राप्त करना बहुत आसान है। अभिव्यक्ति संकलन और निष्पादन को लागू करना कठिन नहीं है। यह एक्सप्रेशन ऑब्जेक्ट बनाने के लिए मोटे तौर पर स्ट्रिंग का एक पार्सर है। कठिन हिस्सा (imho), WF को डिजाइन करते समय उपयोग किए जाने वाले प्रकारों के लिए VS पर इंटेलिजेंस प्राप्त करना है, लेकिन मुझे पूरा यकीन है कि Roselyn और भाषा सेवाएं इसमें हमारी मदद कर सकती हैं और VS के पास इसके लिए बुनियादी ढांचा है।

@galversibeiro आप उल्लेख करते हैं कि आपने JSON- आधारित वर्कफ़्लो परिभाषा और क्रमांकन के साथ अपना स्वयं का वर्कफ़्लो इंजन पहले ही बना लिया है। यदि WF को Core में पोर्ट किया जाता, तो क्या आप वास्तव में इसका उपयोग करते?

@dmetzgar हमने इसे प्रूफ-ऑफ-कॉन्सेप्ट के रूप में विकसित करना और परीक्षण करना शुरू कर दिया है कि हम एक क्लीनर WF में बेहतर परिणाम प्राप्त कर सकते हैं, जिसमें ढांचे पर लगभग कोई निर्भरता नहीं है, जो इसे coreclr पर काम करने के लिए अच्छा है। हमारे पास यह तैयार नहीं है।

मुझे अपना खुद का इंजन बनाने और डब्ल्यूएफ का उपयोग करना पसंद नहीं है, भले ही यह एक्सएएमएल पर आधारित हो, लेकिन कोरक्लर को पोर्ट किया गया हो और यदि यह एंटिटीफ्रेमवर्क और एएसपी. सर्वर पुस्तकालय और हर जगह चलता है)।

मुद्दा यह है, अगर यह अभी भी एक्सएएमएल और सर्वर प्रोफाइल पर निर्भर करेगा, तो यह धीमा रहेगा (बहुत अधिक संसाधनों की आवश्यकता है), डिजाइनर विकल्पों पर सीमित, आदि।

मेरा सुझाव है कि इसे Json का उपयोग करके कोरक्लर में पोर्ट किया जाए, और बहुत सारी निर्भरता को दूर किया जाए जो आज उपयोगकर्ता को इसे कहीं भी चलाने में सक्षम छोड़ रही है, वे उसी तरह चाहते हैं जैसे आप IoT ARM डिवाइस पर ASP.Net vNext चला सकते हैं (जल्द ही ARM समर्थन के रूप में) हो गया है!) और निर्भरता और उच्च संसाधन खपत के बारे में चिंता न करें।

आज हमारे सभी कार्यप्रवाह वर्तमान संस्करण के साथ बनाए गए हैं जिनमें से कुछ शुद्ध कोड के साथ लिखे गए हैं और कुछ एक्सएएमएल बुथ के साथ दोनों मामलों में, हमारे पास अभी भी निर्भरताएं हैं।

आईएमएचओ, इसे कोरक्लर के रूप में पोर्ट करता है, जब तक कि कोई व्यक्ति एक्सएएमएल/एक्सएमएल पार्सिंग/रनटाइम और डिज़ाइन समय दोनों के लिए प्रतिपादन के लिए सुपर न्यू लाइटवेट इंजन के साथ नहीं आता है, तब तक इतना लाभ नहीं लाता है। लेकिन अगर आप लोग पोर्ट करने का निर्णय लेते हैं, तो हम इसे वैसे भी इस्तेमाल करते रहेंगे, क्योंकि यह मेरे एक्सएएमएल वर्कफ़्लोज़ को 0 दिन से काम करेगा (मुझे आशा है), भले ही मुझे पता हो कि यह कोई व्यावहारिक लाभ नहीं लाएगा ...

दोबारा, मैं (शायद @jakesays और अन्य डब्ल्यूएफ उपयोगकर्ता) इस बंदरगाह पर दोनों तरीकों से मदद कर सकता हूं (एक्सएएमएल या जेएसओएन) चाहे आप लोग तय करें। मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि यह पोर्ट इसे काम करने के लिए सिर्फ कॉपी और पेस्ट और फिक्स नहीं है, और इसके बजाय, यह उन लोगों के लिए वास्तव में लाभ लाता है जो इसे कोरक्लर के समान विचार का उपयोग कर रहे हैं और यह बिना दर्द के हर जगह चल सकता है।

धन्यवाद

@galversibeiro मैं मानता हूं कि एक्सएएमएल डब्ल्यूएफ में बहुत कसकर एकीकृत है। वर्कफ़्लो पर धर्म की मूल पुस्तक पर वापस जाने पर, उनके पास एक नमूना था जिसने Visio से वर्कफ़्लो बनाया था। कम से कम कोर को पोर्ट करने के साथ, हम इसे तराश सकते हैं ताकि रनटाइम XAML से अलग हो। यह हमें XAML टीम को कोर में पोर्ट करने के साथ या उसके बिना आगे बढ़ने की अनुमति देता है और हम हमेशा XAML वर्कफ़्लो समर्थन को बाद में एक अलग GitHub प्रोजेक्ट/NuGet पैकेज के रूप में जोड़ सकते हैं। मैं निश्चित रूप से किसी भी प्रारूप में कार्यप्रवाह को परिभाषित करना और उसे जारी रखना संभव बनाने के लिए हूं। धन्यवाद, यह प्रतिक्रिया सहायक है।

@dmetzgar मुझे कोई संदेह नहीं है कि किसी दिन XAML को कोर में पोर्ट किया जाएगा ... यदि .net कोर विंडोज़ फोन या किसी विंडोज़ 10 मोबाइल डिवाइस पर चलने वाला है, तो यह किसी समय होगा और मैं आपसे पूरी तरह सहमत हूं कि हम निर्माण कर सकते हैं एक नया कोर, और बाद में भी दोनों परिभाषाओं और वर्कफ़्लो की स्थिति की दृढ़ता जोड़ें।

तो, इसे पोर्ट करना शुरू करने के लिए हमें क्या करने की आवश्यकता है? (हमने पहले से ही योगदानकर्ता समझौते पर हस्ताक्षर किए हैं और एमएस, आदि के साथ एक कंपनी के रूप में अन्य एनडीए हैं)

धन्यवाद

@galvesribeiro मैं उत्साह की सराहना करता हूं! GitHub रेपो खोलना और हैकिंग शुरू करना जितना आकर्षक है, इसमें कुछ चरण शामिल हैं। इसके अलावा, यह केवल System.Xaml ही नहीं है जिसे उकेरा जाना है। WF में अन्य निर्भरताएँ गहरी हैं जैसे System.Transactions और WCF के साथ कुछ साझा घटक। हम इनमें से प्रत्येक की जांच कर रहे हैं।

मैं समझता हूं। खैर, मैं आप लोगों को धक्का नहीं देना चाहता, मुझे बस समय की चिंता है। हमारे पास अब अपने दम पर निर्माण को आगे बढ़ाने, या यहां समुदाय में शामिल होने और WF को coreCLR में पोर्ट करने का निर्णय है ताकि यह हमारे उत्पाद के लिए हमारी समयरेखा को पूरा कर सके।

@dmetzgar क्या आपने उन हिस्सों को प्रकाशित करने पर विचार किया है जिन्हें अभी ओपन सोर्स किया जा सकता है https://github.com/Microsoft/referencesource? मुझे लगता है कि एक पूर्ण ओपन सोर्स प्रोजेक्ट बनाने से काफी आसान हो सकता है जो वास्तव में काम करता है।

इस तरह, आप अपना समय उचित संस्करण के साथ ले सकते हैं, और अन्य लोग इस बीच अपने स्वयं के आंशिक/कस्टम संस्करण बना सकते हैं।

@svick WF घटक पूर्ण .NET में कुछ समय पहले ही github संदर्भ स्रोत पर प्रकाशित हो चुके हैं। उदाहरण के लिए, आप https://github.com/Microsoft/referencesource/tree/master/System.Activities पा सकते हैं

@zhenlan हाँ, इसके साथ समस्या यह है कि कुछ निर्भरताएँ "समाधान योग्य" नहीं हैं ... मैं नहीं देख सकता कि सिस्टम पर निर्भरता के कारण कुछ वर्गों का व्यवहार सही ढंग से क्या है। Xaml जो सार्वजनिक नहीं है ...

हम हमेशा अपने अंत तक पता लगा सकते हैं, लेकिन इसका मतलब यह होगा कि हम निश्चित रूप से नहीं जानते कि हम उसी तरह से चल रहे हैं या नहीं।

@dmetzgar System.Transaction कुछ ऐसा है जो खुला नहीं है (अभी तक?), लेकिन मुझे लगता है कि हम इससे (अभी के लिए) निपट सकते हैं। डब्ल्यूसीएफ के संबंध में, निर्भरता पेड़ केवल मुझे गतिविधियां और वर्कफ़्लो सर्विसेज होस्ट दिखाता है। कोर (आईआईआरसी) पर कुछ भी डब्ल्यूसीएफ पर निर्भर नहीं है ...

@galversibeiro System.Transactions की स्थिति उससे कहीं अधिक जटिल है। यह पूरे WF रनटाइम में छिड़का हुआ है और टिकाऊ इंस्टेंसिंग पर बहुत अधिक निर्भर है, जहां आधार वर्ग दृढ़ता के लिए हैं। WCF और WF को .Net 4.0 समय सीमा के आसपास एक ही टीम में मिला दिया गया था, इसलिए हमारे पास System.ServiceModel.Internals जैसी चीजें हैं जिनका उपयोग WCF और WF दोनों द्वारा किया जाता है। नेट कोर में बहुत सी बड़ी चीजें पोर्ट की गई हैं, लेकिन बहुत कुछ ऐसा है जो गायब है। लापता टुकड़ों के आसपास काम करने के लिए डिज़ाइन परिवर्तन या सुविधाओं के पुनर्लेखन की आवश्यकता हो सकती है।

इनमें से कोई भी समस्या दुर्गम नहीं है, मैं केवल प्रयास को तुच्छ नहीं बनाना चाहता। यह कोड और उसके आस-पास की हर चीज के लिए जाता है जैसे कानूनी स्वीकृति प्राप्त करना, वातावरण बनाना, बुनियादी ढांचे का परीक्षण करना, आदि। हम निश्चित रूप से समुदाय की मदद करना चाहते हैं और हम उस दिशा में काम कर रहे हैं। आपको अपना पोर्ट लिखना चाहिए या "आधिकारिक" की प्रतीक्षा करनी चाहिए, यह आपकी समय सीमा पर निर्भर करता है। नैनो सर्वर पर कार्यप्रवाह चलाना हमारे सबसे बड़े परिदृश्यों में से एक है और मुझे इस पर आपकी सहायता प्राप्त करना अच्छा लगेगा।

@dmetzgar मैं समझ गया, हमेशा कुछ देरी होती थी जब किसी भी प्रश्न को पीआर या कानूनी के लिए आगे बढ़ना पड़ता था जब मैं आपकी तरफ था :)

ठीक है, अगर कम से कम हमारे पास कुछ समय सीमा की धारणा है, तो हम खुद को तैयार कर सकते हैं और इसके लिए इंतजार कर सकते हैं। मुझे "गलत जगह" में कुछ लागू करने के विचार से नफरत है या जब पहले से ही कुछ प्रयास किए जा रहे हैं कि हम बेहतर करने के लिए सेना में शामिल हो सकें।

कृपया मुझे बताएं कि क्या ऐसा कुछ है जो हम कर सकते हैं, या यदि आपके पास कोई समाचार है, या मुझे पिंग करें यदि आपको डिज़ाइन/पोर्ट के संबंध में कोई सुझाव चाहिए।

धन्यवाद

जैसे-जैसे समय सीमा स्पष्ट होती जाएगी, मैं इस थ्रेड पर अपडेट करूंगा। मुझे यह जानकर खुशी होगी कि लोग किन अन्य परिदृश्यों में रुचि रखते हैं। नैनो पर WF अभी प्राथमिक परिदृश्य है, लेकिन यह जानना अच्छा होगा कि दूसरे क्या कर रहे हैं।

हाय दोस्तों, एक्सएएमएल और जेएसओएन के अलावा, गतिविधियों को लिखने का एक अच्छा तरीका है: मेटाप्रोग्रामिंग। मेरे प्रायोगिक प्रोजेक्ट पर एक नज़र डालें: Metah.W: एक वर्कफ़्लो मेटाप्रोग्रामिंग लैंग्वेज (https://github.com/knat/Metah)।

@jakesays क्या आप स्वयं-होस्ट किए गए डब्ल्यूएफ में सी # अभिव्यक्ति समर्थन को सक्षम करने के बारे में कुछ मार्गदर्शन प्रदान कर सकते हैं।

कृपया Xaml रखें। :) JSON क्रमबद्ध वस्तुएं भी दिलचस्प होंगी। लेकिन मैं उन प्रदाताओं को देखना पसंद करूंगा जो पसंदीदा प्रारूप चुनने के लिए ढांचे में किसी भी तरह कॉन्फ़िगर किए गए हैं।

@dmetzgar (और अन्य MSFT लोग) क्या इस विषय के बारे में कोई खबर है?
धन्यवाद

हम इस पर काम कर रहे हैं और काफी प्रगति की है। एक्सएएमएल वर्तमान में कोर में उपलब्ध नहीं है इसलिए हम रनटाइम पर ध्यान केंद्रित कर रहे हैं। हम अन्य धारावाहिकों को खोलने पर विचार कर रहे हैं। इसलिए JSON या XAML के बीच पक्ष चुनने के बजाय, हम आपको अपना स्वयं का धारावाहिक लाने की अनुमति देना पसंद करेंगे। स्वीकृत होने के लिए अभी और अनुपालन और कानूनी चीजें हैं। चूंकि बहुत सारे ग्राहक इस बंदरगाह पर जोर नहीं दे रहे हैं, इसलिए यह कम प्राथमिकता रही है।

@dmetzgar मीठा! मुझे इसमें योगदान करने में अधिक खुशी होगी, हालांकि अगर यह एक मुख्य परियोजना बन जाती है ... चाहे वह एक वेब वर्कफ़्लो डिज़ाइनर हो आदि। ऐसा लगता है कि xaml को परिभाषा प्रारूप के लिए शायद ही वहां होने की आवश्यकता है ... सुनने के लिए उत्साहित इस काम के बारे में!

हैलो दोस्तों, मेरी क्रिसमस और नया साल मुबारक हो!

तो, क्या हमारे पास उस पोर्ट पर कोई अपडेट है या कम से कम वर्तमान कार्य का ओएसएस रिलीज है ताकि हम इसमें मदद कर सकें?

धन्यवाद

@galvesribeiro मैं स्थिति को यथासंभव समझाने की कोशिश करूंगा। WF को .NET कोर में पोर्ट कराने के अपने उत्साह में, मैं इस पूरी चीज़ के व्यावसायिक पक्ष को ध्यान में रखने में विफल रहा। डब्ल्यूपीएफ/एक्सएएमएल को .NET कोर में पोर्ट नहीं किया गया है और यह डब्ल्यूएफ के एक महत्वपूर्ण हिस्से का प्रतिनिधित्व करता है। जबकि XAML रनटाइम के लिए आवश्यक नहीं है, यह है कि अधिकांश ग्राहक वर्कफ़्लो कैसे बनाते हैं। यह दर्शकों को सीमित करता है जो कोर पर WF को उपयोगी पाएंगे। आशंकाओं में से एक यह है कि हम कोर पर डब्ल्यूएफ जारी करते हैं और इसमें समुदाय की ज्यादा भागीदारी नहीं होती है। यह हमारी समर्थन लागत में वृद्धि करता है और अधिकांश WF ग्राहकों की स्थिति में सुधार नहीं करता है। जबकि WF को Linux मशीन पर चलाना अच्छा लगता है, यह साबित करना कठिन है कि कोई भी वास्तव में इसका उपयोग करेगा।

मैं OmniXAML से अवगत हूं और हम लेखक को MIT लाइसेंस में बदलने के लिए मनाने में कामयाब रहे हैं। तो कुछ निवेश के साथ हम संभावित रूप से एक्सएएमएल काम कर सकते हैं। लेकिन अभी भी यह सवाल है कि यह मौजूदा WF ग्राहकों को कैसे लाभ पहुंचाता है। यदि एक दिन SharePoint या Dynamics जैसा कोई बड़ा ग्राहक साथ आता है और कहता है कि वे नैनो में जा रहे हैं, तो हमारे पास एक सम्मोहक मामला होगा। यदि .NET Framework टीम एक ऐसा पैकेज बनाने का निर्णय लेती है जो नैनो पर पूर्ण ढांचे को चला सकता है, तो यह सब विवादास्पद है।

यदि पर्याप्त सामुदायिक हित और परियोजना को चैंपियन बनाने के इच्छुक कोई व्यक्ति था, तो हम इसे इस तरह से करने का प्रयास कर सकते थे। ओपन लाइव राइटर की तरह। मुश्किल बात यह है कि मेरी टीम इसमें यथासंभव योगदान देगी, लेकिन उस तरह की परियोजना Microsoft समर्थन के साथ नहीं आएगी। मुझे संदेह है कि अधिकांश WF ग्राहक मुख्य रूप से WF का उपयोग करते हैं क्योंकि Microsoft इसका समर्थन करता है।

मुझे लगता है कि यह उजागर करना महत्वपूर्ण है कि .NET कोर और पूर्ण .NET फ्रेमवर्क दो अलग-अलग उत्पाद हैं। .NET Framework किसी भी तरह से खत्म नहीं हो रहा है। हम इसका समर्थन करना जारी रखेंगे, सुविधाओं को जोड़ेंगे, आदि। इसलिए ऐसा नहीं है कि हमें इसे जीवित रखने के लिए डब्ल्यूएफ को .NET कोर में पोर्ट करना होगा। कोर पर WF मूल रूप से एक नया उत्पाद होगा। एक ठोस व्यावसायिक औचित्य के साथ आना मुश्किल है। यह समय का मुद्दा भी हो सकता है। जैसे-जैसे अधिक कंपनियां नैनो सर्वर अपनाती हैं, एक मजबूत मामला हो सकता है।

@dmetzgar पोर्टेबल.एक्सएमएल के बारे में कैसे, क्या यह एक विकल्प हो सकता है? https://github.com/cwensley/Portable.Xaml इसे Eto के लिए शानदार Eto.Forms प्रोजेक्ट के लेखक द्वारा उपयोग के लिए निकाला गया है। यह एमआईटी लाइसेंस प्राप्त है और (और मोनो प्रोजेक्ट से प्राप्त होने वाले वर्ग पुस्तकालय भी हैं)।

@dmetzgar ,

मैं स्थिति को यथासंभव समझाने की कोशिश करूंगा। WF को .NET कोर में पोर्ट कराने के अपने उत्साह में, मैं इस पूरी चीज़ के व्यावसायिक पक्ष को ध्यान में रखने में विफल रहा। डब्ल्यूपीएफ/एक्सएएमएल को .NET कोर में पोर्ट नहीं किया गया है और यह डब्ल्यूएफ के एक महत्वपूर्ण हिस्से का प्रतिनिधित्व करता है। जबकि XAML रनटाइम के लिए आवश्यक नहीं है, यह है कि अधिकांश ग्राहक वर्कफ़्लो कैसे बनाते हैं। यह दर्शकों को सीमित करता है जो कोर पर WF को उपयोगी पाएंगे। आशंकाओं में से एक यह है कि हम कोर पर डब्ल्यूएफ जारी करते हैं और इसमें समुदाय की ज्यादा भागीदारी नहीं होती है। यह हमारी समर्थन लागत में वृद्धि करता है और अधिकांश WF ग्राहकों की स्थिति में सुधार नहीं करता है। जबकि WF को Linux मशीन पर चलाना अच्छा लगता है, यह साबित करना कठिन है कि कोई भी वास्तव में इसका उपयोग करेगा।

मुझे लगता है कि WF के वर्तमान उपयोगकर्ताओं के लिए सबसे बड़ी प्रेरणा नैनो सर्वर और माइक्रो सर्विसेज है न कि लिनक्स। Linux अधिक उपयोगकर्ताओं को जोड़ेगा, लेकिन यह वास्तविक प्रेरणा नहीं है।

लेकिन अभी भी यह सवाल है कि यह मौजूदा WF ग्राहकों को कैसे लाभ पहुंचाता है।

हम बादल के दिनों में हैं। याद रखें, "क्लाउड फर्स्ट, मोबाइल फर्स्ट..." और जो बड़ी तकनीकें विकसित हो रही हैं उनमें से एक कंटेनर, माइक्रो सर्विसेज, और सभी के लिए एमएस की एक बड़ी पेशकश नैनो सर्वर है।

यदि एक दिन SharePoint या Dynamics जैसा कोई बड़ा ग्राहक साथ आता है और कहता है कि वे नैनो में जा रहे हैं, तो हमारे पास एक सम्मोहक मामला होगा।

यहां तक ​​कि धरती पर सबसे बड़े शेयरपॉइंट या डायनेमिक्स परिनियोजन के साथ, हम कभी भी उपयोगकर्ताओं की समान संख्या तक नहीं पहुंचेंगे और मैं यहां तक ​​​​कि क्लाउड तकनीक के साथ किए जा रहे राजस्व की तुलना में समान स्तर का राजस्व भी कहूंगा।

यदि .NET Framework टीम एक ऐसा पैकेज बनाने का निर्णय लेती है जो नैनो पर पूर्ण ढांचे को चला सकता है, तो यह सब विवादास्पद है।

DNX आज (जहाँ तक RC1) है, उसमें न केवल coreCLR शामिल है। इसका पूरा ढांचा भी है (dnx451) इसलिए हम वर्तमान में DNX पर WF का उपयोग कर सकते हैं और यह यहाँ इस मुद्दे के बारे में नहीं है। हम बात कर रहे हैं coreCLR (dnxcore50)

यदि पर्याप्त सामुदायिक हित और परियोजना को चैंपियन बनाने के इच्छुक कोई व्यक्ति था, तो हम इसे इस तरह से करने का प्रयास कर सकते थे। ओपन लाइव राइटर की तरह।

मैं इसकी तुलना ओपन लाइव राइटर पर किए गए कार्यों से नहीं करूंगा... मुझे लगता है कि यह कमोबेश वही है जो ASP.Net, MVC, Entity Framework के साथ बनाया गया था। .Net परिवार से मूल "उत्पाद" और वह आज खुला स्रोत है।

मुश्किल बात यह है कि मेरी टीम इसमें यथासंभव योगदान देगी, लेकिन उस तरह की परियोजना Microsoft समर्थन के साथ नहीं आएगी। मुझे संदेह है कि अधिकांश WF ग्राहक मुख्य रूप से WF का उपयोग करते हैं क्योंकि Microsoft इसका समर्थन करता है।

वास्तव में WF ग्राहक MS समर्थन अनुबंधों का उपयोग करते हैं... विशेष रूप से Dynamics और Sharepoint ग्राहक ऐसा करते हैं, हालाँकि, इस दुनिया के बाहर बहुत सारे अनुप्रयोग हैं जिन्हें अभी भी समर्थन की आवश्यकता है। यह कहना कि लोग केवल समर्थन के कारण इसका उपयोग करते हैं और OSS समर्थित नहीं है, लगभग यही कहना है कि CoreCLR, EF, ASP.Net को MS का समर्थन नहीं मिलेगा। हालांकि वे परियोजनाएं अब ओएसएस हैं, वे एमएस टीमों द्वारा भारी निगरानी और संचालित की जाती हैं।

उदाहरण के लिए, मैंने एमएस ऑरलियन्स प्रोजेक्ट पर एक उपयोगकर्ता के रूप में शुरुआत की। यह लगभग 7 वर्षों के लिए सभी हेलो क्लाउड सेवाओं को शक्ति प्रदान करता है। स्काइप, आउटलुक, और कई अन्य एमएस सार्वजनिक/क्लाउड सेवाएं किसी भी तरह इसका उपयोग करती हैं। कुछ साल पहले, MS Research से OSSed किया गया था और अब 343 Studios, MSR के कुछ लोग, और MS के अंदर अन्य समूहों के कुछ अन्य लोगों द्वारा बनाए रखा जाता है, लेकिन ज्यादातर समुदाय द्वारा बनाए रखा जाता है। आज, मैं खुद को उस परियोजना में एक सक्रिय योगदानकर्ता मानता हूं और मैं वहां अन्य एमएस और गैर-एमएस लोगों के साथ नए उपयोगकर्ता का समर्थन करता हूं। हमारे पास ऑरलियन्स के लिए जीएच टीम के अंदर पूर्व (मेरे जैसे) और गैर-एमएस कर्मचारी भी हैं। क्या इसका मतलब यह है कि हमारे पास समर्थन नहीं है? ठीक है, मैंने ऑरलियन्स नहीं खरीदा है, इसलिए मैं कानूनी तौर पर ऑरलियन्स के लिए एमएस के साथ अपने अनुबंधों के अंदर समर्थन मांगता हूं, हालांकि, मैं नेट फ्रेमवर्क या किसी अन्य उत्पाद को लक्षित करके ऐसा कर सकता हूं, मैं वास्तव में आपके कथन से सहमत नहीं हूं।

एक ठोस व्यावसायिक औचित्य के साथ आना मुश्किल है।
यदि आप केवल शेयरपॉइंट और डायनेमिक्स ग्राहकों की तलाश करते हैं तो मैं आपसे सहमत हूं।

ठीक है, हम, दुनिया भर की कई अन्य कंपनियों की तरह, उन अनुबंधों पर अधिकांश परिवर्तनशील उत्पादों का उपयोग करके Microsoft के साथ बड़े उद्यम समझौते (EA) को बनाए रखते हैं। हमारे मामले में, हम प्रति दिन लाखों वित्तीय (क्रेडिट/डेबिट कार्ड) लेनदेन संसाधित करते हैं और हर एक ऑरलियन्स के शीर्ष पर और Microsoft Azure के अंदर चल रहे WF के एक उदाहरण का प्रतिनिधित्व करता है। मुझे नहीं पता कि व्यावसायिक औचित्य के रूप में कार्य करने के लिए आपके लिए क्या बड़ा होगा।

मुझे लगता है कि कोर (सिस्टम। एक्टिविटीज), एक्सएएमएल के बिना, कोरसीएलआर में पोर्ट किया जा सकता है और डिजाइनरों को एक्सएएमएल, जेसन, एचटीएमएल, एक्सएमएल, कुछ भी मांग पर बनाया जा सकता है। इस निर्भरता को अलग करने से अन्य संभावनाएं खुलती हैं।

जैसा कि मैंने इस धागे की शुरुआत में कहा था, अब हम जो सबसे भारी काम चाहते हैं, वह यह है कि इसे OSSed प्राप्त करें और MSFT से कोई (कम से कम शुरुआत में) PR की समीक्षा के लिए उपलब्ध हो जाए। यहां सामान्य ज्ञान WF को फिर से लिखना है और न केवल इसे coreCLR के लिए कॉपी और पेस्ट करना है, इसलिए हम उस पर बड़े योगदान की उम्मीद करेंगे।

अगर ऐसा कुछ नहीं होने वाला है, तो मुझे लगता है कि हम इस मुद्दे को बंद कर सकते हैं और कम से कम लोग अन्य ओएसएस या यहां तक ​​कि भुगतान किए गए वर्कफ़्लो इंजन की तलाश शुरू कर देंगे जो अंततः कोरसीएलआर समर्थन प्राप्त करेंगे। मुझे लगता है कि यह एक बड़ा खो गया है, इसे CoreCLR के अंदर न रखें ...

मैं एक बहुत मजबूत कारण बता सकता हूं कि WF को .Net Core में क्यों पोर्ट किया जाना चाहिए।

Microsoft डेवलपर्स को UWP प्लेटफॉर्म की ओर ले जा रहा है। UWP भविष्य का विंडोज प्लेटफॉर्म होगा। इसका लिनक्स आदि में ऐप्स पोर्ट करने के हवादार परी विचार से कोई लेना-देना नहीं है। विंडोज 10 मशीनों पर डब्ल्यूएफ चलाने की सख्त जरूरत है, और यूडब्ल्यूपी विंडोज 10 प्लेटफॉर्म के लिए भविष्य है।

हम कभी-कभी कनेक्टेड ऐप्स बनाते हैं। हमारे पास एक .Net बैक एंड और एक UWP फ्रंट एंड है। वर्तमान में, सभी व्यावसायिक तर्क .Net और UWP पर साझा किए जाते हैं। लेकिन, हम WF में बिजनेस लॉजिक को सॉफ्ट कोड करना चाहते हैं। यह नेट में ठीक काम करेगा, लेकिन WF वर्तमान में UWP द्वारा समर्थित नहीं है, इसलिए WF को बेकार कर दिया जाता है क्योंकि जब तक उपयोगकर्ता इंटरनेट से कनेक्ट नहीं होता है, तब तक वे WF लॉजिक द्वारा मान्य कॉल करने में सक्षम नहीं होते हैं।

UPW में XamlReader है, इसलिए XAML को पार्स करना वास्तव में कोई बड़ी बात नहीं है ...

@MelbourneDeveloper सभी कारणों से आपसे सहमत हैं, हालांकि, ध्यान रखें कि UWP और .Net Core (कम से कम अब) एक ही उपनाम के तहत नहीं हैं, जिसका अर्थ है कि वे समान निचले स्तर के API साझा कर रहे हैं, जिनमें समान API सतह (और . नेट कोर ओएसएस है जबकि यूडब्ल्यूपी नहीं है), वे एक ही चीज़ नहीं हैं और संगत नहीं हैं। दूसरे शब्दों में, आप एक UWP एक में .Net Core असेंबली नहीं जोड़ सकते। वे मतभेद (आईएमएचओ) अंततः दूर हो जाएंगे लेकिन अभी के लिए, वे अभी भी मौजूद हैं ...

हां। समझा। यह कामकाजी धारणा के साथ था कि भविष्य में उन दोनों चीजों को एक साथ लाया जाएगा। अगर वे नहीं हैं, तो भगवान हमारी मदद करें!

साथ ही @MelbourneDeveloper UWP का Xaml, .NET के Xaml का पूरी तरह से अलग, डंब-डाउन संस्करण है। WindowsDev के UserVoice को इसके Xaml सिस्टम को बेहतर बनाने के लिए वोटों के साथ (जिसे नज़रअंदाज़ किया जाना जारी है, जैसा कि सब कुछ UWP के साथ लगता है - यह कोई आश्चर्य की बात नहीं है कि उनके पास शुरू करने के लिए UserVoice क्यों है):
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9523650-add-support-for-xmlnsdefinitionattribute

उम्मीद है कि वे सही काम करते हैं और सुझाव के अनुसार @cwensley के मोनो Xaml पोर्ट और/या OmniXaml के पीछे रैली करते हैं। UWP का Xaml सिस्टम जैसा कि यह खड़ा है, वास्तव में एक मजाक है और इस कारण से इसकी गोद लेने की दर इतनी भयानक है।

इस तरह के नोट के साथ, मेरे पास MSFTies पर विचार करने के लिए एक व्यावसायिक उपयोग का मामला है: NodeJS। जितनी देर हम सभी इस मुद्दे पर अपने सामूहिक नट को खरोंचते हैं, उतना ही अधिक मूल्य NodeJS बाजार में मूल्य अर्जित करता है, क्योंकि यह वास्तव में क्रॉस प्लेटफॉर्म है और वास्तव में सर्वव्यापी है, कुछ ऐसा जो MSFT तकनीक केवल क्षण के रूप में (या निकट भविष्य के लिए) दावा नहीं कर सकता है। NodeJS सर्वर और क्लाइंट (उनमें से सभी) पर काम करता है और दोनों के बीच कोड का पुन: उपयोग करने में सक्षम बनाता है। एक कोडबेस देशी (कॉर्डोवा के माध्यम से) और वेब (मानक एचटीएमएल 5 ब्राउज़र के माध्यम से) परिदृश्यों में काम करेगा, जो कि एमएसएफटी-आधारित समाधान के साथ आपको जो करना होगा, उससे कहीं अधिक सस्ता है।

यह जल्द ही इस बिंदु पर पहुंच जाएगा कि NodeJS में एक प्रणाली को फिर से करना और MSFT को पूरी तरह से खोदना बाजार की आर्थिक वास्तविकताओं को पकड़ने के लिए निष्क्रिय टीमों (जो ऐसा लगता है) की प्रतीक्षा करने की तुलना में अधिक स्वादिष्ट (और स्पष्ट रूप से कम खर्चीला) हो जाएगा।

मैं इसका भी उल्लेख करता हूं क्योंकि यह उल्लेख किया गया है कि ऐसा लगता है कि एमएसएफटी अपने क्लाइंट प्लेटफॉर्म के लिए यूडब्ल्यूपी पर भरोसा कर रहा है, लेकिन यह बाजार के एक अंश तक पहुंचता है जो नोडजेएस करता है। और जब मैं भिन्न कहता हूं, तो वह इसे बढ़ा-चढ़ाकर बता सकता है। हम बात कर रहे हैं 200m (Windows 10 की अंतिम ज्ञात इंस्टॉल संख्या) बनाम ~3B (बिलियन) डिवाइस जो नोडज-आधारित एप्लिकेशन तक पहुंच सकते हैं।

मुझे यहाँ गलत मत समझो, मुझे MSFT पसंद है। मैंने अपने जीवन के 15 वर्षों में इसकी तकनीकों के साथ निवेश किया है और मैं व्यक्तिगत रूप से यहां पूरी तरह से निवेशित हूं। हालांकि, उस निवेश के साथ यह देखने का जुनून आता है कि हर कोई इसे सही कर लेता है और ओपन सोर्स के नए युग, क्रॉस-प्लेटफ़ॉर्म अजीबता के साथ यहां किए गए निर्णयों और प्रयासों पर गर्व करता है। मैं यह भी चाहता हूं कि हर कोई बाजार के खतरे से अवगत हो (और शायद मेरे डर को सत्यापित/पुष्टि करने के लिए भी)।

अंत में, अगर सब कुछ ठीक रहा, तो हमें पोर्टेबल के रूप में क्रॉस-प्लेटफ़ॉर्म Xaml की हमारी वर्तमान स्थिति के साथ एक और बड़ी समस्या है। Xaml ओमनीएक्सएएमएल से अलग है, इसलिए किसी बिंदु पर हमें एक समुदाय के रूप में यह पता लगाना होगा कि दोनों को कैसे सुलझाया जाए कोड आधार ... आदर्श। :)

@ माइकल-डीएसटी सभी बिंदुओं पर आपसे सहमत हैं। जिन लक्ष्यों पर हम WF चलाना चाहते हैं उनमें से एक क्लाइंट (विशेष रूप से मोबाइल और एम्बेडेड) हैं। हम उस पर WF जोड़कर स्थानीय व्यापार नियमों के लिए क्लाइंट कोड को कम करना चाहते हैं। ग्राहकों द्वारा मैं विंडोज़ डिवाइस (फोन, टैबलेट और आईओटी) जैसे यूडब्ल्यूपी के बारे में सख्ती से नहीं बोल रहा हूं ...

मुझे विश्वास है कि ऐसे प्रमुख उत्पाद हैं जो बिज़टॉक और शेयरपॉइंट जैसे डब्ल्यूएफ पर भरोसा करते हैं लेकिन वे अभी भी नेट पूर्ण संस्करण पर भरोसा कर सकते हैं जबकि नेट कोर (और बाद में यूडब्ल्यूपी) पर लोग नए डब्ल्यूएफ/एक्सएएमएल एपीआई पर भरोसा कर सकते हैं। मुझे पता है कि यह कोडबेस के आसपास बहुत सारे #ifs का संकेत देगा, लेकिन यह जाने का रास्ता होगा ...

@galversibeiro सत्यापन/समर्थन के लिए धन्यवाद। ऐसा लगता है कि मैं कभी-कभी ऊपर की ओर स्केटिंग कर रहा हूं क्योंकि कोई भी इस वास्तविक (अस्तित्ववादी?) समस्या का सामना नहीं कर रहा है। वास्तव में, .NET नेतृत्व वेब अनुप्रयोगों के लिए .NET को AngularJS के साथ जोड़ने की सिफारिश करके इस समस्या को बढ़ाने में मदद कर रहा है, मूल रूप से साहसी संगठनों को NodeJS में पूरी तरह से स्विच करने के लिए! (पूर्ण प्रकटीकरण, मैंने वह लिखा था।: पी)।

मैं यहां NodeJS के बारे में बहुत कुछ पोस्ट करने में संकोच करता हूं, क्योंकि WF एक सर्वर-साइड तकनीक से अधिक है, लेकिन जिस तरह से मैं (और अन्य संगठन शुरू कर रहे हैं) इसे देखते हैं, यह सभी क्षेत्रों को प्रभावित करता है और पूरे बोर्ड में .NET को खतरा देता है। वर्तमान में समाधान स्टैक के रूप में NodeJS का उपयोग करना अधिक लागत प्रभावी (और बाजार-पहुंच कुशल) है और हम (फिर से, खुद को दोहराने से नफरत करते हैं - लेकिन वास्तव में नहीं) इसे संगठनों में उनकी पसंद की तकनीक के लिए प्रतिबिंबित करते हुए देख रहे हैं।

निचला रेखा: मुझे अपना गुस्सा _कहीं_ रखना है और यह धागा शिकार है। :पी #सॉरीनोट्सरी

#if defs के बारे में ... हाँ, मैं यहां MvvMCross घोषणापत्र उद्धृत करूंगा: "# ट्विटर के लिए है, कोड के लिए नहीं।" :पी

अंत में, मैं @SuperJMN को टैग करना भूल गया क्योंकि उसे इस थ्रेड/चर्चा के बारे में भी पता होना चाहिए (OmniXaml के लेखक के रूप में) - कोई अनादर का इरादा नहीं है, यार! मैं अगले सप्ताह या उसके बाद व्यक्तिगत रूप से OmniXaml बनाम पोर्टेबल.Xaml समस्या से निपटूंगा।

@ माइकल-डीएसटी हाँ ... वास्तव में #if सिर्फ एक ही रास्ता है ...। नेट कोर टीम ने "मूल शिम" का दृष्टिकोण लिया जहां वास्तविक (ओएस विशिष्ट) कार्यान्वयन देशी कोड की एक पतली निचली परत पर सारगर्भित है। डब्ल्यूएफ मामले में यह नेट फुल के लिए एक शिम हो सकता है और दूसरा नेट कोर के लिए उदाहरण के लिए ...

मैं Node.js का प्रशंसक नहीं हूं और न ही जावास्क्रिप्ट (मुझे लगता है कि यह अभी भी एक स्क्रिप्टिंग भाषा है, प्रोग्रामिंग नहीं है, लेकिन यह मेरी अपनी पसंद है), लेकिन मुझे इस बात से सहमत होना होगा कि आजकल, इसकी तुलना में कुछ भी नहीं है एक्सप्लेट के संदर्भ में। माइक्रोसॉफ्ट स्वयं इसे वीएसटीएस पर अपने निर्माण एजेंटों के लिए उपयोग करता है (केवल 1 मामले का नाम देने के लिए, एमएस पर अन्य हैं) क्योंकि यह किसी भी प्लेटफॉर्म पर चलता है उदाहरण के लिए ...

मुझे लगता है कि डब्ल्यूएफ तकनीक का एक अद्भुत टुकड़ा है, जो वर्तमान संस्करण सर्वर साइड पर उपयोगकर्ताओं के लिए था, हालांकि नेट कोर के साथ, और पूरी तरह से ग्राहकों पर भी हो सकता है ...

@galvesribeiro ... मैं 100% आपके साथ हूं। EF Core 1.0 उसी तरह है... पारंपरिक रूप से सर्वर-साइड तकनीक जिसे अब क्लाइंट-साइड पर भी इस्तेमाल किया जा सकता है। इस तरह से भी WF उपलब्ध होना बहुत आसान होगा।

इसके अलावा, शिम के बारे में सुनकर अच्छा लगा। बहुत मंजूर। :)

अंत में, मैं यहां धागे (ज्यादातर) को पटरी से उतारना/अपहृत नहीं करना चाहता, लेकिन यह सुनिश्चित करने के लिए कि पुन: जावास्क्रिप्ट: मैं एक स्क्रिप्टिंग भाषा के रूप में सहमत हूं। हालांकि, यह एक बहुत ही लचीली "भाषा" भी है जिसका उपयोग अन्य रूपों में किया जा सकता है, विशेष रूप से बाइट कोड (आईएसएच)। जैसा कि मुझे यकीन है कि आपने देखा है, सी ++ के लिए वहां एलवीवीएम कंपाइलर जादू है। .NET डेवलपर समुदाय में बढ़ती/लोकप्रिय मांग .NET के लिए भी ऐसा ही करना है (आधिकारिक क्षमता पर .NET को JS में बदलना)। यह वास्तव में वर्तमान MSFT डेवलपर वातावरण में सभी मौजूदा (प्रमुख) बुराइयों को ठीक करेगा।

वैसे भी, अपने नियमित शेड्यूल किए गए प्रोग्रामिंग पर वापस जाएं। :P संवाद और विचारों के लिए धन्यवाद!

आप लोग कुछ ऐसी चीजों को छू रहे हैं जिनसे मैं 9 साल से निपट रहा हूं। ऐसा कुछ है जिसे Microsoft तकनीकों के साथ काम करने वाले बहुत से लोग समझ नहीं पाते हैं; अर्थात् वितरित कंप्यूटिंग की अवधारणा। शुरू से ही हमारे सॉफ़्टवेयर की एक मूलभूत आवश्यकता यह है कि यह कभी-कभार कनेक्टेड मोड में काम करता है। समय के साथ माइक्रोसॉफ्ट ने इसके लिए टूलिंग उपलब्ध कराने के लिए कई कदम उठाए हैं, लेकिन कभी भी कोई व्यापक ढांचा विकसित नहीं किया गया है। हमारे पास यहां पर थोड़ा सा सिंक फ्रेमवर्क है, वहां पर एक LINQ डेटाबेस है, लेकिन सब कुछ एक साथ काम करने के लिए कोई व्यापक टूलसेट नहीं है।

पिछले 9 वर्षों में हम अपने स्वयं के कभी-कभी जुड़े ढांचे को विकसित कर रहे हैं। यह अब नेट, सिल्वरलाइट और यूडब्ल्यूपी पर चलता है। हमने EF, और WF जैसे Microsoft ढांचे का लाभ उठाने की बहुत कोशिश की, लेकिन सिल्वरलाइट जैसे क्लाइंट टेक्नोलॉजी प्लेटफॉर्म पर इन तकनीकों के लिए कोई समर्थन नहीं दिया गया। हमने सचमुच अपना खुद का ओआरएम बनाया है और सिल्वरलाइट के लिए सिंक फ्रेमवर्क बनाया है जो अब यूडब्ल्यूपी के साथ संगत है।

जब पहली बार में WF के आसपास बहुत चर्चा हुई, तो यह काफी रोमांचक था क्योंकि इसने बिना कोड के सॉफ्ट कोड बिजनेस लॉजिक का एक तरीका पेश किया। लेकिन, जैसे-जैसे समय बीतता गया, मैं यह सोचने के लिए कम इच्छुक होता गया कि सिल्वरलाइट जैसी क्लाइंट साइड तकनीक के लिए कभी कोई पोर्ट होगा। मैंने मंचों पर इसके बारे में कई प्रश्न पोस्ट किए, लेकिन प्रतिक्रिया हमेशा समान थी: डब्ल्यूएफ एक सर्वर साइड तकनीक है, आप इसे सिल्वरलाइट में क्यों इस्तेमाल करना चाहेंगे?

जैसा कि गैल्वेसरिबेरो ने कहा था

"मुझे लगता है कि डब्ल्यूएफ तकनीक का एक अद्भुत टुकड़ा है, जो वर्तमान संस्करण सर्वर साइड पर उपयोगकर्ताओं के लिए था, हालांकि नेट कोर के साथ, और पूरी तरह से ग्राहकों पर भी हो सकता है ..."

और

"एक लक्ष्य जिसे हम WF चलाना चाहते हैं, वे हैं क्लाइंट (विशेष रूप से मोबाइल और एम्बेडेड)। हम इसमें WF जोड़कर स्थानीय व्यापार नियमों के लिए क्लाइंट कोड को कम करना चाहते हैं। क्लाइंट्स द्वारा मैं विंडोज़ डिवाइस जैसे UWP के बारे में सख्ती से नहीं बोल रहा हूँ। (फोन, टैबलेट और IoT)"

लोगों को यह समझना होगा कि जब वितरित कंप्यूटिंग की बात आती है, तो क्लाइंट और सर्वर तकनीक के बीच कोई अंतर नहीं होता है। गिट के काम करने के तरीके के बारे में सोचें। चाहे आप केंद्रीय रेपो को देख रहे हों, या कहीं नेटवर्क पर एक नोड देख रहे हों, गिट के लिए कोड समान है। कोड हर जगह दोहराया गया है। हमारे ढांचे के साथ भी ऐसा ही है। व्यापार तर्क सभी नोड्स पर दोहराया गया है। ऐसा इसलिए है क्योंकि भले ही उपयोगकर्ता नेटवर्क से जुड़ा न हो, फिर भी उन्हें उसी व्यावसायिक तर्क के अधीन रहने की आवश्यकता है। वितरित कंप्यूटिंग में, प्रत्येक कंप्यूटर सचमुच एक सर्वर है। यह सचमुच सर्वर के समान कोड चलाता है।

हम कभी भी WF का लाभ उठाने में सक्षम नहीं थे, क्योंकि हम सिल्वरलाइट में WF कोड नहीं चला सकते थे, और अब हम इसे UWP में नहीं चला सकते। EF को UWP में पोर्ट करते हुए देखना उत्साहजनक है। शायद यह माइक्रोसॉफ्ट की यह समझने की शुरुआत है कि वितरित कंप्यूटिंग एक आवश्यकता है। लेकिन, माइक्रोसॉफ्ट को परेशान कंप्यूटिंग के साथ बोर्ड पर आने की जरूरत है और पूरे वितरित कंप्यूटिंग ढांचे के हिस्से के रूप में डब्ल्यूएफ को शामिल करना होगा। शायद तब, हम अपने वितरित कंप्यूटिंग ढांचे को हटाने में सक्षम होंगे, और मुझे अब उस कोड को बनाए रखने की आवश्यकता नहीं होगी।

वास्तव में महान परिप्रेक्ष्य और विचार @MelbourneDeveloper। उन्हें शेयर करने के लिए धन्यवाद। मैं सिल्वरलाइट का बहुत बड़ा प्रशंसक भी था और तब से इसे देख रहा हूं (इसलिए मेरा परिणामी वोट और - वास्तव में - ऊपर साइट)। साथ ही, मैं उत्सुक हूं कि आप Azure मोबाइल सेवाओं के बारे में क्या सोचते हैं और यदि आपने अपनी ऑफ़लाइन कहानी में इसका उपयोग करने पर विचार किया है? मैं एक नौसिखिया/वितरित कंप्यूटिंग हूं (लेकिन आपको जो कहना है उसे खोदें), लेकिन मैं वास्तव में अगले साल इसमें शामिल होना चाहता हूं (मैं बहुत सारे माइक्रोसर्विसेज भी सुन रहा हूं, जो मुझे लगता है कि इसका नवीनतम समकक्ष है?) .

लोगों को यह समझना होगा कि जब वितरित कंप्यूटिंग की बात आती है, तो क्लाइंट और सर्वर तकनीक के बीच कोई अंतर नहीं होता है।

वास्तव में अच्छा बिंदु। इस बिंदु पर, यह सब कुछ है जहां प्रौद्योगिकी की मेजबानी की जाती है। यही है, आप वास्तव में उस तकनीक के मेजबान द्वारा सीमित हैं जिसे आप "वितरित" करने की कोशिश कर रहे हैं, मैं कहूंगा (और फिर से मैं इसके साथ कोई विशेषज्ञ नहीं हूं)। सबसे सर्वव्यापी (या आसानी से उपलब्ध) मेजबान है, बेहतर वितरित/सुलभ आवेदन है। Annnnnd .... मुझे लगता है कि आप जानते हैं कि मैं इसके साथ कहाँ जा रहा हूँ। :पी

किसी भी मामले में, वास्तव में ऐसा लगता है कि हम सभी इस चर्चा के साथ _something_ पर समझौता कर रहे हैं और यह मेरे लिए एक स्वागत योग्य परिवर्तन/उपलब्धि है। ;)

@galvesribeiro

ध्यान रखें कि UWP और .Net Core (कम से कम अब) एक ही मॉनीकर के तहत नहीं हैं, जिसका अर्थ है कि वे समान निचले स्तर के API साझा करते हैं, जिनकी API सतह समान होती है (और .Net Core OSS है जबकि UWP नहीं है) , वे एक ही चीज़ नहीं हैं और संगत नहीं हैं। दूसरे शब्दों में, आप एक UWP एक में .Net Core असेंबली नहीं जोड़ सकते। वे मतभेद (आईएमएचओ) अंततः दूर हो जाएंगे लेकिन अभी के लिए, वे अभी भी मौजूद हैं ...

इस PR dotnet/corefx#5760 पर एक नज़र डालें, मुझे आशा है कि यह कुछ चीजों को स्पष्ट करता है।

UWP _is_ .NET कोर का .NET पक्ष। हालाँकि, .NET Core कई रनटाइम प्रदान करता है। UWP AOT आधारित रनटाइम का उपयोग करता है, इसलिए JIT की आवश्यकता वाली कुछ कार्यक्षमता समर्थित नहीं है (जैसे LCG या RefEmit)। हालाँकि, वे समान असेंबली और (आगे बढ़ते हुए) समान NuGet पैकेज साझा करते हैं। हमने यूडब्ल्यूपी और एएसपी.नेट कोर से क्रॉस रेफरेंसिंग असेंबली (और पैकेज) की अनुमति देने के लिए विशेष रूप से स्टैक को डिज़ाइन किया है।

बेशक, पोर्टेबल क्लास लाइब्रेरी (पीसीएल) नामक इसके शीर्ष पर वीएस टूलिंग है जो पुस्तकालयों के निर्माण में आपकी मदद करने की कोशिश करती है जो प्लेटफार्मों के एक सेट पर काम करेगी। पीसीएल लक्ष्यीकरण संवाद में आप कई गंभीर विकल्प चुन सकते हैं, जिसके परिणामस्वरूप आपकी बाइनरी .NET कोर संगत होती है। हालांकि, चूंकि वीएस में पोर्टेबिलिटी प्लेटफॉर्म को देखकर निर्धारित की जाती है, आप यूडब्ल्यूपी ऐप से पीसीएल को तब तक संदर्भित नहीं कर पाएंगे जब तक कि पीसीएल यह नहीं कहता कि वह यूडब्ल्यूपी को लक्षित कर सकता है। यह व्यवहार बाय-डिज़ाइन है क्योंकि विचार यह है कि पीसीएल टूलिंग आपको गलती से कार्यक्षमता का उपयोग नहीं करने में मदद करती है जो हर जगह समर्थित नहीं है जहां आपको चलाने की आवश्यकता है। इसके विपरीत, आप केवल उन प्लेटफार्मों से पीसीएल का संदर्भ दे सकते हैं जो इसे लक्षित करता है।

चूँकि आप स्पष्ट रूप से मॉनीकर्स का उल्लेख करते हैं, आइए इस बारे में एक सेकंड के लिए भी बात करें। एक मॉनीकर (TFM) का डिज़ाइन यह है कि यह संपूर्ण सतह क्षेत्र का प्रतिनिधित्व करता है। हमारे टूलींग में दो मॉनीकर्स हैं:

• टारगेट प्लेटफॉर्म मॉनीकर्स (टीपीएम)
• टारगेटफ्रेमवर्क मॉनीकर (टीएफएम)

TFM को प्रबंधित, इन-बॉक्स, सतह क्षेत्र की समग्रता की पहचान के रूप में सोचें, जबकि TPM अंतर्निहित OS का प्रतिनिधित्व करता है, अर्थात OS प्रदान किया गया API सेट।

चूंकि हमने .NET कोर को कई प्लेटफार्मों के लिए पोर्टेबल होने के लिए डिज़ाइन किया है, एक पारंपरिक TFM वास्तव में ज्यादा मायने नहीं रखता है। इसलिए एक नई अवधारणा है, जिसे मानक मंच कहा जाता है, जिसे पहले पीढ़ी कहा जाता था।

क्या यह मदद करता है?

हालाँकि, वे समान असेंबली और (आगे बढ़ते हुए) समान NuGet पैकेज साझा करते हैं।

अधिकांश असेंबली में 'netcore50' NuGet लक्ष्य (Windows UWP Store App) और 'dnxcore50' NuGet लक्ष्य (ASP.NET v5 / ASP.NET Core 1.0) दोनों अनुप्रयोगों के लिए समान बाइनरी कार्यान्वयन DLL है।

हालांकि, कुछ NuGet पैकेज जैसे System.Net.* लाइब्रेरी पैकेज में 'netcore50' लक्ष्य बनाम 'dnxcore50' लक्ष्य के लिए अलग-अलग कार्यान्वयन हैं। उदाहरण के लिए, 'netcore50' वाली System.Net.Http लाइब्रेरी नीचे WinRT Windows.Web.Http कार्यान्वयन का उपयोग करती है। 'dnxcore50' कार्यान्वयन कुछ और (मूल WinHTTP) का उपयोग करता है।

हालांकि, कुछ NuGet पैकेज जैसे System.Net.* लाइब्रेरी पैकेज में 'netcore50' लक्ष्य बनाम 'dnxcore50' लक्ष्य के लिए अलग-अलग कार्यान्वयन हैं

हाँ, मुझे इसका उल्लेख करना चाहिए था। जिस तरह से मैं इसे देखता हूं वह यह है कि एक NuGet पैकेज एक कंटेनर प्रदान करता है जो निर्माता को विभिन्न निष्पादन वातावरण के लिए अलग-अलग कार्यान्वयन प्रदान करने की अनुमति देता है जबकि उपभोक्ताओं को यह जानने की आवश्यकता नहीं होती है। उस अर्थ में, NuGet पैकेज नई असेंबली हैं।

इस गहन व्याख्या और संदर्भ मुद्दे को साझा करने के लिए @terrajobst और @davidsh को धन्यवाद, लेकिन, मैंने जो कहा, उसमें क्या गलत है कि "एक मंच से 1 असेंबली को दूसरे द्वारा संदर्भित नहीं किया जा सकता है"?

जिस तरह से मैं इसे देखता हूं वह यह है कि एक NuGet पैकेज एक कंटेनर प्रदान करता है जो निर्माता को विभिन्न निष्पादन वातावरण के लिए अलग-अलग कार्यान्वयन प्रदान करने की अनुमति देता है जबकि उपभोक्ताओं को यह जानने की आवश्यकता नहीं होती है। उस अर्थ में, NuGet पैकेज नई असेंबली हैं।

यह अवधारणा वास्तव में नई नहीं है... लोग पहले से ही एक Nuget पैकेज बनाते हैं जो अन्य पैकेजों के एक समूह के संदर्भ के अलावा और कुछ नहीं है - तथाकथित "मेटा पैकेज"। पीसीएल को कई प्लेटफॉर्म पर काम करने के कई तरीके हैं। कई लोकप्रिय पुस्तकालयों (जैसे न्यूटनसॉफ्ट के Json.Net) द्वारा उपयोग किए जाने वाले सबसे प्रसिद्ध बैट और स्विच हैं जहां आपके पास एक नगेट है जिसमें एक सार्वजनिक इंटरफ़ेस (एपीआई सतह) और प्रत्येक विशिष्ट प्लेटफॉर्म के लिए एक असेंबली (एपीआई सतह का वास्तविक कार्यान्वयन) है। जिसमें एक-दूसरे से भिन्न निर्भरताएं भी हो सकती हैं और रनटाइम पर, उस प्लेटफॉर्म के लिए सही असेंबली का चयन किया जाएगा। अब अंतर यह है कि एक कंटेनर नगेट के अंदर "अंदर" कई नगेट्स होने के बजाय, जहां सभी एक ही प्लेटफॉर्म या 1 इंटरफ़ेस असेंबली पर होना चाहिए जो कि विकास द्वारा उपयोग किया जाता है और जो रनटाइम पर विशिष्ट पर स्विच हो जाएगा, हमारे पास एक मिश्रण है इसके! 1 nuget जो एक कंटेनर है और साथ ही इससे जुड़े सभी प्लेटफ़ॉर्म विशिष्ट nugets के लिए सार्वजनिक इंटरफ़ेस।

मुझे लगता है कि हम वही बात कर रहे हैं, मैंने पहले ही खुद को बुरी तरह व्यक्त किया: मुस्कान:

वैसे भी, WF पर वापस... मुझे लगता है कि यह कुख्यात है कि लोग इसे WF में पोर्ट करना चाहते हैं, न कि इसे linux या नैनो सर्वर पर चलाने के लिए "इसके शांत होने का कारण"। क्लाइंट्स पर भी लोग इसे हल्के तरीके से इस्तेमाल करना चाहते हैं।

फिर से, मुझे लगता है कि इस बंदरगाह को बनाने के लिए समुदाय के पर्याप्त लोग हैं ...

पुनश्च: उन लोगों के लिए जो वितरित कंप्यूटिंग में रुचि रखते हैं (असली एक ऑफ़लाइन क्लाइंट कहानी नहीं है) कृपया हमारे अन्य प्रोजेक्ट ऑरलियन्स पर एक नज़र डालें जो वास्तव में नेट कोर पर डब्ल्यूएफ के लिए एक अच्छा उपयोग मामला है और जो आज की बड़ी माइक्रोसॉफ्ट सेवाओं को सशक्त बनाता है जैसे स्काइप, हेलो5, और जिसे मैं व्यक्तिगत रूप से अपने वित्तीय लेनदेन प्रसंस्करण मंच की अपनी मुख्य तकनीक के रूप में उपयोग करता हूं जो एक वितरित फैशन में अरबों लेनदेन की प्रक्रिया करता है ...

@galvesribeiro

मैंने जो कहा उसमें गलत क्या है कि "एक मंच से 1 असेंबली को दूसरे द्वारा संदर्भित नहीं किया जा सकता है"?

ऐसा नहीं है कि आपका कथन गलत है; यह सिर्फ इतना है कि यह सही नहीं है: मुस्कान: आम तौर पर, मैं उस तरह का व्यक्ति नहीं हूं जो नाइटपिक करना पसंद करता है, लेकिन जिस चीज ने मुझे फेंक दिया वह था:

दूसरे शब्दों में, आप एक UWP एक में .Net Core असेंबली नहीं जोड़ सकते।

मैं यह धारणा देने से बचना चाहता हूं कि UWP और .NET Core अलग-अलग .NET प्लेटफॉर्म हैं, जैसे कि .NET Framework और Silverlight थे। हमने विशेष रूप से .NET कोर डिज़ाइन किया है कि आप सभी प्लेटफॉर्म पर काम करने वाली असेंबली को लेखक बना सकते हैं। उदाहरण के लिए, System.Collections.Immutable और काफी हद तक सभी रोसलिन .NET कोर असेंबली हैं, वे UWP में भी ठीक काम करेंगे।

तो फिर से लिखने के लिए: हमारा लक्ष्य एक ऐसा प्लेटफॉर्म बनाना है जहां सरल एमएसआईएल आधारित घटक सचमुच सभी .NET कोर आधारित प्लेटफॉर्म पर एक ही बाइनरी का उपयोग कर सकें। ऐसे मामलों में जहां यह संभव नहीं है, उदाहरण के लिए, मूल निर्भरता या अलग-अलग कार्यान्वयन के कारण, हम ठीक वही कर रहे हैं जो पॉल बेट्स ने इतनी स्पष्ट रूप से बैट और स्विच पीसीएल के रूप में वर्णित किया है: पोर्टेबल सतह क्षेत्र, प्रति प्लेटफॉर्म अलग-अलग कार्यान्वयन, और कंटेनर के रूप में NuGet और चयनकर्ता

.NET कोर दुनिया में, System पुस्तकालय वास्तव में विशेष नहीं हैं। कोई भी उसी तकनीक का उपयोग यह सुनिश्चित करने के लिए कर सकता है कि अधिकांश उपभोक्ताओं को अपने कोड आधार को #if निर्देशों के साथ नहीं डालना है।

मुझे लगता है कि हम वही बात कर रहे हैं, मैंने पहले ही खुद को बुरी तरह व्यक्त किया: मुस्कान:

मुझे लगता है कि हमने एक ऐसी दुनिया बनाई है जहां लोगों को भ्रमित करना थोड़ा आसान है - जिसमें स्पष्ट रूप से हम शामिल हैं: मुस्कान: इसलिए मैं सटीक होने के लिए इतनी मेहनत करता हूं कि .NET कोर कैसे बनाया गया और हमने किन समस्याओं को हल करने का प्रयास किया।

हाँ आप सही हैं। इंप्रेशन क्या मायने रखता है।

मुझे उम्मीद है कि किसी दिन हम UWP पर .Net Core को भी कॉल करेंगे तो यह खत्म हो जाएगा... तो, हमें अभी भी system.xaml की आवश्यकता है

संबंधित होने पर, मुझे लगता है कि System.Xaml एक अलग घटक है जो स्वयं ही मूल्य जोड़ता है। मैंने इसे अलग से ट्रैक करने के लिए dotnet/corefx#5766 दायर किया है।

धन्यवाद माइकल-डीएसटी

साथ ही, मैं उत्सुक हूं कि आप Azure मोबाइल सेवाओं के बारे में क्या सोचते हैं (https://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-store-dotnet-get-started-offline-data/) और यदि आपने इसे अपनी ऑफ़लाइन कहानी में उपयोग करने पर विचार किया है?

बेहतरीन सवाल। यह वितरित कंप्यूटिंग उर्फ ​​कभी-कभी कनेक्टेड ऐप्स के साथ हमारी कंपनी के अनुभव के बारे में एक इतिहास के सबक का संकेत देता है और यह कैसे Azure मोबाइल सेवाओं से जुड़ा हुआ है, और माइक्रोसॉफ्ट तकनीक के साथ कंप्यूटिंग वितरित करता है।

यदि लोगों ने ऊपर उल्लिखित वेबसाइट नहीं देखी है, तो मैं इसे देखने की दृढ़ता से अनुशंसा करता हूं। इसमें Azure Mobile Services के बारे में एक अच्छा वीडियो है।

लगभग 8 साल पहले हमने मूल विंडोज फोन प्लेटफॉर्म के लिए एक ऐप बनाया था। नेट कॉम्पेक्ट फ्रेमवर्क वाला पुराना स्कूल। लोग उस पर उपहास कर सकते हैं, लेकिन कुछ प्रमुख बिंदुओं पर यह मंच कभी-कभी कनेक्टेड तकनीक के संबंध में वर्तमान यूडब्ल्यूपी मंच से अधिक उन्नत था। हालाँकि, ऐसा प्रतीत होता है कि UWP पकड़ रहा है। उस प्लेटफ़ॉर्म पर कभी-कभार जुड़े ऐप्स की सफलता की कुंजी थी:

1) पूर्ण SQL डेटाबेस कार्यान्वयन (SQL सर्वर CE)
2) SQL सर्वर (बैकएंड), और SQL सर्वर CE (मोबाइल डिवाइस) के बीच फ्रेमवर्क कार्यान्वयन को सिंक करें। यह सिंक फ्रेमवर्क संस्करण 1 था।

यह ऐप सफल रहा। हमने एक डेटा स्तर लिखा था जो शीर्ष SQL CE, और SQL सर्वर पर था जो सर्वर पर तैनात किया गया था, और उपकरणों पर तैनात किया गया था। यह लगभग स्मृति को अधिकतम करता है लेकिन यह काम करता है। फील्ड कार्यकर्ता क्षेत्र में डेटा कैप्चर करने में सक्षम थे, और डेटा को केंद्रीय डेटाबेस में वापस सिंक किया गया था।

जब विंडोज फोन 7 जारी किया गया था तो हम भयभीत थे क्योंकि एक महत्वपूर्ण समस्या थी: बाजार के सभी डेटाबेस गैर-एसक्यूएल डेटाबेस थे। वे ज्यादातर LINQ के साथ लागू किए गए थे। यह हमारे डेटा स्तर के साथ संगत नहीं था, और विंडोज फोन 7 के लिए ईएफ मौजूद नहीं था। इसलिए, हम विंडोज फोन 7 के लिए कभी-कभी ऑफ़लाइन फ्रेमवर्क बनाने में असमर्थ रह गए थे, भले ही हम मूल के लिए एक पूर्ण समाधान बनाने में सक्षम थे। विंडोज फोन प्लेटफॉर्म।

सिल्वरलाइट गेम चेंजर था। फिर से, हम एक पूर्ण SQL डेटाबेस में आए। लेकिन, माइक्रोसॉफ्ट ने सिल्वरलाइट या इनलाइन डेटाबेस के लिए सिंक फ्रेमवर्क लागू नहीं किया था। इसलिए, हमने माइक्रोसॉफ्ट के सिंक ढांचे के बाद तैयार किए गए अपने स्वयं के सिंक ढांचे को लिखने के बारे में निर्धारित किया है। माइक्रोसॉफ्ट सिंक फ्रेमवर्क टाइमस्टैम्प के आसपास आधारित है। इसे हमने अपने सिंक फ्रेमवर्क में लागू किया है। सिल्वरलाइट के साथ फिर से हमें पूरी सफलता मिली। फील्ड वर्कर विंडोज टैबलेट को फील्ड में ले जाने, डेटा कैप्चर करने और फिर इसे वापस केंद्रीय डेटाबेस में सिंक करने में सक्षम थे। समस्या यह थी कि यह फोन के लिए कभी उपलब्ध नहीं था। विंडोज फोन 7 के लिए डेटाबेस प्लेटफॉर्म मौजूद नहीं था।

जैसा कि मैंने पहले उल्लेख किया है, हम WF के साथ व्यावसायिक तर्क को लागू करना चाहते थे, लेकिन सिल्वरलाइट को छोड़ दिया गया और किसी ने भी WF को सिल्वरलाइट में पोर्ट करने की संभावना के बारे में बात नहीं की।

अंत में, हम UWP पर पहुँचते हैं। यूडब्ल्यूपी के लिए SQLite के लिए एक रैपर लिखा गया है, और रैपर के लिए कुछ हैक्स के साथ, मैं SQLite के साथ इंटरफ़ेस का विस्तार करने में सक्षम हूं ताकि हम एक पूर्ण SQL डेटाबेस के साथ फिर से काम कर सकें। इसका मतलब है कि हमारी डेटा परत इसके साथ संगत है। हमारी डेटा परत, और सिंक परतें अब SQL सर्वर, SQLite, और एक अन्य अनाम डेटाबेस प्लेटफ़ॉर्म के साथ .Net, Silverlight और UWP पर काम करती हैं।

आज पहली बार मैंने माइकल-डीएसटी की बदौलत शुद्ध Microsoft तकनीक के साथ कोई सिंकिंग होते हुए देखा है। मूल रूप से, मैं कह सकता हूं कि Azure Mobile Services सिंकिंग केवल Microsoft Sync Framework रीब्रांडेड है। इसमें थोड़ा अलग एपीआई इंटरफ़ेस है, लेकिन मूल बातें मूल विंडोज फोन सिंक फ्रेमवर्क के समान हैं जिसे हम लगभग 8 साल पहले काम करने के लिए सिंक करते थे। मैं देख सकता हूं कि यह डेटा परिवर्तनों को ट्रैक करने के लिए समान दो टाइमस्टैम्प फ़ील्ड का भी उपयोग करता है। इन्हें SQL सर्वर में SQL Server 2008 में एक मुख्य विशेषता के रूप में पेश किया गया था। हमारा सिंक फ्रेमवर्क कमोबेश Microsoft सिंक फ्रेमवर्क की तरह ही काम करता है।

इसलिए, माइकल के प्रश्न का उत्तर देने के लिए, मैं इस तकनीक की जांच करूंगा। मैं देखूंगा कि क्या यह हमारे सिंक ढांचे को बदल सकता है। मैं इसे डंप करना पसंद करूंगा और किसी और को इसे बनाए रखने दूंगा। यह देखते हुए कि उन्होंने उल्लेख किया है कि यह SQLite का समर्थन करेगा, यह आशाजनक लगता है क्योंकि ऐसा लगता है कि हम पूर्ण SQL डेटाबेस का उपयोग जारी रखने के लिए SQLite रैपर को हैक करने में सक्षम होंगे, और इसलिए हमारी डेटा परत का उपयोग जारी रखने में सक्षम होंगे। अगर ऐसा है, तो इसका मतलब यह होगा कि 5+ साल का सिंक फ्रेमवर्क कोड सीधे बिन में जाएगा।

वैसे भी, मुद्दा यह है कि माइक्रोसॉफ्ट ऐसा लगता है जैसे वे एक बार फिर स्वीकार कर रहे हैं कि वितरित कंप्यूटिंग महत्वपूर्ण है। यदि यह महत्वपूर्ण है, तो WF को UWP में पोर्ट किया जाना चाहिए। UWP भविष्य है, और इसलिए यह Microsoft तकनीक के साथ वितरित कंप्यूटिंग का भी भविष्य है। वितरित प्रौद्योगिकी के भविष्य को WF की आवश्यकता है।

संबंधित होने पर, मुझे लगता है कि System.Xaml एक अलग घटक है जो स्वयं ही मूल्य जोड़ता है। मैंने इसे अलग से ट्रैक करने के लिए dotnet/corefx#5766 दायर किया है।

बहुत बहुत धन्यवाद @terrajobst! मैं आपके द्वारा ऑनलाइन/ट्विटर पर पोस्ट की जाने वाली हर बात से सहमत नहीं हूं, लेकिन मैं इस बात का बहुत बड़ा प्रशंसक हूं कि आप डेवलपर्स/समुदाय के बीच संवाद और संचार को कैसे सुगम बनाते हैं और मैं हमेशा इससे सहमत रहूंगा। :) यह वास्तव में मेरे लिए व्यक्तिगत रूप से बहुत मायने रखता है क्योंकि ऐसा लगता है कि एमएसएफटी से कुछ भी प्राप्त करने के लिए चढ़ाई के एक वर्ष से अधिक समय लगता है (और हाँ, मुझे एहसास है कि यह प्रतिबद्धता नहीं है लेकिन इस बिंदु पर कुछ भी सार्थक है)।

इसलिए, माइकल के प्रश्न का उत्तर देने के लिए, मैं इस तकनीक की जांच करूंगा।

बहुत बढ़िया @MelbourneDeveloper , मदद करने में खुशी हो रही है! मुझे लगता है कि Azure के पास वास्तव में उनके समूह पर एक ठोस संभाल है। वीएसओ/वीएसटीएस के साथ वे वास्तव में अपने डेवलपर्स को सुनते हैं और एक *_लॉट *_किया प्राप्त करते हैं। वास्तव में, यह यूडब्ल्यूपी समूह के लिए MSFT _except_ में प्रत्येक समूह के मामले में प्रतीत होता है, जो वास्तव में बहुत कुछ नहीं करता है और अपनी खुद की तकनीक को भी नहीं समझता है (और आइए उनकी परिभाषा में भी नहीं आते हैं "एक्सएएमएल")।

वर्तमान में हम अपनी कई मुख्य सेवाओं के लिए WF का उपयोग करते हैं और हम अब भी अपने उपयोग को और बढ़ा रहे हैं क्योंकि हमारे पास वर्कफ़्लो के साथ एक अच्छा अनुभव है और इस तरह के एक दृश्य, समझने में आसान प्रारूप में हमारे व्यापार तर्क हैं।

जैसे @MelbourneDeveloper ने कहा

वैसे भी, मुद्दा यह है कि माइक्रोसॉफ्ट ऐसा लगता है जैसे वे एक बार फिर स्वीकार कर रहे हैं कि वितरित कंप्यूटिंग महत्वपूर्ण है। यदि यह महत्वपूर्ण है, तो WF को UWP में पोर्ट किया जाना चाहिए। UWP भविष्य है, और इसलिए यह Microsoft तकनीक के साथ वितरित कंप्यूटिंग का भी भविष्य है। वितरित प्रौद्योगिकी के भविष्य को WF की आवश्यकता है।

कई .NET डेवलपर्स द्वारा WF की तकनीक की सराहना नहीं की गई है क्योंकि उन्होंने उस समय इसका मूल्य नहीं देखा होगा (मैं अतीत में नहीं था लेकिन अब मैं WF का बहुत बड़ा प्रशंसक हूं क्योंकि मैं समझता हूं कि यह कितना शक्तिशाली हो सकता है लेकिन वितरित कंप्यूटिंग के युग में, अब पहले से कहीं अधिक WF वास्तव में चमक सकता है और मुझे आशा है कि यह अंततः पोर्ट हो जाएगा।

मुझे लगता है कि इस विषय पर असहमति के लिए बहुत कम जगह है।

यह निश्चित रूप से तर्क दिया जा सकता है कि डब्ल्यूएफ जैसे घोषणात्मक, दृश्य प्रोग्रामिंग कोड लिखने के रूप में कुशल नहीं है। मैं सहमत होने की प्रवृत्ति भी रखता हूं। लेकिन, कॉन्फ़िगर करने योग्य प्लेटफॉर्म को राउंड आउट करने के लिए टूलकिट में एक टूल के रूप में WF का होना निश्चित रूप से एक अच्छी बात होगी। ग्राहक *_DO *_ विज़ुअल वर्कफ़्लो देखना चाहते हैं, और ग्राहकों को अपने स्वयं के वर्कफ़्लोज़ को संशोधित करने के लिए सशक्त बनाना निश्चित रूप से एक अच्छी बात है।

इसे पूरा करने का समय!

मुझे लगता है कि इस विषय पर असहमति के लिए बहुत कम जगह है।

हाहा @MelbourneDeveloper क्या आप कभी किसी सॉफ्टवेयर डेवलपर से मिले हैं? या वास्तव में, मानव जाति? ;पी

मुझे व्यक्तिगत रूप से लगता है कि डब्ल्यूएफ विजुअल डिजाइनर और मौजूदा टूल्स ने एक्सएएमएल को नुकसान पहुंचाया है, क्योंकि एमएसबिल्ड वर्कफ़्लोज़ के लिए जेनरेट की गई अत्यधिक वर्बोज़ फाइलों ने वास्तव में इस संबंध में एक्सएएमएल को एक बुरा नाम दिया है। यही वास्तव में डेवलपर्स Xaml ("ब्लोटेड फाइल्स") के साथ जुड़ते हैं और उड़ान को "सरल" JSON फाइलों और "स्क्रिप्टेड" बिल्ड फाइलों तक पहुंचाने में मदद करते हैं। उल्लेख नहीं है, पूरी रहस्यमय, कठिन और बोझिल प्रक्रिया (मैं अभी भी इसे अपनी परियोजनाओं में पूरी तरह से काम नहीं कर पा रहा हूं) यहां तक ​​​​कि Xaml फ़ाइल को देखने के लिए एक प्रोजेक्ट बनाने के लिए भी।

जब, वास्तव में, WF ने कैसे काम किया, वह हमेशा "सही तरीका" था। इसकी असली बीमारी इसकी टूलींग में थी।

इस प्रकार, यदि डिज़ाइनर टूल थोड़ा अधिक मित्रवत था (और शायद अधिक संगठित/कंपार्टमेंटलाइज़्ड फ़ैशन में फ़ाइलों को क्रमबद्ध करने के साथ बेहतर काम किया), तो यह एक गैर-मुद्दा (या किसी समस्या से कम) होगा।

मैं WF के लक्ष्य के पथ का बहुत बड़ा प्रशंसक हूं, लेकिन इसे थोड़ा और कड़ा करने की जरूरत है और इसके टूलिंग को संबोधित और सुधार किया जाना चाहिए। वास्तव में, दिन के अंत में, एक तकनीक केवल उतनी ही अच्छी होती है जितनी कि उसके सहायक उपकरण - डिजाइनर और सभी। उपकरण/डिजाइनर जितने बेहतर होंगे, तकनीक उतनी ही बेहतर होगी/समझने योग्य होगी, अपनाने की प्रक्रिया उतनी ही बेहतर होगी।

मैं निश्चित रूप से देखना चाहता हूं कि डब्ल्यूएफ ईएफ की तरह बन जाए और किसी भी .NET परिदृश्य में पहुंच योग्य हो, और टूलिंग को ठीक से सुविधाजनक बनाने के लिए बेहतर हो।

मेरी समझ यह है कि WF के लिए मूल दृष्टिकोणों में से एक केवल XAML ही नहीं, बल्कि वर्कफ़्लोज़ के लिए कई फ़ाइल प्रकारों का समर्थन करना था। यहां और वहां कुछ विचित्रताओं के अलावा कुल मिलाकर मुझे एक्सएएमएल के साथ वास्तव में कोई समस्या नहीं है। मेरे सिर को इसके चारों ओर लपेटने में और आवश्यकता पड़ने पर इसे मैन्युअल रूप से संपादित करने में सहज होने में कुछ समय लगा, जो मुझे यकीन है कि कई लोगों के प्रवेश के लिए बाधा प्रस्तुत करता है। इसलिए जब मुझे लगता है कि एक्सएएमएल को पश्चगामी संगतता (कम से कम अल्पावधि में) के लिए बनाए रखने की आवश्यकता है, तो मुझे वास्तव में अन्य वर्कफ़्लो फ़ाइल प्रकारों को विकसित करना शुरू करना अच्छा लगेगा (जैसे JSON)। मैं उस मोर्चे पर कुछ अच्छे सामुदायिक योगदान देख सकता था! ( व्हाट्सएप में लिखे गए कार्यप्रवाह किसी को भी? :मुस्कान:)

@ माइकल-डीएसटी मैं आपसे पूरी तरह सहमत हूं। हाल ही में मेरी टीम और मैं वर्कफ़्लो के लिए पसंद/नापसंद/इच्छाओं की समीक्षा कर रहे थे और लगभग सब कुछ जो हम सुधार देखना चाहते थे वह डिजाइनर के आसपास था और जरूरी नहीं कि कोर डब्ल्यूएफ ही। मुझे लगता है कि माइक्रोसॉफ्ट ने डब्ल्यूएफ में जो कुछ भी बनाया है उसके साथ एक शानदार काम किया है और मुझे लगता है कि कुछ सुधार और कुछ इंजीलवाद हम इसमें नए जीवन को सांस लेते हुए देख सकते हैं। मुझे लगता है कि यह एक ऐसा उपकरण है जिसे अस्तित्व में रखने की आवश्यकता है और मुझे डब्ल्यूएफ से एक टन मूल्य मिल गया है और मैं इसे लंबे समय तक जारी रखना चाहता हूं।

हमारे उद्यम ने डब्ल्यूएफ में काफी निवेश किया है और अब यह हमारे व्यवसाय के लिए एक महत्वपूर्ण तकनीक है। ओपन सोर्स और .NET कोर के लिए MIcrosoft की हालिया प्रतिबद्धता को देखते हुए, WF को पोर्ट करना इस तकनीक के लिए सबसे अच्छा अगला कदम लगता है। हमें इसकी आवश्यकता है!

वर्कफ़्लो हमारे संगठन के भीतर देव के रूप में हमारे लिए कई लाभों वाला एक उपकरण रहा है। यदि माइक्रोसॉफ्ट अपने ढांचे को एकीकृत करने जा रहा है, तो यह हमारे जीवन को मुख्य ढांचे में डब्ल्यूएफ के लिए आसान बना देगा।

हाहा @MelbourneDeveloper क्या आप कभी किसी सॉफ्टवेयर डेवलपर से मिले हैं? या वास्तव में, मानव जाति? ;पी

हाहा, मैं एक सॉफ्टवेयर डेवलपर हूं। मानव जाति मेरे लिए महत्वहीन है।

माइकल-डीएसटी

मुझे व्यक्तिगत रूप से लगता है कि डब्ल्यूएफ विजुअल डिजाइनर और मौजूदा टूल्स ने एक्सएएमएल को नुकसान पहुंचाया है, क्योंकि एमएसबिल्ड वर्कफ़्लोज़ के लिए जेनरेट की गई अत्यधिक वर्बोज़ फाइलों ने वास्तव में इस संबंध में एक्सएएमएल को एक बुरा नाम दिया है। यही वास्तव में डेवलपर्स Xaml ("ब्लोटेड फाइल्स") के साथ जुड़ते हैं और उड़ान को "सरल" JSON फाइलों और "स्क्रिप्टेड" बिल्ड फाइलों पर ले जाने में मदद करते हैं

शायद आप सही हैं। लेकिन, मैं व्यक्तिगत रूप से सोचता हूं कि यहां Xaml पर बहुत अधिक जोर दिया गया है। जब मैंने डब्ल्यूएफ का परीक्षण किया (यह महसूस करने से पहले कि हम इसका उपयोग नहीं कर सके क्योंकि यह सिल्वरलाइट पर मौजूद नहीं है), मैंने एक डब्ल्यूपीएफ ऐप बनाया। वह ऐप हमारी डब्ल्यूसीएफ सेवाओं से जुड़ा है और डब्ल्यूएफ के लिए एक्सएमएल को हमारे डेटाबेस में एक टेबल में संग्रहीत करता है। इस तरह हमने WF की सॉफ्ट कोडिंग हासिल की।

लेकिन, Xaml को पूरी तरह से wpf WF डिज़ाइनर टूल के उपयोग से हेरफेर किया गया था। उपयोगकर्ता ने Xaml को कभी नहीं देखा। xaml उपयोगकर्ता के लिए अप्रासंगिक था। इसे वेब पेज के पीछे HTML मार्कअप की तरह समझें। यह बेहद जटिल हो सकता है, लेकिन जब तक अंतिम उपयोगकर्ता वेब पेज को पसंद करता है, यह वास्तव में मायने नहीं रखता। मुझे लगता है कि यदि आप सीधे टेक्स्ट के रूप में एक्सएमएल में हेरफेर कर रहे हैं, तो आप वास्तव में डब्लूएफ का अपने इच्छित तरीके से उपयोग नहीं कर रहे हैं ...

मानव जाति मेरे लिए महत्वहीन है।

अच्छा। बी)

लेकिन, Xaml को पूरी तरह से wpf WF डिज़ाइनर टूल के उपयोग से हेरफेर किया गया था। उपयोगकर्ता ने Xaml को कभी नहीं देखा।

सही। एमएसबिल्ड ठीक इसी तरह काम करता है और अंतिम उपयोगकर्ता इससे नफरत करते हैं क्योंकि यह कितनी बड़ी फाइलें उत्पन्न करता है (विशेषकर जब आप उनकी तुलना सरल "स्क्रिप्ट" फाइलों से करते हैं जो बहुत ही बुनियादी और रैखिक होते हैं)। मैं आपके साथ सहमत हूं कि यह एक टूलिंग/डिजाइनर मुद्दा है, और मैं यह भी कहूंगा कि टूलिंग/डिजाइनर को डब्ल्यूएफ के साथ काफी सुधार किया जा सकता है।

मामले में मामला: ब्लॉग पोस्ट और कॉपी/पेस्ट कोड (या वास्तव में, कॉपी/पेस्ट _workflow_: मुस्कान :)। कई बार मैंने डब्ल्यूएफ के लिए कुछ ऑनलाइन खोज की है, और एक अच्छी ब्लॉग पोस्ट पर ठोकर खाई है जिसमें वर्कफ़्लो घटक (एमएसबिल्ड के लिए सबसे अधिक संभावना) डालने के लिए प्रदर्शन करने के लिए कुछ कदम दिखाए गए हैं। खैर, ऐसा करने के लिए, मुझे मूल रूप से चरणों का एक गुच्छा डुप्लिकेट करना पड़ा। आमतौर पर एक कोडिंग ब्लॉग पोस्ट पर, कोड एक साधारण कॉपी/पेस्ट के लिए उपलब्ध होता है। डब्ल्यूएफ के साथ ऐसा नहीं है। आपको इसे चरण दर चरण करना होगा जब तक कि यह आपकी मशीन पर बिल्कुल वैसा ही न दिखे जैसा ब्लॉग पोस्ट पर दिखता है। यह स्पष्ट रूप से बहुत कठिन और त्रुटि-प्रवण है (और पूरी तरह से सी # परिप्रेक्ष्य से एक कदम पीछे हटने जैसा लगता है)।

MSBuild के साथ हमने जो दूसरी समस्या का सामना किया, वह फ़ाइल का आकार है, न केवल बाइट्स में बल्कि स्वयं डिज़ाइनर में भी: एक जटिल वर्कफ़्लो को नेविगेट करना वास्तव में कठिन था। ऐसा कुछ ऐसा लगता है जिसे बहुत व्यापक (और सहज) तरीके से हिसाब किया जाना चाहिए।

अंत में, मैं फ़ाइल आकार की चीज़ पर लपेटना चाहता हूं। मुझे यकीन नहीं है कि आप दिन में वर्डएमएल और/या एमएसएफटी फ्रंटपेज से अवगत हैं। लेकिन यह दुनिया में सबसे अधिक फूला हुआ HTML बनाएगा। हालांकि उपयोगकर्ता आम तौर पर परिणामी मार्कअप में अपना हाथ नहीं डालते हैं, वे यह महसूस करने के लिए अपनी नाक में डालना पसंद करते हैं कि यह कितना "साफ" है। पहली चीज़ जो वे देखते हैं, वह है डिस्क पर आकार, और फिर दूसरी बात यह देखने के लिए कि फ़ाइल को कैसे स्वरूपित किया जाता है, आदि।

फिर से, मैं इस बात से सहमत हूं कि ये फाइलें कैसे बनाई जाती हैं, यह सख्ती से एक टूलिंग/डिजाइनर मुद्दा है, लेकिन डेवलपर्स उत्सुक हो जाते हैं और इसका भी हिसाब होना चाहिए। :)

हां। सभी अच्छे अंक। मुझे लगता है कि डिजाइनर को साफ करने की आवश्यकता होगी ताकि वह इस तरह की वर्बोज़ Xaml न बना सके।

वास्तव में यह निर्णय लेने की शक्ति किसके पास है कि WF को .Net Core, या UWP में पोर्ट किया जाए या नहीं? क्या यह सिर्फ कुछ डेवलपर द्वारा कोड लिखने, और फिर उस पैच को .Net Core codebase repo के व्यवस्थापकों को सबमिट करने का मामला है? इसके इर्द-गिर्द क्या राजनीति है? क्या Microsoft से प्रभावित डेवलपर्स की कोई कोर टीम नहीं है? क्या माइक्रोसॉफ्ट के कर्मचारी हैं? मुझे अभी भी वास्तव में पूरा सेटअप नहीं मिला है। हमें किसे मनाना है?

दरअसल @MelbourneDeveloper सिर्फ इस सूत्र में भाग लेकर, आप तर्क देने में मदद कर रहे हैं। एमएस में एक टीम है जो डब्ल्यूएफ का मालिक है, वर्तमान में मेरा है, लेकिन हम कोर पर डब्ल्यूएफ जारी करने का निर्णय नहीं लेते हैं। हमें व्यवसाय का मामला बनाना है। यहां चर्चा मुझे ऐसा करने में मदद करती है।

यह वास्तव में प्रभावशाली है कि कैसे लोगों ने इस धागे का समर्थन करते हुए 2016 की शुरुआत की :)

इसके अलावा https://github.com/dotnet/corefx/issues/5766 @terrajobst से इन दिनों बहुत अधिक व्यस्त हो गया है :)

@dmetzgar मुझे आशा है कि आप उन चर्चाओं से अधिक से अधिक प्रतिक्रिया प्राप्त कर सकते हैं/आवश्यकता है ताकि आपके पास ओएसएस के लिए पर्याप्त मामले हों।

मुझे पूरा यकीन है कि अगर एक डॉटनेट/डब्ल्यूएफ रेपो खोला जाता है, अगर इसे कोरएफएक्स में जोड़ा जाता है, तो लोग निश्चित रूप से इसे वास्तव में तेजी से बढ़ाएंगे।

वास्तव में @MelbourneDeveloper सिर्फ इस सूत्र में भाग लेकर, आप तर्क करने में मदद कर रहे हैं

यह मुझे गर्म और फजी महसूस कराता है।

बस FYI करें dmetzgar - मुझे अपने अनुभवों का दस्तावेजीकरण करने और बंदरगाह व्यापार मामले के लिए सबूत बनाने में मदद करने के लिए एक प्रेरक मामला सामने रखते हुए खुशी हो रही है।

मैं 2000 के बाद से माइक्रोसॉफ्ट प्रौद्योगिकी में घुटने टेक रहा हूं। मैंने इस धागे से संबंधित सभी प्रमुख प्रौद्योगिकियों को विकसित और फीका देखा है। जब तक मैं माइक्रोसॉफ्ट प्रौद्योगिकी में डूबा हुआ हूं, मैं अभी भी इसे एक उद्देश्य के दृष्टिकोण से देखता हूं और सोचता हूं कि डब्ल्यूएफ उन प्रमुख प्रौद्योगिकियों में से एक है जो नेट कोर, और विंडोज यूडब्ल्यूपी प्लेटफॉर्म में व्यापार/सरकारी खरीद को विकसित करने में मदद करेगा।

फ्लो चार्ट से ज्यादा उत्साहित ग्राहक को कुछ नहीं मिलता! कुछ भी तो नहीं!

मुझे यह भी कहना चाहिए कि Microsoft तकनीक कुछ बड़ा करने की कगार पर है।

इतने सालों से, मैंने अच्छी तकनीक का उदय और पतन देखा है। बदलते उपकरण परिदृश्य के कारण प्रौद्योगिकी के रास्ते में आने का प्रमुख कारण है। अतीत में, रणनीति प्रत्येक डिवाइस परिवार के लिए एक मंच बनाने की थी। इस दृष्टिकोण में स्वाभाविक रूप से कुछ भी गलत नहीं था। लेकिन, इसका मतलब है कि प्लेटफार्मों के बीच प्रौद्योगिकियों को पोर्ट करना। यह कठिन है, और यह असामान्य नहीं है कि प्रौद्योगिकियों का रास्ते के किनारे गिरना है क्योंकि एक मंच अचानक अप्राप्य हो जाता है (खांसी - सिल्वरलाइट)।

Microsoft अब .Net Core और UWP से पीछे हो रहा है। जबकि मुझे लगता है कि ये दो प्लेटफ़ॉर्म एक ही होने चाहिए, फिर भी मैं बहुत आशावादी हूं कि जब कोई तकनीक बनाई या बनाए रखी जाती है, तो यह कई प्लेटफार्मों पर काम करेगी। Xamarin मेरे आशावाद को और बढ़ाता है।

यह वास्तव में ऐसा लगता है कि इतिहास में पहली बार, हम उन प्रौद्योगिकियों के संग्रह में बिंदु रिक्त हो सकते हैं जो सीपीयू और ऑपरेटिंग वातावरण की एक विस्तृत श्रृंखला में काम करते हैं। यदि Microsoft इस पर जोर देता है, तो WF उसी का हिस्सा होगा।

यह मुझे गर्म और फजी महसूस कराता है।

:+1: उस पर @MelbourneDeveloper और @dmetzgar। यह एक तरह का जुड़ाव और संवाद है जिसे मैं व्यक्तिगत रूप से MSFT से बाहर देखना पसंद करता हूं, बजाय इसके कि इसके जुनूनी आधार से नजरअंदाज की गई दलीलों और अनुत्तरित कॉलों ( यह सिर्फ मतलबी है, यानी मतलबी है, आदमी )।

यहां एक तरफ यादृच्छिक: नोडजेएस के मेरे बिंदु पर एकमात्र व्यावसायिक मामला/खतरा है जिसकी आपको आवश्यकता है, एक यादृच्छिक लेख जो मैंने हाल ही में हुआ था ।

अंत में, "अगर .NET कोर EF के लिए पर्याप्त है, तो यह WF के लिए पर्याप्त होना चाहिए" के मेरे बिंदु पर ... इसके बैकएंड के रूप में किसी तरह? यह एक सम्मोहक मामला है, यदि ऐसा है तो। यदि नहीं, तो फिर भी विचार करने योग्य है (देखें: चर्चा/संवाद/विचार-मंथन/आदि)। :)

अंत में, "अगर .NET कोर EF के लिए पर्याप्त है, तो यह WF के लिए पर्याप्त होना चाहिए" के मेरे बिंदु पर ... इसके बैकएंड के रूप में किसी तरह? यह एक सम्मोहक मामला है, यदि ऐसा है तो। यदि नहीं, तो फिर भी विचार करने योग्य है (देखें: चर्चा/संवाद/विचार-मंथन/आदि)। :)

यह एक दिलचस्प विचार है। ईएफ और डब्ल्यूएफ को एकीकृत करने के लिए आपका उपयोग मामला क्या है? क्या आप एक उदाहरण दे सकते हैं? क्या यह दृढ़ता के लिए है?

क्या आप एक उदाहरण दे सकते हैं? क्या यह दृढ़ता के लिए है?

यह कि कम से कम इसका उपयोग बैकिंग मॉडल के रूप में किया जा सकता है कि वर्कफ़्लो एप्लिकेशन डोमेन में काम करता है। अधिकतर यह वास्तव में वर्कफ़्लो के लिए स्टोरेज मैकेनिज्म के रूप में काम कर सकता है (लेकिन मैं इसकी अनुशंसा नहीं करता - Xaml इसके लिए काफी बेहतर है)।

मैं यहां एक डब्ल्यूपीएफ-एस्क प्रतिमान देख सकता हूं जहां आप एक्सएएमएल में वर्कफ़्लो को परिभाषित कर सकते हैं और फिर उन्हें ईएफ में परिभाषित, संशोधित और संग्रहीत मॉडल इकाइयों के डेटा का उपयोग करके वर्कफ़्लो तत्वों के गुणों से बांध सकते हैं।

दी, मेरा अनुभव w / WF यहाँ सीमित है (व्यापक अनुभव वाले लोग यहाँ झंकार कर सकते हैं)। लेकिन, अगर यह डब्ल्यूपीएफ के लिए काम करता है, तो यह डब्ल्यूएफ के लिए काम कर सकता है। वास्तव में, मैं अपने वर्तमान प्रोजेक्ट के लिए उपयोग किए जाने वाले कंसोल एप्लिकेशन के लिए इसी प्रतिमान (यानी, wpf-esque Xaml- आधारित विकास) का उपयोग करता हूं। दी, यह डेटा-बाइंडिंग का उपयोग नहीं करता है जैसा कि मैं सुझाव दे रहा हूं (अभी तक), लेकिन वे आसानी से उत्पादित होते हैं, जैसा कि OmniXaml/Perspex ने हमें दिखाया है। धूप का चश्मा:

@ माइकल-डीएसटी मैं बहुत अधिक एकीकरण से बचना पसंद करूंगा। WF एक स्टैंडअलोन NuGet पैकेज होना चाहिए। WF और EF को एक साथ एकीकृत करना एक अलग परियोजना होनी चाहिए। बहुत सी चीजों का संयोजन शुरू करें और आप ओस्लो के साथ समाप्त हो सकते हैं।

मैं @dmetzgar से सहमत हूं: +1:

ईएफ एक भंडारण/दृढ़ता प्रदाता है। यह एक अलग NuGet पैकेज होना चाहिए और रनटाइम पर इंजेक्ट किया जाना चाहिए। डब्ल्यूएफ को केवल इंटरफेस का एक सेट प्रदाता होना चाहिए और बस इतना ही।

हमने इसे माइक्रोसॉफ्ट ऑरलियन्स पर स्टोरेज प्रोवाइडर्स के साथ बहुत अच्छा किया।

@dmetzgar (और @galversribeiro) सहमत हुए। मैं एक आवश्यक एकीकरण का सुझाव नहीं दे रहा हूं, लेकिन एक संभावित उपयोग के मामले/मूल्य प्रस्ताव का सुझाव दे रहा हूं। (देखें: बुद्धिशीलता। :मुस्कान :)

ईएफ और डब्ल्यूएफ को एकीकृत करने के लिए आपका उपयोग मामला क्या है? क्या आप एक उदाहरण दे सकते हैं? क्या यह दृढ़ता के लिए है?

मैं इस पर झंकार करना चाहता हूं! फिर, यह मेरी कंपनी के अनुभव से संबंधित है। अंततः, हम कभी-कभी कनेक्टेड ऐप्स के लिए SQLite जैसे इनलाइन डेटाबेस में डेटा की दृढ़ता के लिए EF का उपयोग करना चाहेंगे। अंततः, UWP/.Net Core में EF, SQLite, Azure Mobile Services, और WF सभी सद्भाव में काम करेंगे। अगर मैं समझाता कि हम ऐसा क्यों चाहते हैं, तो मैं खुद को दोहराऊंगा, लेकिन मैं समझा सकता हूं कि ईएफ और डब्ल्यूएफ एक साथ अच्छी तरह से क्यों काम करेंगे। हालांकि, हमने ईएफ में एक सीमा पाई है जिसने हमें अतीत में हमारे ट्रैक में रोक दिया है - और यह दूसरा कारण है कि हमें अपना ओआरएम बनाना पड़ा।

हमारे पास एक प्रणाली है जहां डेटा एक्सेस "पहले लोड", "सेव से पहले", आदि जैसी घटनाओं को ट्रिगर करता है। हम इन घटनाओं में हुक छोड़ देते हैं ताकि जब कोई रिकॉर्ड प्रकार सहेजा जाता है, तो हम वहां कस्टम व्यापार तर्क डाल सकते हैं। वर्तमान में, हमने इसे कस्टम बिजनेस लॉजिक डीएलएल से जोड़कर किया है। प्रत्येक ग्राहक के पास कस्टम ईवेंट का अपना सेट होता है। हमने WF को कॉल्स भी लागू कीं। इसलिए, उदाहरण के लिए, पहले सेव घटना पर, हम डब्ल्यूएफ को कॉल करके वहां कुछ सत्यापन कर सकते हैं जो अनिवार्य क्षेत्रों को मान्य करता है। इस तरह, किसी दिए गए ग्राहक के लिए सत्यापन तर्क को सॉफ्ट कोडित किया गया था। लंबे समय में, हमें इस उद्देश्य के लिए WF को छोड़ना पड़ा क्योंकि इसे सिल्वरलाइट पर कभी लागू नहीं किया गया था, लेकिन इसे वहाँ एक विकल्प के रूप में रखना अच्छा होता।

वैसे भी, मुझे लगता है कि यह किसी भी ऐप के लिए काफी सार्वभौमिक आवश्यकता है। आम तौर पर, आप हमेशा डेटा परत के शीर्ष पर एक परत चाहते हैं जो डेटाबेस में जाने वाले डेटा को मान्य करता है, या सामान्य व्यावसायिक तर्क करता है। उदाहरण के लिए, हमारे पास कुछ ग्राहकों के लिए व्यावसायिक तर्क हैं जो डेटाबेस में किसी विशेष प्रकार का रिकॉर्ड जोड़े जाने पर ईमेल भेजते हैं। यह डब्ल्यूएफ में किया जा सकता है। ईएफ और डब्ल्यूएफ के साथ सद्भाव में काम करने के साथ ऐसा कुछ लागू करना बहुत अच्छा होगा।

हां, मुझे नेट पर भी ईएफ के साथ ऐसा करने का कोई तरीका नहीं मिला। मुझे जो समस्या मिली, वह यह थी कि EF आपको यह नहीं बताता कि किसी दिए गए प्रकार का रिकॉर्ड कब सहेजा जाएगा। तो उदाहरण के लिए, यदि आप एक नया "कार्य" ऑब्जेक्ट बनाते हैं और इसे ईएफ के साथ डेटाबेस में जारी रखते हैं, तो ईएफ द्वारा कोई भी घटना नहीं निकाली जाती है जिसमें "RecordInserted" जैसा कुछ होता है"। यह हमें डेटा एक्सेस में हुक बनाने की अनुमति देगा ताकि कस्टम व्यवसाय सम्मिलित किया जा सके। इसलिए, यह एक कारण है कि हम कभी भी ईएफ के साथ नहीं गए। यह अफ़सोस की बात है क्योंकि हमारे अपने ओआरएम को परिष्कृत करने में वर्षों लग गए।

NodeJS के "व्यावसायिक मामले" से बात करते हुए: कैसे NodeJS 3 आसान चार्ट में .NET पर हावी हो रहा है

उस गिटहब रेपो के लिए धैर्यपूर्वक प्रतीक्षा कर रहा है। केवल अभी-अभी एहसास हुआ कि WF को .NET Core में पोर्ट नहीं किया गया था, जिसने हमारे उत्पाद के लिए इसकी व्यवहार्यता को काफी हद तक समाप्त कर दिया। जो एक शर्म की बात है क्योंकि हम ASP.NET कोर में आने वाले परिवर्तनों और संपूर्ण क्रॉस-प्लेटफ़ॉर्म, स्लिम डाउन, .NET कोर के मॉड्यूलर विचार से प्यार करते हैं, लेकिन हमें WF की आवश्यकता है क्योंकि यह हमारे पूरे उत्पाद का आधार है।

मुझे लगता है कि मैं ईमानदारी से वास्तव में परवाह नहीं करता अगर यह डब्ल्यूडब्ल्यूएफ है, या यदि यह कुछ अन्य अच्छी तरह से समर्थित वर्कफ़्लो इंजन है, लेकिन मुझे लगता है कि विस्तार के उद्देश्यों के लिए, किसी प्रकार का वर्कफ़्लो बिल्कुल बड़ा हो सकता है।

+1

हमने गतिशील पीढ़ी (आयातित बाहरी नियमों के आधार पर) और वर्कफ़्लोज़ को WCF सेवाओं के रूप में लोड करने का उपयोग किया। यह बहुत अच्छा होगा यदि हम ऐसे मॉडल का उपयोग .net core में कर सकें!
बीटीडब्लू - पूर्ण नेट की असेंबली आयात करने में क्या समस्या है? अगर यह ज्यादातर आईएल कोड है, तो यह नेट कोर में क्यों नहीं चलता है?

+1

@dmetzgar https://github.com/dmetzgar/corewf देखना अविश्वसनीय रूप से रोमांचक है! रीडमी से, मुझे यह देखकर आश्चर्य हुआ कि डब्ल्यूएफ टीम द्वारा एक बंदरगाह को ज्यादा कर्षण नहीं मिला। विशेष रूप से पावरहेल वर्कफ़्लो वाले हालिया पावरहेल पोर्ट को देखते हुए जो पूर्ण ढांचे तक सीमित होगा - लिनक्स और मैक स्पष्ट रूप से एक प्रमुख लक्ष्य नहीं है, लेकिन नैनो सर्वर मैं कल्पना करता हूं कि पावरहेल के लिए बेहद महत्वपूर्ण होगा। इसमें यह भी उल्लेख किया गया है कि आप एक्सएएमएल के विकल्प तलाश रहे हैं जिसमें पोर्टेबल जैसे अन्य एक्सएएमएल कार्यान्वयन शामिल हैं। उदाहरण के लिए एक्सएमएल पहले से ही कोरसीएलआर के साथ संगत प्रोफाइल 259 का समर्थन करता है?

@watertree पोर्टेबल.एक्सएएमएल और अन्य एक्सएएमएल कार्यान्वयन .NET कोर समर्थन के साथ जो मैंने अब तक देखा है, सभी में एक लापता विशेषता है। वे x: Class="" विशेषता को लागू नहीं करते हैं। यह डब्ल्यूपीएफ के लिए अनावश्यक है लेकिन डब्ल्यूएफ के लिए महत्वपूर्ण है। एक XAML कार्यप्रवाह में आम तौर पर होता है

पावरशेल वर्कफ़्लो में स्क्रिप्ट में वर्कफ़्लो को परिभाषित करने का एक बहुत अच्छा तरीका है। यह एक्सएएमएल या सी # में एक ही चीज़ लिखने से कहीं ज्यादा साफ है। हालाँकि, PSWF उस स्क्रिप्ट को पर्दे के पीछे एक XAML फ़ाइल में बदल देता है। PSWF के लिए नैनो पर काम करने के लिए, उन्हें अपनी मौजूदा पाइपलाइन और WF रनटाइम को बदलना होगा ताकि यह XAML का उपयोग न करे। और नैनो पर PSWF रखने के लिए ग्राहकों का वास्तव में पर्याप्त दबाव नहीं है।

एक्सएएमएल के विकल्पों के संबंध में, इस पर मेरी बहुत सारी राय है। एक्सएएमएल के साथ मेरी समस्या यह है कि यह डब्ल्यूएफ में एम्बेडेड है। .NET 3.5 में जारी पुराने WF के साथ, WF टीम से किसी भी प्रारूप को वर्कफ़्लो में बदलने के लिए अधिक प्रोत्साहन मिला। उन्होंने Visio आरेखों को कार्यप्रवाह में बदलने के उदाहरण का उपयोग किया। लेकिन जब 4.0 में नया WF आया, तो सब कुछ XAML पर केंद्रित था। क्या आपने कभी एक्सएएमएल में हाथ से वर्कफ़्लो लिखने की कोशिश की है? नहीं हो रहा। फिर डिबग सिंबल और व्यूस्टेट हैं। और एक भिन्न उपकरण के साथ XAML के एक संस्करण की दूसरे संस्करण से तुलना करने का प्रयास करें।

मुझे वास्तव में लगता है कि वर्कफ़्लो को परिभाषित करने के लिए XAML का उपयोग करना NuGet पैकेज को शामिल करने का मामला होना चाहिए। वर्कफ़्लो परिभाषाओं को संग्रहीत करने के अन्य साधनों को बनाने को प्रोत्साहित किया जाना चाहिए। हो सकता है कि आपको कुछ ऐसा चाहिए जो अच्छी तरह से संपीड़ित हो। हो सकता है कि आपको सुरक्षा की आवश्यकता हो और केवल सीमित गतिविधियों की अनुमति दें। मैं विकल्प रखना पसंद करता हूं।

वे एक्स लागू नहीं करते हैं: कक्षा = "" विशेषता

वास्तव में, संकलित Xaml (baml?) मेरे द्वारा देखे गए सभी Xaml स्वादों में स्पष्ट रूप से अनुपस्थित रहा है। मैंने अपने खाली समय के साथ इसमें गोता लगाने के बारे में सोचा है, लेकिन मुझे लगता है कि यह जल्द ही कुछ क्षमता में उपलब्ध होगा, शायद अगले साल। इसके अलावा, Xamarin की Xaml प्रणाली इसका समर्थन करती है, लेकिन यह बंद है और एक्स्टेंसिबल/सुलभ नहीं है।

क्या आपने कभी एक्सएएमएल में हाथ से वर्कफ़्लो लिखने की कोशिश की है? नहीं हो रहा।

सत्य। विडंबना यह है कि WF किसी भी Xaml एकीकरण का सबसे व्यापक लाभकारी (अब तक) है। एक गलती के लिए, शायद। यह शर्म की बात है कि Xaml को बेहद डिजाइनर अनुकूल बनाया गया था, फिर भी WF के आसपास टूलिंग हाथ से लिखे गए परिदृश्यों के लिए और यहां तक ​​​​कि खुद डिजाइनर के लिए भी थोड़ा निषेधात्मक है। ऐसा लगता है कि उन्होंने वास्तव में इसे एक दृश्य प्रोग्रामिंग भाषा बनाने का लक्ष्य रखा था, लेकिन महत्वपूर्ण मात्रा में समर्थन/संसाधनों के बिना इसे सफल होने की आवश्यकता होगी।

मुझे वास्तव में लगता है कि वर्कफ़्लो को परिभाषित करने के लिए XAML का उपयोग करना NuGet पैकेज को शामिल करने का मामला होना चाहिए।

मुझे पसंद है कि आप कैसे सोचते हैं! मैं

BTW, यदि आपने अभी तक नहीं किया है, तो कृपया System.Xaml पोर्ट अनुरोध/समस्या पर एक हॉप लें और यदि आप कर सकते हैं तो इस मुद्दे को ऊपर उठाएं। मैं एक के लिए वास्तव में एक नया खुला स्रोत, क्रॉस-प्लेटफ़ॉर्म Xaml सिस्टम देखना चाहूंगा जो सभी ज्ञात प्रणालियों में से सर्वश्रेष्ठ लेता है और इसे एक आधिकारिक और आधिकारिक स्वाद के रूप में प्रदान करता है। क्या यह अच्छा नहीं होगा? मैं

वैसे भी, अब यह 74 वोटों तक है। यह देखते हुए कि गिटहब प्रतिक्रियाएं उपलब्ध होने से पहले वोट शुरू हो गया था, यह बहुत अच्छा है:
https://github.com/dotnet/corefx/issues/5766

17 दिल भी बहुत अच्छे होते हैं। :)

किसी भी समर्थन (और निरंतर प्रतिक्रिया) के लिए धन्यवाद!

@dmetzgar आपके प्रयासों के लिए धन्यवाद! एक्सएएमएल पर बस टिप्पणी करें - मेरे पास एक्सएएमएल का एक बहुत ही नकारात्मक दृष्टिकोण होता था क्योंकि मैंने जिन फाइलों को निपटाया था, वे एक्सएएमएल की दृश्य डिजाइनर-पहली बोलियों के साथ बनाई गई थीं।

यह सब तब बदल गया जब मैंने Xamarin.Forms के साथ प्रोग्रामिंग शुरू की, जिसमें XAML के अलावा एक बहुत अच्छा घोषणात्मक C# API है। कोई विज़ुअल डिज़ाइनर नहीं है (केवल एक पूर्वावलोकनकर्ता जो XF रिलीज़ की तुलना में बहुत बाद में आया)। हैरानी की बात है, मैं सी # कोड की तुलना में एक्सएएमएल की उनकी बोली पर काम करना पसंद करता हूं! उन्होंने इसका बहुत अच्छा काम किया, और आपके पास मार्कअप के अर्थ को प्रदूषित करने वाला एक टन डिज़ाइनर मेटाडेटा नहीं है। प्रिज्म.फॉर्म जैसे सहायक ढांचे भी एक्सएएमएल की ओर स्केल को काफी हद तक टिपने में मदद करते हैं क्योंकि यह बिना किसी कोड-बैक के कोड लिखने में मदद करता है।

तो मुझे नहीं लगता कि एक्सएएमएल प्रति समस्या है, लेकिन पहले डिजाइनरों का समर्थन करने के लिए डिज़ाइन की गई बोलियां - एक्सएफ मेरे लिए बहुत आकर्षक सबूत है।

उस विषय पर कोई अपडेट?

खैर CoreWF जीवित है और https://github.com/dmetzgar/corewf . पर मौजूद है

यह देखने की जरूरत है कि क्या डायनामिक एक्टिविटी को अब कोर में जोड़े गए नए कंपोजिशन एपीआई और .net मानक 2.0 के साथ पोर्ट किया जा सकता है।

बहुत अच्छा होगा अगर हम डब्ल्यूएफ टीम से सुनें।

इस विषय पर कई रोचक और उपयोगी टिप्पणियाँ की गई हैं। मेरे हिस्से के लिए, मेरा मानना ​​​​है कि केवल डब्ल्यूएफ रनटाइम और इवेंट ट्रैकिंग (यानी एक्सएएमएल, लेनदेन, या डब्ल्यूसीएफ बिट्स के बिना) को .NET कोर में पोर्ट किया जा रहा है और मुझे खुशी है कि यह (प्रकार) किया गया था।

मैं सहमत हूं कि WF.Core को आधिकारिक रूप से मौजूद रहने की आवश्यकता है। यदि डेवलपर्स के लिए काम करने वाले वर्कफ़्लो को परिभाषित करने का अधिक लचीला तरीका बनाने की क्षमता थी, तो मेरा मानना ​​​​है कि यह सबसे अच्छा तरीका होगा। मैं मानता हूं कि यदि एमएस कहता है कि वे सिस्टम.एक्सएएमएल को पोर्ट नहीं करने जा रहे हैं, तो एक्सएएमएल क्रैक करने के लिए एक कठिन अखरोट है, लेकिन मैं वास्तव में अपने .NET कोर वेब एपीआई प्रोजेक्ट्स में WF.Core देखना चाहता हूं।

मुझे लगता है कि यहां के कमरे में विशाल हाथी यह है कि इस परियोजना को धरातल पर उतारने के लिए पर्याप्त कर्षण नहीं है क्योंकि एमएस और अन्य लोगों ने डब्ल्यूएफ के बारे में किसी भी जानकारी पर बहुत कड़ा रुख अपनाया है। निश्चित रूप से एमएसडीएन पर कुछ नमूने हैं, लेकिन किताबों या अन्य ठोस (पुनरीक्षित) सामग्री के रूप में वहां बहुत कम जानकारी है।

मैं निश्चित रूप से इसे जीवन में लाने में मदद करने के लिए समय देने को तैयार हूं।

तो OmniXAMLv2 (यह जीथब रेपो में एक शाखा पर है), जो अभी भी विकास में है, को x: क्लास विशेषताओं (https://github.com/SuperJMN/OmniXAML/issues/12) का समर्थन करना चाहिए। शायद हम इसे (कोर) डब्ल्यूएफ के लिए इस्तेमाल कर सकते हैं?

@ewinington इसे इंगित करने के लिए धन्यवाद!
यह निश्चित रूप से इसका एक बड़ा हिस्सा है। साथ ही, .NET मानक 2.0 में WF द्वारा उपयोग किए जाने वाले System.ComponentModel प्रकारों का एक समूह है। System.Transaction पहले से ही corefx में है। डब्ल्यूसीएफ सर्विसहोस्ट केवल एक चीज गायब है।

डब्ल्यूसीएफ सर्विसहोस्ट आईएमएचओ इंतजार कर सकता है। मुझे लगता है कि .Net Core/Asp.Net दुनिया में किसी भी चीज़ की तरह होस्टिंग मॉडल अज्ञेयवादी होना चाहिए ...

@galversibeiro मैं इससे सहमत हूं, इस तथ्य को देखते हुए कि वेब एपीआई सहित .NET कोर दुनिया में डब्ल्यूएफ कई अन्य तरीकों से काम कर सकता है।

हां। हालांकि, मैं @dmetzgar से सहमत हूं कि ऐसे ग्राहकों का एक समूह है जो आज WCF का उपयोग करते हैं, इसलिए इसका समर्थन करना जरूरी है लेकिन फिर से, इसमें देरी हो सकती है ...

वास्तव में होस्टिंग और "डिज़ाइन भाषा" को कोर रनटाइम से सारणित किया जाना चाहिए ...

हम WF के साथ WCF का उपयोग करते हैं लेकिन WF कोर में होने पर खुशी से WebAPI जैसी किसी चीज़ पर स्विच कर देंगे। असल में हम आगे बढ़ रहे हैं और डब्ल्यूसीएफ से एक रेस्टफुल विकल्प की परवाह किए बिना आगे बढ़ रहे हैं। हमें वर्कफ़्लो से एक टन मूल्य मिलता है और यह मेरी पसंदीदा .NET तकनीकों में से एक है!

मुझे यह भी लगता है कि कोर पर WF को xaml या wcf पर निर्भर नहीं होना चाहिए, बस wf इंजन और ऑब्जेक्ट मॉडल होना सुपर मूल्यवान होगा। फिर आप इसे asp.net कोर पर एक मिडलवेयर के रूप में चलाएंगे, विशेष रूप से नई पाइपलाइन/गैर-http काम के साथ जो कि केस्ट्रेल में आ रहा है।

कोर में डब्ल्यूएफ इंजन और ऑब्जेक्ट मॉडल रखने और समर्थन करने के लिए +1। हम एक्सएएमएल और डब्ल्यूसीएफ के आसपास भी काम कर सकते हैं।

एक्सएएमएल अच्छा है - यह आपको गतिशील कॉन्फ़िगरेशन बनाने देता है - एक प्रोजेक्ट में हम फाइलों से xaml वर्कफ़्लो लोड करते हैं और उन्हें डब्ल्यूसीएफ एंडपॉइंट्स के रूप में दर्शाया जाता है। और ये एक्सएएमएल फाइलें उपलब्ध सेवाओं की रजिस्ट्री से स्वतः उत्पन्न होती हैं। तो डब्ल्यूसीएफ-सेवाओं को एंडपोंट मिलते हैं:
https://[आधार]/wcf/[service_id1]
https://[आधार]/wcf/[service_id2] ...
नेट कोर में ऐसी कार्यक्षमता रखना अच्छा होगा :)
ओह... मैंने इसे यहाँ पहले भी लिखा है... :)))

हाँ, जैसा कि मैं यहाँ की भूमि से अधिक परिचित हो गया हूँ, WF में Xaml समर्थन इतना महत्वपूर्ण नहीं है, बल्कि यह वास्तव में System.Xaml को पोर्ट किया गया है जो महत्वपूर्ण हिस्सा है। चूंकि यह स्पष्ट रूप से दूसरे में कैद है - और मुझे काफी लोकप्रिय कहने में काफी खुशी हो रही है (लेकिन इसे आपको अपवोट करने से न रोकें, @ freerider7777! :smile :) - मुद्दा, मैं WF को निर्भरता के रूप में बनाने के समर्थन में हूं यह सुनिश्चित करने के लिए जितना संभव हो मुफ़्त है। यह .NET कोर में प्रवेश करता है। मैं

@ माइक-ईईई मैंने बहुत समय पहले वहां मतदान किया है !! :)

यह देखते हुए कि कोड के माध्यम से वर्कफ़्लोज़ बनाए जा सकते हैं, क्या EF Core के समान फ़्लुएंट API का उपयोग WF कोर को जीवन में लाने के लिए एक वैध विकल्प होगा? फिर क्रम के लिए क्रमांकन/deserialization बाद में बनाया जा सकता है और इसे लागू करना बहुत आसान हो सकता है?

FluentAPI... अभी बहुत गर्म है। या कम से कम, जब से वे स्थापित हुए थे। मैं

FluentAPI, बिल्डर पैटर्न, वे दोनों अनिवार्य रूप से समान हैं। एक कोड आधारित तरीका प्रदान करना जो श्रृंखलाबद्ध और उपयोग में आसान हो, मेरा मानना ​​है कि इसके पीछे एक ठोस सिद्धांत होना चाहिए।

एक डिजाइनर के बिना यह सब बेकार है। बेशक हम सब कुछ खुद कोड कर सकते हैं - सभी तर्क, सभी श्रृंखलाएं और इसी तरह (धाराप्रवाह के साथ या इसके बिना)। लेकिन WF में क्या अच्छा है - आप प्रसंस्करण के प्रवाह को नेत्रहीन रूप से देख सकते हैं। यह प्रबंधकों (और अन्य 'हितधारकों') और डेवलपर्स के बीच की कड़ी है! प्रबंधक कोड को नहीं समझते हैं, लेकिन ये उच्च स्तरीय आरेख सभी के लिए समझ में आते हैं। डब्ल्यूएफ के साथ आपको अलग-अलग आरेखों (विज़ियो या अन्य) की आवश्यकता नहीं होती है यदि वे अलग हो जाते हैं - वे आमतौर पर वास्तविक कोड के साथ सिंक से बाहर होते हैं :)

@ freerider7777 WF परिभाषा क्रमांकन xaml तक सीमित नहीं है (देखें https://github.com/dmetzgar/corewf @dmetzgar से)। इसे JSON के लिए भी लागू किया जा सकता है .. और यह मौजूदा परियोजनाओं जैसे NodeRed http://nodered.org/ को एकीकृत / फोर्क करने की संभावना को खोलेगा, जो कई तरह से WF डिज़ाइनर सुविधाओं और UX (+ यह भी चलेगा) जैसा दिखता है वेब ब्राउज़र में, WF के लिए नए उपयोग के मामले खोलना)

मुझे लगता है कि WF को .NET मानक में पोर्ट करना सबसे अच्छा है न कि केवल .NET कोर पर। पहले से लिंक किया गया WF रनटाइम पहले से ही .NET मानक 1.3 पर काम करता है (यदि हम राइटलाइन गतिविधि को छोड़ देते हैं तो हम नीचे जा सकते हैं)। 2.0 मानक जल्द ही आने के साथ, हमारे पास स्वचालित कैशेमेटाडेटा, डायनामिक एक्टिविटी और लेन-देन के दायरे जैसे बहुत सारे फीचर अंतराल को भरने की क्षमता होगी। हमें घटकों को अलग-अलग पैकेजों में अलग करना चाहिए ताकि एक पे-फॉर-प्ले मॉडल हो: यदि आप केवल रनटाइम चाहते हैं तो आप 1.3 मानक के साथ रह सकते हैं, लेकिन यदि आप डायनामिक एक्टिविटी चाहते हैं तो आपको 2.0 मानक की आवश्यकता होगी और आप अपने प्लेटफॉर्म को सीमित कर सकते हैं।

WF रनटाइम कोड में निश्चित रूप से सुधार की बहुत गुंजाइश है। उदाहरण के लिए, मैं गतिविधि एक्सटेंशन को निर्भरता इंजेक्शन से बदल दूंगा। धाराप्रवाह एपीआई कोड में वर्कफ़्लो लिखने के लिए दिलचस्प होगा (और उन पंक्तियों के साथ https://github.com/knat/Metah @knat द्वारा देखें) लेकिन मैं @ freerider7777 से सहमत हूं कि आरेखों का उपयोग करके आपके प्रबंधन और बीए के साथ संवाद करने की क्षमता जो वास्तव में उत्पादन में उपयोग किया जाता है उससे उत्पन्न एक बड़ा प्लस है। @helmsb को इसका बहुत अनुभव है (http://dotnetrocks.com/?show=1236) देखें।

एक नए डिजाइनर को एक वेब एप्लिकेशन बनना होगा। डब्ल्यूपीएफ या यूडब्ल्यूपी को लक्षित करने से दर्शकों की संख्या सीमित हो जाएगी। यदि OmniXAML समाप्त हो जाता है, तो लोग उसी टूल का उपयोग करके वर्कफ़्लो बना/संपादित कर सकते हैं जो वे आज करते हैं (VS या पुनः होस्ट किया गया समाधान)। समस्या यह है कि चूंकि वर्तमान डिज़ाइनर को .NET Framework में बनाया गया है, इसलिए किसी भी सुविधा या सुधार को .NET Framework रिलीज़ के लिए प्रतीक्षा करनी होगी। यह आरंभ करने के लिए काफी अच्छा है लेकिन दीर्घकालिक समाधान नहीं है। @ erikcai8 ने एक वेब डिज़ाइनर के साथ कुछ प्रयोग किए, जो कि nodered के समान है। मैं देखूंगा कि क्या मैं उसे साझा करने के लिए मना सकता हूं।

वर्कफ़्लो डिज़ाइनर फ्रंट-एंड के लिए, जीथब पर पहला प्रयास उपलब्ध है: https://github.com/gary-b/WF4JSDesigner और आप इसका लाइव उपयोग कर सकते हैं http://gary-b.github.io/WF4JSDesigner/

यह वही है जो पहले से ही दिखता है:

@ewinington : वेब वर्कफ़्लो डिज़ाइनर POC को देखकर बहुत अच्छा लगा। मैंने नीचे दिखाए गए स्क्रीनशॉट के रूप में एक और भी बनाया है।

AWWWWW स्नैप!!! यह एक डब्ल्यूएफ पीओसी-ऑफ है !!! मैं

हे हे। अरे @ erikcai8 Xaml को निर्यात कहां है ??? हा हा। बस आपको दु: ख को फ़्लिप कर रहा है। क्रमबद्ध करें। मैं

दोनों प्रयास बहुत अच्छे लगते हैं। अच्छा लगा दोनों को देखकर। यह अब स्पष्ट प्रतीत होता है, लेकिन मूल WF में वेब-आधारित विज़ुअल डिज़ाइनर का होना कितना शानदार होता? सब कुछ लॉक और लोडेड है, जाने के लिए तैयार है, आप बस एक यूआरएल पर जाएं। मुझे लगता है कि इससे वास्तव में ब्रांडिंग और अपनाने में मदद मिलती। दुर्भाग्य से ऐसा लगता है कि हर कोई टीएफएस-आधारित संपादक पर आ गया है जिसे सेटअप करना बहुत मुश्किल था और बहुत ही वर्बोज़ Xaml का नेतृत्व किया। ठेठ डेवलपर के लिए इससे निपटने के लिए यह एक खराब अनुभव था और अनुभव (डब्ल्यूएफ या एक्सएएमएल) के साथ कुछ भी करने के लिए एक बुरा नाम दिया।

यह, ओटीओएच, एक महान दृष्टिकोण की तरह लगता है। पुनर्जागरण शुरू होने दो!

@ माइक-ईईई माई ई2ई प्रयोग ने जेएसओएन वर्कफ़्लो को मूल रूप से लोड करने के लिए वर्कफ़्लो कोर इंजन को बढ़ाया ताकि एक्सएएमएल प्रारूप की आवश्यकता न हो। एक बार जेएसओएन वर्कफ़्लो लोड होने के बाद एक्सएएमएल वर्कफ़्लो वर्कफ़्लो इंजन से निर्यात किया जा सकता है।

मुद्दा यह है। हमें रनटाइम और उसके ऑब्जेक्ट मॉडल को डिज़ाइनर और क्रमबद्ध प्रारूप से नहीं बांधना चाहिए जिस तरह से यह WF 4.5 में था ...

@galversribeiro बात समझ में आ गई। प्रयोग ने माना कि जेएसओएन प्रारूप को वर्कफ़्लो कोर के लिए एक अन्य विकल्प के रूप में समर्थित किया गया था। जैसा कि ऊपर चर्चा की गई है, XAML अभी तक नवीनतम वेब तकनीकों के अनुकूल नहीं है।

हम WF से प्यार करते हैं कृपया इसे .NetCore पर पोर्ट करें।

हमें एक वेब आधारित वर्कफ़्लो डिज़ाइनर की आवश्यकता है। .NET कोर के लिए समर्थन, कार्यप्रवाह चलाने के लिए डबल कमाल होगा। जाओ जाओ

डैनियल गेरलाग यहां वास्तव में एक अच्छे हल्के वजन वाले कोर-संगत वर्कफ़्लो इंजन पर काम कर रहा है:

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

डेनियल ने बहुत ही कम समय में एक लंबा सफर तय किया है। यदि आप इसमें योग्यता पाते हैं तो मैं आपको इसे देखने और इस परियोजना में भाग लेने के लिए दृढ़ता से प्रोत्साहित करूंगा।

इस सारी रुचि के साथ, क्यों न केवल शुरुआत से ही नेट कोर संगत इंजन का निर्माण किया जाए?

@ccpony क्योंकि आप अभी डॉट नेट कोर पर CoreWF का उपयोग कर सकते हैं -> https://github.com/dmetzgar/corewf । केंद्रीय घटक पोर्ट किए जाते हैं और काम करते हैं। कुछ चीजें .net मानक 2.0 की प्रतीक्षा कर रही हैं।

@ewington उत्तर देने के लिए धन्यवाद, लेकिन मुझे यह नहीं मिल रहा है। WF एक सफल MS उत्पाद नहीं था और MS ने वर्षों से इसे बढ़ाने के लिए कुछ नहीं किया है। समुदाय आजमाए हुए और असफल कार्यान्वयन की गवाही से भरा हुआ है। इसे उद्यम में व्यापक रूप से नहीं अपनाया गया है। यह बोझिल, अति-विशेषीकृत, सीखना मुश्किल है और (अभी भी) छोटी गाड़ी है। इसका इंटरफ़ेस व्यापक रूप से बदनाम है। यह अंत उपयोगकर्ता के अनुकूल तकनीक बनने में विफल रहा। यह आंतरिक रूप से एक ब्लैक-बॉक्स है जिसे आसानी से बढ़ाया नहीं जा सकता है। यह साधारण वर्कफ़्लो के अलावा किसी अन्य चीज़ के साथ धीमा है। परीक्षण करना बहुत कठिन है। यह पुरानी तकनीकों (WCF, XAML) पर आधारित है। जब से रॉन जैकब्स बीमार हुए, WF सुस्त पड़ा है और MS में उसका कोई मित्र नहीं है।

मेरे अनुमान में, WF ने सबके लिए सब कुछ बनने की कोशिश की और वास्तव में, किसी के लिए बहुत कम निकला। माइक्रोसॉफ्ट ने इसे छोड़ दिया है लेकिन इसे छोड़ दिया है। हम ऐसा कुछ भी क्यों पुनर्जीवित करना चाहेंगे? यदि किसी महत्वपूर्ण तकनीक पर पुनर्विचार और पुनर्लेखन की आवश्यकता है तो यह यह है।

डैनियल गेरलाग की नवेली परियोजना को देखें। यह नया और अपरिपक्व है। लेकिन यह वर्कफ़्लो के लिए एक आधुनिक दृष्टिकोण लेता है जिसे बढ़ाना आसान होगा। यदि यहां हर कोई एक जटिल, दिनांकित और, स्पष्ट रूप से, अति-इंजीनियर परियोजना को फिर से बनाने की कोशिश करना बंद कर देता है और इसके बजाय अपने प्रयासों को कुछ नया और बेहतर बनाता है, तो हम एक सार्थक स्थान पर समाप्त होने का एक मौका खड़े होंगे - - वृद्धिशील रूप से निर्माण गेट-गो से एक बीहमोथ को फिर से लिखने की कोशिश करने के बजाय एक विश्व स्तरीय वर्कफ़्लो इंजन। ईमानदारी से, मैं यहां हर किसी की प्रशंसा करता हूं जो एक बहुत ही सार्थक प्रयास में संलग्न होना चाहता है - - बनाना, अंत में, एक अच्छी तरह से इंजीनियर, कार्यात्मक, हल्के वजन, पूर्व-से-सीखना, क्रॉस-प्लेटफ़ॉर्म वर्कफ़्लो (स्टेट मशीन?) टूल। लेकिन, मुझे यह कहते हुए खेद है, यदि आप सभी इस मार्ग पर चलते रहेंगे, तो आपके सभी प्रयास व्यर्थ हो जाएंगे। एमएचओ।

@ccpony अपनी राय साझा करने के लिए धन्यवाद। क्या आप इस बात पर विस्तार से विचार करेंगे कि आप किस बग का जिक्र कर रहे हैं? अगर .NET Framework में समस्याओं को ठीक करने के लिए हम कुछ कर सकते हैं, तो मुझे यह जानकर खुशी होगी।

@dmetzgar उत्तर देने के लिए धन्यवाद, डस्टिन। उस समय की अवधि के दौरान जब मैं डब्ल्यूएफ अनुप्रयोगों को विकसित करने की कोशिश कर रहा था, मुझे बग का सामना करना पड़ा। न केवल अप्रत्याशित व्यवहार, बल्कि कई बार एक जटिल डब्ल्यूएफ "उड़ा" जाएगा और एक्सएएमएल यूआई में त्रुटियां उत्पन्न करेगा जिन्हें एक्सएएमएल कोड में ठीक करना मुश्किल था। मैंने वास्तव में कभी भी WF तकनीक में एक बड़ा विश्वास विकसित नहीं किया। वास्तव में, यह बस इस बिंदु पर पहुंच गया कि मुझे ऐसा लगा कि मैं 800lb गोरिल्ला कुश्ती कर रहा हूं - - हर एक कदम आगे बढ़ने के लिए, मैं अंत में दो कदम पीछे हट जाऊंगा।

मुझे पता है कि बग के बारे में विस्तार से बताने के लिए आप अपनी तरह के अनुरोध में वह नहीं खोज रहे हैं। सच कहूं, तो मैं उन बगों के आसपास काम कर सकता था। लेकिन मैंने अंततः उन सभी अन्य कारणों से WF को छोड़ दिया, जिनका मैंने अपनी पिछली पोस्ट में उल्लेख किया था।

आप इस प्रयास का नेतृत्व कर रहे हैं और इसके लिए मैं आपको सलाम करता हूं। लेकिन निश्चित रूप से एक बिंदु आता है जब एक जटिल तकनीक को फिर से निकालने की कोशिश करना उल्टा हो जाता है। इस पूरे सूत्र के बाद, मैं बस मदद नहीं कर सकता, लेकिन मुझे लगता है कि प्रगति बहुत धीमी है - - यदि बिल्कुल भी - और अंततः इस सब से कुछ भी नहीं दिखाई देगा। मुझे लगता है कि यह बहुत कम संभावना है कि यहां जो कुछ भी उत्पादित किया जाता है, उसके लिए पुराने वर्कफ़्लो पोर्टेबल होंगे। इस थ्रेड में लोग क्लाइंट-आधारित वर्कफ़्लो (यानी जावास्क्रिप्ट), आरईएसटी संगतता, निर्भरता को कम करने, क्रॉस-प्लेटफ़ॉर्म इत्यादि के बारे में बात कर रहे हैं। उदाहरण के लिए, एक्सएएमएल पुरानी डब्ल्यूएफ तकनीक का इतना महत्वपूर्ण हिस्सा है, डब्ल्यूएफ को कोर में पोर्ट करने का क्या उपयोग है एक्सएएमएल इसका हिस्सा नहीं होगा?

तो डस्टिन, मुझे आपसे यह पूछने की ज़रूरत है: यहां हम इस परियोजना में 18 महीने हैं और इस बात पर आम सहमति नहीं लगती है कि वास्तविक प्रगति की जा रही है। मैं आपके प्रयासों का सम्मान करता हूं और मैं देख सकता हूं कि आप एक महान कोडर हैं - लेकिन यहां मेरा प्रश्न है: क्या यह इतनी सारी ऊर्जा और उत्साह को इकट्ठा करने और कुछ नया बनाने के लिए अधिक समझ में नहीं आता है?

@ccpony इस विषय में चर्चा WF .Net Standard का समर्थन करने के लिए है न कि इसके विपरीत।

बस जिज्ञासु... क्या आपने कभी कार्रवाई में शेयरपॉइंट परिनियोजन का उपयोग किया है या देखा है? यदि आप ऐसा करते हैं, तो आप देखेंगे कि यह वास्तव में WF पर बहुत अधिक है। क्या आपने कभी BizTalk परिनियोजन देखा है? जो उसी।

वे उद्यम की दुनिया में प्रमुख MSFT उत्पाद हैं, इसलिए हाँ, ऐसे उपयोगकर्ता हैं जो WF की परवाह करते हैं और इसके लिए उपयोग होता है। जैसा आपने कहा था, यह एक छोड़ी गई/गिराई गई परियोजना नहीं है।

इसके साथ ही, यदि आप @dmetzgar रेपो को देखते हैं, तो आप देखेंगे कि जितना कुछ सामान समान है या WF के पुराने अवतार से कुछ व्यवहार विरासत में मिला है, आप यह भी देखेंगे कि इसे हल्का होने के लिए फिर से डिज़ाइन किया गया था। हठ कम है और लोग आसानी से नए बना सकते हैं। डिज़ाइनर को डिकॉउंड किया गया है और लोगों ने पहले से ही कई परीक्षण बनाए हैं।

मैं कुछ नया चाहने पर आपकी हताशा को समझता हूं। मेरा विश्वास करो, मैं चाहता हूं कि ऐसा भी हो। लेकिन आपको @dmetzgar और उनकी टीम को समझना होगा। यह प्राथमिकता नहीं है क्योंकि 95% ग्राहक पुराने WF के उपयोगकर्ता हैं जो मूल रूप से बिज़टॉक और शेयरपॉइंट पर चल रहे हैं जैसा कि मैंने उल्लेख किया है। मैंने वर्षों तक पुराने WF का उपयोग बहुत उच्च tps वातावरण (बैंकिंग और वित्तीय लेनदेन) में किया और इसने मुझे बहुत अच्छी तरह से सेवा दी।

मेरी नई तकनीक .Net Core के साथ काम कर रही है, और इसका एक ही कारण है कि मैं इसे अभी फिर से उपयोग नहीं कर रहा हूँ, क्योंकि हमारे पास अभी तक .Net Core के लिए यह नहीं है।

जो मैंने पहले ही @dmetzgar को सुझाया था, वह है WF रेपो को .Net Foundation में लाना, मील के पत्थर को परिभाषित करना, वहां कोड डालना और कार्यों को मुद्दों के रूप में जोड़ना और इसे up-for-grabs के रूप में टैग करना ताकि समुदाय इसे करना शुरू कर दे। हालाँकि, इस काम को पूरा करने के लिए अभी भी उनकी टीम से कुछ समय की आवश्यकता है और संभवतः उनके पास वह समय उपलब्ध नहीं है (अभी तक)।

@galvesribeiro मुझे आपकी बात समझ में आई। हां, मैंने SharePoint परिनियोजन लिखा है। और मैंने BizTalk परिनियोजन को क्रिया (* शटर *) में देखा है। मैं SharePoint और WF के बीच संबंध को समझता हूं। (मुझे नहीं पता कि आपका क्या मतलब है जब आप सुझाव देते हैं कि बिज़टॉक किसी तरह डब्ल्यूएफ पर निर्भर करता है। ऐसा नहीं है।)

लेकिन मुझे एक महत्वपूर्ण बिंदु पर आपसे असहमत होना है : डब्ल्यूएफ एक छोड़ी गई/छोड़ी गई परियोजना है। मैं वास्तव में इस बिंदु पर SharePoint डेवलपर्स की चिंता को समझता हूँ। यह मानने का कोई कारण नहीं है कि MS SharePoint में WF की क्षमताओं को बढ़ाएगा। मुझे समझ में नहीं आता कि आपको क्यों लगता है कि @dmetzgar के प्रयासों का SharePoint (या BizTalk) के भविष्य से कोई लेना-देना होगा। ऐसा नहीं है कि MS @dmetzgar के कोड के साथ SharePoint को वापस कर देगा। क्षमा करें, लेकिन SharePoint के भविष्य का यहाँ किए जा रहे प्रयासों से कोई लेना-देना नहीं है।

तो, वास्तव में यह सब मायने रखता है कि क्या इस सब से एक अच्छा वर्कफ़्लो इंजन निकलेगा। और यह मेरा तर्क है कि भविष्य में डब्ल्यूएफ जैसे दिग्गज को मजबूर करने की कोशिश करना कार्रवाई का सबसे अच्छा तरीका नहीं है। खरोंच से निर्माण करना बेहतर है।

@ccpony मैं आपको याद दिलाना चाहूंगा कि यहां बहुत से लोग हैं जो सक्रिय रूप से इस परियोजना को साकार होते देखना चाहते हैं, और कुछ वास्तव में इसे पूरा करने में समय लगा रहे हैं। जबकि आप व्यक्तिगत रूप से WF को Microsoft के एक असफल उत्पाद के रूप में देख सकते हैं, यह अभी भी .NET का एक हिस्सा बना हुआ है और यहाँ केवल हमारे द्वारा ही उपयोग किया जाता है।

यह धागा रचनात्मक आलोचना और संक्रमण को एक वास्तविकता बनाने के लिए इनपुट के लिए होना चाहिए, न कि दूसरों या उत्पाद पर एक स्लैम। जबकि आपके विचारों का सम्मान किया जाता है, ध्यान दें कि वे आपके हैं और अन्य लोग इस बारे में अलग तरह से सोच सकते हैं कि उनके लिए WF कितना महत्वपूर्ण है।

हम उत्पाद को बेहतर बनाने के तरीकों और प्रयास में सक्रिय रूप से भाग लेने वालों की मदद करने के तरीके पर आपके इनपुट का सक्रिय रूप से स्वागत करते हैं।

धन्यवाद =^_^=

@ccpony

(मुझे नहीं पता कि आपका क्या मतलब है जब आप सुझाव देते हैं कि बिज़टॉक किसी तरह डब्ल्यूएफ पर निर्भर करता है। ऐसा नहीं है।)

क्षमा करें, मैं अपने आप को बुरी तरह व्यक्त करता हूं (मैं मोबाइल पर हूं)। मेरे पास ऐसा एप्लिकेशन था जो दोनों का एक साथ उपयोग करता है और मैं बहुत कुछ जानता हूं जो भी करता है।

यह मानने का कोई कारण नहीं है कि MS SharePoint में WF की क्षमताओं को बढ़ाएगा।

मैं यह नहीं कह रहा हूं कि यह होगा। मैं कह रहा हूं कि टीम जो डब्ल्यूएफ टुडे के साथ काम करती है, वह पूरी तरह से शेयरपॉइंट परिनियोजन के समर्थन पर केंद्रित है। शेयरपॉइंट का नवीनतम संस्करण भी डब्ल्यूएफ के समान/वर्तमान संस्करण का उपयोग कर रहा है।

मुझे समझ में नहीं आता कि आपको क्यों लगता है कि @dmetzgar के प्रयासों का SharePoint (या BizTalk) के भविष्य से कोई लेना-देना होगा।

मैं यह नहीं कह रहा हूं कि यह शेयरपॉइंट के भविष्य को प्रभावित करेगा। मैं कह रहा हूं कि अगर मैं सही ढंग से समझूं तो टीम शेयरपॉइंट का समर्थन करने में व्यस्त है। (अगर मैं गलत हूं तो @dmetzgar मुझे सही कर सकता है)

ऐसा नहीं है कि MS @dmetzgar के कोड के साथ SharePoint को वापस कर देगा। क्षमा करें, लेकिन SharePoint के भविष्य का यहाँ किए जा रहे प्रयासों से कोई लेना-देना नहीं है

यदि MS Sharepoint vNext पर WF vNext का उपयोग करेगा या नहीं, तो केवल वे ही इसे निश्चित रूप से बता सकते हैं। फिर, समस्या यह है कि WF टीम दोनों से निपटने में सक्षम नहीं है।

तो, वास्तव में यह सब मायने रखता है कि क्या इस सब से एक अच्छा वर्कफ़्लो इंजन निकलेगा। और यह मेरा तर्क है कि भविष्य में डब्ल्यूएफ जैसे दिग्गज को मजबूर करने की कोशिश करना कार्रवाई का सबसे अच्छा तरीका नहीं है। खरोंच से निर्माण करना बेहतर है।

कोई भी इसे वैसे ही पोर्ट नहीं कर रहा है। @dmetzgar का रेपो इस बात का प्रमाण है कि इसे जमीन से ऊपर तक फिर से डिजाइन किया जा रहा है। फिर, समस्या बैकलॉग और बैंडविड्थ है जिसे टीम को दोनों चीजों से निपटना पड़ता है। इसलिए मैंने इसे डॉटनेट फाउंडेशन पर "खोलने" का सुझाव दिया और इसे डब्ल्यूएफ टीम के मार्गदर्शन और क्यूरेशन के साथ एक प्रमुख समुदाय-संचालित प्रयास बनाया, ताकि हम उनके शेड्यूल को जितना संभव हो उतना कम प्रभावित करने का प्रयास कर सकें।

फिर से, जैसे @InariTheFox और मैंने उल्लेख किया है, यह धागा पोर्ट के लिए एक पुश फॉरवर्ड है, जिसका मतलब यह नहीं है कि पुराने संस्करण को नए संस्करण में इन सभी सुविधाओं के साथ बल-पुश करें। हालांकि, यह समझना महत्वपूर्ण है कि लोग अपने वर्तमान WF-आधारित उत्पादों पर बहुत अधिक प्रयास (और पैसा) लगाते हैं, इसलिए @dmetzgar पुराने वर्कफ़्लो के साथ जितना संभव हो उतना अनुकूलता पर चिंता करता है, वास्तव में कुछ ध्यान रखना है।

ठीक। मैं यहां जुनून देखता हूं। वास्तव में, यदि WF का कोई अच्छा प्रतिस्थापन होता जो उन सभी समस्याओं का समाधान करता जिनका मैंने पहले उल्लेख किया था, तो हम यह वार्तालाप नहीं कर रहे होते। रिकॉर्ड के लिए, हम में से बहुत से लोग डब्ल्यूएफ से दूर चले गए हैं और अगली चीज़ के साथ आने का इंतजार कर रहे हैं। यह कभी नहीं किया। मेरे सर्वोत्तम ज्ञान के लिए, कोई वर्तमान, समर्थित, कार्यात्मक, नेट-आधारित वर्कफ़्लो/स्टेट मशीन समाधान नहीं है जिसे व्यापक रूप से माना जाता है। कृपया समझें: मैं अपने इस तर्क पर कायम हूं कि माइक्रोसॉफ्ट के नजरिए से डब्ल्यूएफ एक मृत तकनीक है।

लेकिन, ऐसा कहने के बाद, कृपया मुझे समझने में मदद करें। क्या @dmetzgar का रेपो इस तरह काम करता है? कोई इसके साथ कार्यप्रवाह कैसे लिखता है? मुझे कोई उदाहरण कोड नहीं दिख रहा है और न ही कोई दस्तावेज है। मैं कैसे आगे बढ़ूंगा?

मुझे लगता है कि वहाँ कई उत्पाद / कंपनियां हैं जिन्होंने WF को अपनी उत्पाद रणनीति के लिए केंद्रीय बनाया है, यह केवल समर्थन मोड में शेयरपॉइंट निर्भरता नहीं है: मेरी वर्तमान कंपनी में हमने WF के साथ एक स्वचालन मंच विकसित किया है जो केंद्रीय तकनीक है (और मुझे पता है इस बाजार के अन्य 2 प्रतियोगी जो अपने उत्पादों में WF का भी उपयोग करते हैं); मैंने उन लोगों के साथ भी चर्चा की है जो इसे इंसुरटेक में इस्तेमाल करते हैं .. इसलिए मेरा दृढ़ विश्वास है कि डब्ल्यूएफ के लिए दर्शक अभी भी हैं।

ऐसा कहा जा रहा है, .net कोर माइक्रोसॉफ्ट के फोकस क्षेत्रों में से एक है और अगली अवधि में इसमें बहुत सारे तकनीकी नवाचार शामिल होंगे; मुझे लगता है कि डब्ल्यूएफ का इसके हिस्से के रूप में न होना एक बड़ी क्षति होगी।

मेरे दृष्टिकोण से ऐसा करने का सही तरीका है कि WF कोर को xaml से स्वतंत्र बनाया जाए और अन्य प्रारूपों में भी वर्कफ़्लोज़ को क्रमबद्ध करना (डी) आसान बना दिया जाए (उदा: json)। यह वेब ब्राउज़र में होस्ट किए गए वर्कफ़्लो डिज़ाइनर जैसे परिदृश्यों के कार्यान्वयन को भी सरल करेगा। और https://github.com/dmetzgar/corewf रेपो के साथ हमारे पास एक प्रारंभिक बिंदु है।

WF की वर्तमान स्थिति के बारे में एक सिंहावलोकन में रुचि रखने वालों के लिए (जिसे मैं MS द्वारा छोड़े गए के रूप में नहीं देखता), कुछ समय पहले मैंने एक पोस्ट और एक प्रस्तुति में WF के बारे में उपलब्ध जानकारी को केंद्रीकृत किया था http://andreioros.com/blog /विंडोज़-वर्कफ़्लो-फ़ाउंडेशन-रीहोस्टेड-डिज़ाइनर/ ; मैं अभी भी इसे अप टू डेट रख रहा हूं

हम और हमारे ग्राहक डब्ल्यूएफ पर भरोसा करते हैं और हम इसे क्लाइंट के साथ-साथ सर्वर पर भी काम करते हुए देखना पसंद करेंगे। एक्सएएमएल और अन्य निर्भरता से मुक्त एक डब्ल्यूएफ, जिसे हल्के वजन के लिए डिज़ाइन किया गया है, लेकिन मौजूदा डब्ल्यूएफ की अभिव्यक्ति के साथ जो एमएस के साथ समर्थित समुदाय भी है, वास्तव में एक रोमांचक और मूल्यवान उत्पाद होगा।

एक बार फिर, कृपया मुझे यह पूछने की अनुमति दें: कोई @dmetzgar के पोर्ट को चलाने के लिए उसके साथ क्या करता है? वर्तमान स्थिति क्या है?

मुझे नहीं पता था कि @dmetzgar का बंदरगाह वास्तव में अपने वर्तमान अवतार में प्रयोग योग्य था ...

ऊपर @ewinington से:

"क्योंकि आप अभी डॉट नेट कोर पर CoreWF का उपयोग कर सकते हैं -> https://github.com/dmetzgar/corewf । केंद्रीय घटक पोर्ट किए गए हैं और काम करते हैं। कुछ चीजें .net मानक 2.0 की प्रतीक्षा कर रही हैं।"

किस मामले में मैं भी इसके उपयोग के बारे में सुनना चाहूंगा...

हाँ, यह मुख्य कार्यशीलता का आधार है। आप कोड-आधारित वर्कफ़्लो चला सकते हैं। netstandard2.0 की अनुपलब्ध विशेषताएं अधिकतर लेन-देन समर्थन से संबंधित हैं।

यह एक और कारण है कि मैं अभी भी इसे शुरू करने का सुझाव देता हूं और लोगों को केंद्रीय स्थान पर योगदान देता हूं। इसके फैलने से भविष्य में किसी दिन अंतिम उत्पाद तक पहुंचना और भी मुश्किल हो जाएगा।

कोर के एक भाग के रूप में आधुनिक रोसलिन सुविधाओं के लिए परीक्षणों और समर्थन के साथ WF पुनर्लेखन के लिए अप वोट। मुझे यह देखना अच्छा लगेगा कि सर्वर रहित और कंटेनर आर्किटेक्चर को कैसे प्रभावित कर सकते हैं, विशेष रूप से अलग डोमेन संदर्भों और व्यावसायिक प्रक्रियाओं के भीतर नियम सेट की तैनाती और स्केलिंग। मैं व्यक्तिगत रूप से एक WYSIWYG डिज़ाइनर पर एक संक्षिप्त DSL पसंद करूँगा। मैं व्यक्तिगत रूप से डिजाइनर से प्यार करता था, लेकिन यह लगभग हर समय विचित्र लगा। WF में स्वयं अत्यधिक ठोस होने की क्षमता थी, लेकिन इसके लिए गहरी विशेषज्ञता की आवश्यकता थी। वास्तव में, WF का एक बड़ा रोलआउट जिसमें WF प्रबंधक शामिल था और SQL सर्वर में निरंतर प्रवाह के लिए MS परामर्श और बग फिक्स की आवश्यकता थी। हालांकि मैं अब पिछले कई वर्षों से जावा टीमों का समर्थन करता हूं, लेकिन मुख्य रूप से एमएस तकनीक पर ध्यान केंद्रित करने के केवल 15 वर्षों के बाद मैं .NET पर नजर रखना पसंद करता हूं। मैं निक हैरिसन द्वारा "कोड जनरेशन विद रोजलिन" पढ़ रहा था (मेरा उनसे या किताब से कोई संबंध नहीं है) और एक बार फिर बिजनेस रूल इंजन स्पेस में फिर से आने के बारे में सोच रहा था, जिससे मुझे एक बार फिर डब्ल्यूएफ के भाग्य के बारे में आश्चर्य हुआ ... पूरी ईमानदारी से, मुझे लगता है कि Azure Functions MS संसाधनों के साथ-साथ WF में कहीं भी गहरे निवेश का समर्थन करने की उनकी सामान्य कॉर्पोरेट इच्छा दोनों के साथ प्रतिस्पर्धा करता है। ऐसा स्पष्ट प्रतीत होता है कि वे चाहते हैं कि आप इसका उपयोग करें... इसलिए, शायद समाधान इसके बजाय ओपनविस्क के ओपन सोर्स .NET संस्करण पर ध्यान केंद्रित करना है। लेकिन, एक कंटेनरीकृत दुनिया में, ... मैं सिर्फ एक सेवा के रूप में OpenWhisk का उपयोग कर सकता हूं। इसलिए...

पीएस केवल बाहरी अभिव्यक्तियों को आयात करने की एक मजबूत विधि का समर्थन करने से 60% ऐप आवश्यकताओं को हल कर सकता है जो सोचते हैं कि वे डब्ल्यूएफ चाहते हैं। क्या यह सीशार्पस्क्रिप्ट था? स्ट्रेट-फॉरवर्ड एपीआई के साथ बुनियादी व्यापार नियम कॉन्फ़िगरेशन आयात करने का एक आसान तरीका एक लंबा रास्ता तय करेगा (विभिन्न दृढ़ता, पुनर्प्राप्ति और कैशिंग विकल्प)। डिस्पोजेबल वर्चुअल इन्फ्रास्ट्रक्चर (इन्फ्रास्ट्रक्चर-, कंटेनर- और प्लेटफॉर्म-ए-ए-सर्विस पर ऑटोमेशन) के साथ, WF vNext ऐप में इन-लाइन करने की कोशिश करने पर एक सेवा के रूप में संस्करण परिवर्तनों को तैनात करने पर ध्यान केंद्रित कर सकता है (यानी WF के लिए एक बेहतर समाधान) डब्ल्यूसीएफ पर)

मुझे इस बातचीत में बहुत दिलचस्पी है। मेरी टीम एक्सएएमएल की निराशा से भी निपट रही है। हमारी दुविधा यह है कि हम अपने स्वयं के UI डिज़ाइनर बना रहे हैं ताकि हमारे ग्राहक Visual Studio या फिर से होस्ट किए गए डिज़ाइनर की आवश्यकता के बिना अपने स्वयं के वर्कफ़्लोज़ बना सकें। हमें एक्सएएमएल के हिस्सों को पुन: प्रयोज्य बिट्स में सहेजने की क्षमता की आवश्यकता है ताकि ग्राहक को हमेशा उन बिट्स को फिर से लिखने की आवश्यकता न हो (उन्हें वर्कफ़्लो फ़ंक्शंस के रूप में सोचें)। इसके लिए हमें यह जानना होगा कि XAML के टुकड़ों को एक साथ कैसे मिलाना है, जो हमने सीखा है वह बेहद निराशाजनक है। हम जो करने की सोच रहे हैं वह एक अमूर्तता पैदा कर रहा है जहां हम अपनी विभिन्न गतिविधियों और उनके संबंधों के डेटाबेस मॉडल पर भरोसा करते हैं और एक्सएएमएल को पूरी तरह से अनदेखा करते हैं। हर बार जब कोई वर्कफ़्लो निष्पादित होता है तो हम प्रोग्रामिक रूप से गतिविधियों आदि का निर्माण करेंगे। इस दृष्टिकोण पर शोध करते समय, मैं इस सूत्र पर अड़ गया। बातचीत जारी रखें, मुझे दूसरों की राय जानने में बहुत दिलचस्पी है।

@ erikcai8 वर्कफ़्लो डिज़ाइनर बहुत अच्छा आइडिया है। क्या मुझे आपके वर्कफ़्लो डिज़ाइनर का स्रोत मिल सकता है?

मैं अपने ऑटोमेशन प्रोजेक्ट्स में 5 से अधिक वर्षों से WF का उपयोग कर रहा हूं और यह अद्भुत था। मुझे उम्मीद है कि बहुत सारे डेवलपर इस अनुरोध का समर्थन करेंगे और इसे पूरा करेंगे। जब से मैंने काम करना शुरू किया है, मैंने हमेशा नेट तकनीक का इस्तेमाल किया है और मैं इसे जारी रखना चाहता हूं। हालांकि, क्रॉस-प्लेटफॉर्म का समर्थन करने में सक्षम होना कंपनी की दिशा है, इस प्रकार मैं वास्तव में नेट कोर में पूर्ण डब्ल्यूएफ देखने की उम्मीद कर रहा हूं।

नेट मानक 2.0 के आगमन के साथ, कोरवफ के मुद्दों पर एक अद्यतन होना बहुत अच्छा होगा:

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

जोड़े गए एपीआई ने पोर्टिंग प्रक्रिया को कैसे अनब्लॉक किया है और हम मदद के लिए क्या कर सकते हैं?

मुझे लगता है कि netstandard2.0 की परवाह किए बिना, इस बंदरगाह को जाना चाहिए क्योंकि यह आईएमएचओ जा रहा था ... एक पुनर्लेखन के साथ ... इसे बाहरी कार्य शेड्यूलर, एसिंक/प्रतीक्षा/कार्य, और अन्य आधुनिक सामान के अनुकूल बनाना। जितना मुझे डब्ल्यूएफ पसंद है, वर्तमान संस्करण काफी पुराना है ...

मेरा मतलब यह है कि बिना किसी अनादर के। ईमानदारी से। लेकिन क्या मैं यहां अकेला हूं जो समझता है कि यह परियोजना निराशाजनक है? हमें .Net के लिए एक अच्छे कार्यप्रवाह इंजन की सख्त जरूरत है, लेकिन ऐसा नहीं है। क्या हमें यहां बातचीत नहीं बदलनी चाहिए?

मैं एक नए, बेहतर कार्यप्रवाह इंजन के लिए तैयार हूं। बॉटमलाइन हमें .NET कोर में से एक की आवश्यकता है। हमने वर्षों से WF का उपयोग किया है और इसने हमारे लिए वास्तव में अच्छा काम किया है इसलिए यदि यह विकल्प है तो यह कुछ भी नहीं से बेहतर है।

@kalocamgit , स्रोत संदर्भ स्रोत पर उपलब्ध है। यह दो विधानसभाओं में है:
System.Activities.Presentation और System.Activities.Core.Presentation ।

दुर्भाग्य से, संदर्भ स्रोत प्रकाशित करने वाला उपकरण केवल C# कोड करता है। इसमें कोई भी एक्सएएमएल फाइल शामिल नहीं है। आप इसके बारे में [email protected] पर फ़ीडबैक प्रदान कर सकते हैं और/या उपयोगकर्ता की आवाज़ के मुद्दे पर वोट कर सकते हैं।

कोड .NET Framework में है इसलिए आप इसे अपने टूल में उपयोग करने के लिए स्वतंत्र हैं। कुछ उदाहरण @orosandrei की परियोजना और यहां एक उदाहरण परियोजना हैं ।

मेरा मतलब यह है कि बिना किसी अनादर के। ईमानदारी से। लेकिन क्या मैं यहां अकेला हूं जो समझता है कि यह परियोजना निराशाजनक है? हमें .Net के लिए एक अच्छे कार्यप्रवाह इंजन की सख्त जरूरत है, लेकिन ऐसा नहीं है। क्या हमें यहां बातचीत नहीं बदलनी चाहिए?

ठीक है अगर आपका _वास्तव में मतलब कोई अनादर नहीं है। :) मैं फ्लो के आसपास हर किसी के विचार क्या हैं, इस पर उत्सुक हूं? जब मैं "आधुनिक दिन" के लिए "कार्यप्रवाह" के बारे में सोचता हूं तो मैं यही सोचता हूं ... यह भी कि अज़ूर इन दिनों बहुत कठिन काम कर रहा है।

मैं वास्तव में वास्तव में इसका मतलब है :)

गेस फ्लो बढ़ते जैपियर का जवाब है? मैं नहीं देखता कि यह किसी भी तरह से डब्ल्यूडब्ल्यूएफ की जगह कैसे लेगा।

क्या डब्ल्यूएफ बंद कर दिया गया है या क्या मुझे यहां कुछ याद आ रहा है? यह बहुत दुखद होगा!

मैं डब्ल्यूएफ के लिए कहां वोट कर सकता हूं?

इस अंक का शीर्ष पद सर्वोत्तम स्थान है।

मुझे आश्चर्य है कि @rjacobs (WF guru) इस मामले के बारे में क्या सोचते हैं।

क्या आपका मतलब @ronljacobs है?

@dmetzgar शायद हाँ। वह असली WF हीरो है

यह मेरा जवाब है
https://github.com/danielgerlag/workflow-core

रॉन जैकब्स वह व्यक्ति था जिसने वर्षों और वर्षों तक अपने दिल और आत्मा को डब्ल्यूएफ में डाल दिया। उन्होंने Dercum रोग से अनुबंधित किया और 2013 में Microsoft छोड़ दिया। (यहाँ) जब उन्होंने छोड़ा, तो वह WF के लिए था। एक बार फिर, और उम्मीद है कि आखिरी बार: WF IS DEAD।

और एक बार फिर - - मैं सभी को और किसी को भी ऊपर डैन गेरलाग की परियोजना को देखने के लिए प्रोत्साहित करूंगा। यह वाक्पटु है, खूबसूरती से कल्पना की गई है और कोर पर चलती है। कोई भी व्यक्ति जो व्यवहार्य कार्यप्रवाह समाधान में योगदान करना चाहता है, उसे इसे देखने की आवश्यकता है।

कृपया टिकाऊ कार्य ढांचे पर भी एक नज़र डालें। इसे Azure Functions में जोड़ा जा रहा है, टिकाऊ कार्य देखें।

@dmetzgar यह ढांचा WF के विकल्प के रूप में माना जाने वाला डायपर में है। मुझे नहीं लगता कि यह गंभीर है कि Microsoft इस प्रकार का प्रस्ताव करता है। क्या यह पहिया को फिर से खोजने, WF को .NET Core में स्थानांतरित करने और सभी Microsoft परियोजनाओं में आधार के रूप में पुन: उपयोग करने के बजाय बेहतर नहीं होगा? मेरे शब्दों की कठोरता के लिए खेद है, लेकिन मुझे लगता है कि वे कई लोगों की भावना का प्रतिनिधित्व करते हैं जो डब्ल्यूएफ की वर्तमान स्थिति से बहुत निराश हैं।

@सुरीमन , उचित बिंदु

WF को .NET Core में पोर्ट करने में क्या शामिल है, इसका बेहतर विवरण देने के लिए मैंने corewf रेपो पर रीडमी को अपडेट किया। क्या आप एक नज़र डालने का मन करेंगे?

@dmetzgar स्पष्टीकरण के लिए और स्पष्ट रूप से WF को .NET कोर में पोर्ट करने के लिए आगे का रास्ता दिखाने के लिए धन्यवाद। आप जो कहते हैं उससे मैं समझता हूं कि Microsoft यह सब माइग्रेशन कार्य नहीं करने जा रहा है और यह आशा करता है कि समुदाय करता है, है ना? इस प्रश्न का उत्तर कुंजी है, प्रतिक्रिया के आधार पर कंपनियां वैकल्पिक मार्ग का विकल्प चुन सकती हैं या वह कार्य कर सकती हैं जो Microsoft को करना चाहिए।

Microsoft WF से .NET Core का आधिकारिक पोर्ट नहीं करेगा। मैं और मेरी टीम अपने खाली समय में इस पर काम करेंगे, लेकिन आधिकारिक क्षमता में या किसी निर्धारित रिलीज के साथ नहीं। सूचीबद्ध सभी मुद्दे पकड़ने के लिए तैयार हैं। हमारे द्वारा की जाने वाली कुछ परियोजनाओं के लिए ऐसे बंदरगाह का उपयोग होता है। यहीं से हमारा अधिकांश योगदान आएगा। मुझे लगता है कि इस मुद्दे को अभी के लिए बंद करना और लोगों को नवीनतम कार्य का पालन करने के लिए corewf रेपो की ओर इशारा करना उचित है।

नमस्ते,
फ्यूचर माइलस्टोन से 2.1 में परिवर्तन का मतलब यह है कि माइक्रोसॉफ्ट WF को .NET Core में पोर्ट करेगा?

बंद मुद्दों के लिए मील का पत्थर परिवर्तन सिर्फ यह दर्शाता है कि किस रिलीज के दौरान मुद्दा बंद कर दिया गया है।
यह विशेष मुद्दा मूल रूप से "ठीक नहीं होगा" के रूप में बंद कर दिया गया था - https://github.com/dotnet/corefx/issues/2394#issuecomment -316170275 के ऊपर स्पष्टीकरण देखें

@karelz क्या अफ़सोस है। एक पल के लिए ऐसा लगा जैसे लॉटरी ने हम पर प्रहार किया हो।

हमारे पास WF पर आधारित एक समाधान है। हम WF का उपयोग करके गतिविधियों का एक चरण बना रहे हैं और यह वर्कफ़्लो सभी ग्राहकों तक पहुँचाया जाएगा और वे WF के आधार पर क्रियाओं को संसाधित करेंगे। हम डब्ल्यूएफ से बहुत प्यार करते हैं। क्रॉस-प्लेटफ़ॉर्म का समर्थन करना हमारी कंपनी की दिशा है। हम .NET कोर पर WF रखने के लिए बहुत इच्छुक हैं।

CoreWF है जो वर्कफ्लो फाउंडेशन का कोड है जो आंशिक रूप से .net core पर पोर्ट किया गया है। अब आप वर्कफ़्लो फ़ाउंडेशन क्रॉस प्लेटफ़ॉर्म का उपयोग कर सकते हैं । आप इस समय केवल XAML आधारित कार्यप्रवाहों का उपयोग नहीं कर सकते हैं।

मेरे पास एक शाखा है जहां मैंने नेट स्टैंडर्ड 2.0 के शीर्ष पर गतिशील गतिविधि के लिए समर्थन जोड़ने पर काम किया है।

XAML पार्सिंग प्रक्रिया के लिए Microsoft को System.XAML को पर्याप्त रूप से खोलने की आवश्यकता है ताकि हम फाइलों को सही ढंग से पार्स करने में प्रगति कर सकें।

आप यहां इस मुद्दे पर प्रगति को ट्रैक कर सकते हैं: https://github.com/dmetzgar/corewf/issues/6 और इस मुद्दे पर ध्यान देने के मेरे विभिन्न प्रयासों में:
कोरएफएक्स पर
संदर्भ स्रोत पर

.Net संगतता पैक में System.XAML फ्रंट पर "शायद" है। लेकिन इसके शामिल होने को लेकर कोई खबर नहीं छाई है. समस्या शिप .Net Framework संगतता पैक वर्तमान में System.XAML के लिए "कोई योजना नहीं" सूचीबद्ध करता है।

हो सकता है कि कस्टमर एडॉप्शन एपिक का उपयोग आपकी कहानी को बताने के लिए भी किया जा सकता है कि कैसे वर्कफ़्लो फाउंडेशन (और सिस्टम.एक्सएमएल) को जोड़ने से आपकी कंपनी किसी उत्पाद को शिप कर पाएगी।

मेरी कंपनी भी डब्ल्यूएफ में निवेशित है: हमारे पास ऊर्जा कंपनियों के लिए एक उत्पाद है जहां हमारे ग्राहक वर्कफ़्लो फाउंडेशन का उपयोग करके वर्कफ़्लो बनाते हैं।

आपके जवाब के लिए धन्यवाद।
यह बहुत उपयोगी था इसकी सराहना करें।

2 नवंबर 2017 18:22 को, "एरिक विनिंगटन" नोटिफिकेशन @github.com ने लिखा:

CoreWF है https://github.com/dmetzgar/corewf जो का कोड है
वर्कफ़्लो फ़ाउंडेशन को आंशिक रूप से .net कोर में पोर्ट किया गया। आप वर्कफ़्लो का उपयोग कर सकते हैं
फाउंडेशन क्रॉस प्लेटफॉर्म अब । आप केवल XAML आधारित कार्यप्रवाह का उपयोग नहीं कर सकते हैं
इस समय।

मेरे पास एक शाखा है जहां मैंने गतिशील गतिविधि के लिए समर्थन जोड़ने पर काम किया है
नेट स्टैंडर्ड 2.0 के शीर्ष पर https://github.com/ewington/corewf ।

XAML पार्सिंग प्रक्रिया के लिए Microsoft को System.XAML खोलने की आवश्यकता है
फाइलों को सही ढंग से पार्स करने में प्रगति करने में सक्षम होने के लिए पर्याप्त है।

आप इस मुद्दे पर प्रगति को यहां ट्रैक कर सकते हैं: dmetzgar/corewf#6
https://github.com/dmetzgar/corewf/issues/6 और मेरे विभिन्न प्रयासों में
इस मुद्दे पर नोटिस लाने पर:
कोरएफएक्स पर
https://github.com/dotnet/corefx/issues/5766#issuecomment-320724209
संदर्भ स्रोत पर
https://github.com/Microsoft/referencesource/issues/39

नेट संगतता पैक
https://github.com/dotnet/designs/blob/d48425ffb2ba7d721acb82da61d7c6d4b320d6c7/compat-pack/compat-pack.md
System.XAML मोर्चे पर "शायद" है। लेकिन इसके बारे में कोई खबर फ़िल्टर नहीं की गई है
समावेश। समस्या शिप। नेट फ्रेमवर्क संगतता पैक
https://github.com/dotnet/corefx/issues/24909 वर्तमान में "नहीं" सूचीबद्ध करता है
योजनाएँ" System.XAML के लिए।

शायद यह भी मुद्दा ग्राहक दत्तक ग्रहण महाकाव्य
https://github.com/dotnet/corefx/issues/24751 बताने के लिए इस्तेमाल किया जा सकता है
वर्कफ़्लो फ़ाउंडेशन (और System.Xaml) को जोड़ने की आपकी कहानी कैसे अनुमति देगी
आपकी कंपनी एक उत्पाद शिप करने के लिए।

मेरी कंपनी भी WF में निवेशित है: हमारे पास ऊर्जा कंपनियों के लिए एक उत्पाद है
जहां हमारे क्लाइंट वर्कफ़्लो फ़ाउंडेशन का उपयोग करके वर्कफ़्लोज़ बनाते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/2394#issuecomment-341377434 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AFernYlbmCQ4tnaOz4Hpv5rrVoEBeX9Bks5syZfxgaJpZM4FaQMY
.

नमस्ते,
यह सूक्ष्म सेवाओं की दुनिया है और पूरी सामग्री घटकों में टूट गई है। अब अगर हमें इसे व्यवस्थित करना है तो हमें Azure लॉजिक ऐप्स या किसी अन्य बाहरी विक्रेता पर निर्भर रहना होगा जो वर्कफ़्लो के लिए प्रीमियम चार्ज करता है। हालांकि नेटफ्लिक्स कंडक्टर जैसे बहुत कम गैर .NET WF उत्पाद, हम शुद्ध .NET कोर संस्करण में से एक को पसंद करेंगे। आप नेटफ्लिक्स कंडक्टर से https://github.com/Netflix/conductor पर सुराग ले सकते हैं और वहां से एक का निर्माण शुरू कर सकते हैं। यह उन निजी क्लाउड डेवलपर्स के लिए बहुत अच्छा होगा, जिनके पास एज़्योर स्टैक तक पहुंच नहीं है जो लॉजिक ऐप्स का उपयोग नहीं कर सकते हैं।

सोचा कि जागरूकता के लिए यहां पोस्ट करूंगा। मैं निम्नलिखित दस्तावेज पढ़ रहा था और इसने मुझे इस धागे के बारे में सोचने पर मजबूर कर दिया:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/custom-workflow-activities-workflow-assemblies

ऐसा लगता है कि Dynamics365 और PowerApps एक दिमागी मिश्रण कर रहे हैं और कुछ क्षमता में Windows वर्कफ़्लो का उपयोग कर रहे हैं, जो अब इसके वर्कफ़्लो को संभालने के लिए है। यह निश्चित रूप से केवल विंडोज़ है, लेकिन क्रॉस-प्लेटफ़ॉर्म आदि के नए युग में ... यह कब तक चलेगा?

मुझे नहीं पता कि मुझे क्या उपयोग करना चाहिए। काश MSFT ऐसा करता। स्पष्टता लाओ Microsoft.

@ वेंकटेशश्रीनी , आपको ताल पर भी ध्यान देना चाहिए: https://github.com/uber/cadence
मॉडल अमेज़ॅन के एसडब्ल्यूएफ की तरह है लेकिन यह खुला स्रोत है। हालांकि अभी तक कोई .NET क्लाइंट नहीं है।

एक की तलाश में। नेट कोर संस्करण

ऐसा नहीं होगा।

से: वेंकटेशश्रीनि नोटिफिकेशन @github.com
भेजा गया: बुधवार, 26 सितंबर, 2018 12:30 पूर्वाह्न
प्रति: dotnet/corefx [email protected]
सीसी: जेफरी माइकलसन [email protected] ; उल्लेख करें@noreply.github.com
विषय: पुन: [डॉटनेट/कोरएफएक्स] पोर्ट वर्कफ्लो फाउंडेशन से .NET कोर (#2394)

एक की तलाश में। नेट कोर संस्करण

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें https://github.com/dotnet/corefx/issues/2394#issuecomment-424581034 , या थ्रेड को म्यूट करें https://github.com/notifications/unsubscribe-auth/AVMP1qBfxwybd6ZxRkTuCurLahQ7ZZkNks5ZuwLNQYuCurLahQ7ZZkNks5ZuwLN4Faga .

बहुत बुरा

तो Microsoft गैर Azure पारिस्थितिकी तंत्र में ifttt या वर्कफ़्लो के लिए क्या पेशकश कर रहा है। जब वे एज़्योर से एमएल जैसी चीजों को सक्षम करना चाहते हैं तो वर्कफ़्लो क्यों नहीं?

डैन गेरलाग का काम देखें।

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

से: वेंकटेशश्रीनि नोटिफिकेशन @github.com
भेजा गया: बुधवार, 26 सितंबर, 2018 सुबह 8:34 बजे
प्रति: dotnet/corefx [email protected]
सीसी: जेफरी माइकलसन [email protected] ; उल्लेख करें@noreply.github.com
विषय: पुन: [डॉटनेट/कोरएफएक्स] पोर्ट वर्कफ्लो फाउंडेशन से .NET कोर (#2394)

तो Microsoft गैर Azure पारिस्थितिकी तंत्र में ifttt या वर्कफ़्लो के लिए क्या पेशकश कर रहा है। जब वे एज़्योर से एमएल जैसी चीजों को सक्षम करना चाहते हैं तो वर्कफ़्लो क्यों नहीं?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub https://github.com/dotnet/corefx/issues/2394#issuecomment-424697799 पर देखें, या थ्रेड को म्यूट करें https://github.com/notifications/unsubscribe-auth/AVMP1h2zWn4luwdz0QFNH- Jsl8L_4hIkks5ue3Q5gaJpZM4FaQMY ।

CoreWF है जो .net core के लिए वर्कफ़्लो फ़ाउंडेशन का एक पोर्ट है। यह बंदरगाह प्रगति कर रहा है। हम मदद के लिए लोगों की तलाश कर रहे हैं।

अगला प्रमुख कदम रोसलिन के साथ लोड किए गए वर्कफ़्लोज़ को संकलित करना है ताकि हम वर्कफ़्लो मापदंडों में कोड का उपयोग कर सकें, यह XAML परिभाषित वर्कफ़्लोज़ के लिए आवश्यक है। यदि आप इम्पीरेटिव कोर में कार्यप्रवाह परिभाषित करते हैं, तो आप अभी CoreWF का उपयोग कर सकते हैं।

आपके काम @ewington और @dmetzgar के लिए धन्यवाद! CoreWF में पोर्टेबल.XAML के माध्यम से XAML समर्थन उस प्रयास के लिए बहुत बड़ी बात है। @dmetzgar क्या आप जल्द ही NuGet पर एक नया संस्करण प्रकाशित करने की योजना बना रहे हैं?

नमस्ते,

क्या यह सब प्रोडक्शन तैयार है। हम बाहरी यूआई से कार्य प्रवाह परिभाषा को कम कर रहे हैं। लेकिन इंजन परिभाषा को लोड करने और उनके चालू से काम करने में सक्षम होना चाहिए। एक iffft प्रकार के अधिक

@VenkateshSrini , मुझे नहीं लगता कि Microsoft के लिए क्रॉस-प्लेटफ़ॉर्म वर्कफ़्लो फ्रेमवर्क प्रदान करना आवश्यक है। .NET Framework के दिनों में Microsoft ने वह सब कुछ प्रदान किया, जो समग्र समुदाय की हानि के लिए था। मैं संगठनों द्वारा अपनाई गई और "उत्पादन के लिए तैयार" .NET ओपन सोर्स लाइब्रेरी देखना चाहता हूं।

@watertree , मैं पोर्टेबल.एक्सएमएल की एक नई रिलीज की प्रतीक्षा कर रहा हूं। CoreWF XAML समर्थन के लिए आवश्यक एक महत्वपूर्ण सुधार है।

लंबे समय तक चलने वाले वर्कफ़्लोज़ के लिए अभी (दृढ़ता के साथ) क्या विकल्प है? केवल भुगतान वाले?

@ फ्रीराइडर7777

FYI करें: https://github.com/danielgerlag/workflow-core

हम इसे अपनी कंपनी में बहुत अच्छे परिणामों के साथ उपयोग करते हैं।

उन लोगों के लिए जो अभी भी अनुसरण कर रहे हैं, कोरडब्ल्यूएफ परियोजना ने गतिशील रूप से लोड किए गए एक्सएएमएल वर्कफ़्लो के निष्पादन की अनुमति देने के लिए रोज़लिन के एकीकरण के साथ एक महत्वपूर्ण मील का पत्थर आगे बढ़ाया है। यदि आपको अभी भी डॉटनेट कोर पर वर्कफ़्लो फाउंडेशन की आवश्यकता है, तो इसे देखें।

नमस्ते ,
क्या इसका मतलब है कि मैं मौजूदा एक्सएएमएल कार्य प्रवाह ले सकता हूं और हम इसे वैसे ही ले सकते हैं। क्या हमारी कोई सीमा है

क्या हमारी कोई सीमा है

इंस्टेंस स्टोर अभी तक पोर्ट नहीं किया गया है, डिज़ाइनर कोर पर नहीं है और WCF सर्वर अभी तक कोर पर नहीं होने के कारण WCF सेवा उपलब्ध नहीं है।

कृपया CoreWf रेपो पर एक मुद्दा बनाएं और अपनी आवश्यकताओं की सूची बनाएं। हम वहां बातचीत जारी रख सकते हैं।

corewf के लिए वर्तमान नगेट पुराना है और इसमें रोसलिन आधारित रनटाइम Xaml निष्पादन शामिल नहीं है जिसे अभी विलय किया गया है। हम अभी भी फीडबैक की तलाश में हैं कि क्या काम करता है और क्या नहीं।

क्या इसका मतलब यह है कि यह कभी नहीं होने वाला है?

ऐसा नहीं होने वाला है। यह कभी नहीं होने वाला था - - उन लोगों के लिए कोई अपराध नहीं जिन्होंने अपना सर्वश्रेष्ठ प्रयास किया। डैन गेरलाग की परियोजना (https://github.com/danielgerlag/workflow-core) या बाइट-द-बुलेट देखें और Azure LogicApps ट्रेन में सवार हों।

नमस्कार, यह अक्टूबर 2020 की कॉलिंग है। .NET कोर पर वर्कफ़्लो फाउंडेशन पर कोई समाचार/अपडेट/रिलीज़?

या हम सभी को एल्सा जाना चाहिए? https://elsa-workflows.github.io/elsa-core/

@wstaelens मुझे लगता है कि एमएस उत्तर बहुत स्पष्ट था : डब्ल्यूएफ को आधिकारिक तौर पर नेट कोर पर पोर्ट नहीं किया जाएगा। सुझाया गया विकल्प CoreWF है।