Quartznet: .NET कोर या vNext के लिए समर्थन

मैंने कुछ परीक्षण किए हैं लेकिन RC2 के लिए प्रतीक्षा करने का निर्णय लिया है क्योंकि इस समय चीजें काफी अस्थिर लग रही हैं। उम्मीद है कि v3 के पास इसके लिए कम से कम सीमित समर्थन होगा।

त्वरित जवाब के लिए धन्यवाद।

हमारे जैसे ओपन सोर्स प्रोजेक्ट (और कई अन्य) Quartz.NET पर निर्भर करते हैं। चूंकि Quartz.NET एक ढांचा है (वेब ​​अनुप्रयोगों के विपरीत), क्वार्ट्ज को .NET कोर का समर्थन करते हुए देखना रोमांचक होगा।

क्वार्ट्ज के बिना, कई वेब अनुप्रयोगों (जैसे हमारे) के लिए .NET कोर का समर्थन करना लगभग असंभव है। v3 के रिलीज होने का बेसब्री से इंतजार है और हम किसी भी तरह से योगदान करने के लिए तत्पर हैं।

नमस्ते @lahma , मैं माइक्रोसॉफ्ट की .NET ग्राहक सफलता टीम का सदस्य हूं। मेरी टीम जिन चीजों पर काम करती है उनमें से एक यह सुनिश्चित करना है कि उपयोगी तृतीय-पक्ष लाइब्रेरी .NET कोर और .NET मानक प्रोफ़ाइल के साथ काम करें। इसके भाग के रूप में, मैं .NET Core पर Quartz.Net चलाने में आपकी सहायता करना चाहता हूँ।

मैंने एक कांटेदार शाखा में कुछ मोटा प्रोटोटाइप किया है और बुनियादी परिदृश्य काम कर रहे हैं। उदाहरण के तौर पर, यहां एक साधारण शेड्यूलर का स्क्रीनशॉट है जो उबंटू पर चल रहे SQL सर्वर जॉब स्टोर का उपयोग कर रहा है:

जैसा कि आपने एक अलग थ्रेड में देखा, .NET Core में कई चीजें गायब या बदली हुई हैं, इसलिए सब कुछ ठीक करने और चलाने के लिए थोड़ा सा काम बाकी है। मुझे लगता है कि ज्यादातर काम होगा:

• रिमोटिंग निर्भरताओं को हटा रहा है। Quartz.Net में रिमोटिंग का उपयोग बहुत सीधा है, इसलिए इसे संभवतः HTTP अनुरोधों से बदला जा सकता है। हालाँकि, इसके लिए दूरस्थ अनुसूचक के उचित पुनर्लेखन की आवश्यकता होगी।
• System.Net.Mail उपयोग को किसी तृतीय-पक्ष विकल्प जैसे MailKit . से बदलें
• डेटाबेस एकीकरण को सक्षम करना। मैंने पहले ही एक नई .NET मानक-अनुपालक dbproviders.properties फ़ाइल बनाई है जो SQL सर्वर को काम करने में सक्षम बनाती है। हमें SQLite और PostgreSQL के लिए भी समर्थन जोड़ना चाहिए। अन्य अभी तक .NET कोर पर काम नहीं करते हैं, हालांकि कुछ जल्द ही आने की उम्मीद है।
• अब तक मेरे कुछ परिवर्तनों की समीक्षा करें और उन्हें साफ़ करें। मैंने SimpleThreadPool को .NET कोर पर काम करने के लिए कुछ त्वरित बदलाव किए हैं (चूंकि CLRTreadPool वहां काम नहीं करेगा), लेकिन हमें वापस जाना चाहिए और उचित .NET कोर-अनुपालन IThreadPool कार्यान्वयन बनाना चाहिए।
• परीक्षणों को .NET कोर में माइग्रेट करें और अपरिहार्य बगों को दूर करें।

यहां क्वार्टजनेट/क्वार्ट्जनेट -3 और मेरी विकास शाखा के बीच एक अंतर है। बहुत सारे परिवर्तन हैं, लेकिन अधिकांश को या तो क्रमांकन परिवर्तन, विविध एपीआई प्रतिस्थापन, या सुविधाओं को बंद करने (जैसे रिमोटिंग) के साथ करना है, जिसे हमें भविष्य में किसी अन्य तरीके से फिर से सक्षम करना होगा। मैंने उन सभी 'भविष्य के काम' स्थानों को "TODO (नेटकोर पोर्ट)" युक्त टिप्पणियों के साथ चिह्नित किया है।

क्या आप मेरे लिए यहां पिच करने के लिए तैयार होंगे? अंततः Quartz.Net आपका स्वामित्व और ड्राइव करने के लिए है, लेकिन मुझे इसे .NET कोर पर चलाने के लिए कुछ काम करने में मदद करने में प्रसन्नता हो रही है।

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

धन्यवाद, @फ्रैपिड। मैं हाल ही में ढाँचे में हुए सभी परिवर्तनों को लेकर बहुत उत्साहित हूँ और .NET कोर पारिस्थितिकी तंत्र को बनाने में मदद करने का अवसर पाकर मैं बहुत खुश हूँ।

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

@mjrousos यह बहुत अच्छी खबर है! मुझे वास्तव में खुशी है कि आपने इसमें रुचि ली है और मदद की है। मैं आपके परिवर्तनों को देखूंगा और उनसे सीखूंगा और कुछ और प्रश्न पूछूंगा। मेरा सरसरी निगाह था और वास्तव में अच्छा लग रहा था।

कुछ विचार जो मैं साझा करना चाहता हूं जिनका महत्व हो सकता है या नहीं भी हो सकता है:

• मैं इसे बाद की तुलना में जल्द ही v3 शाखा में ले जाना चाहता हूं, @danielmarbach async के साथ मदद कर रहा है और संभवत: कुछ आंतरिक परिवर्तन होंगे और उन परिवर्तनों को इन परिवर्तनों के साथ किया जाना चाहिए
• वेब एपीआई आधारित इंटरफ़ेस क्वार्ट्ज.वेब प्रोजेक्ट के तहत काम कर रहा है, अब एक प्लगइन के रूप में - रिमोटिंग को शायद v3 से पूरी तरह से हटाया जा सकता है
• SendMailJob में System.Net.Mail निर्भरता और नौकरी है जिसे कोर से निकाला जा सकता है और एक कोड उदाहरण के रूप में पेश किया जा सकता है जिसे पुस्तकालय के उपभोक्ता पक्ष पर फिर से लागू किया जा सकता है
• बाइनरी क्रमांकन यहां एक बड़ा दर्द बिंदु होगा, v2 डेटा बाइनरी प्रारूप में डेटाबेस में है और प्रारूप से दूसरे में माइग्रेशन (बाइनरी से JSON) खुद को मुश्किल साबित कर सकता है
  
  
  
  • बस कुछ ऐसा है जिस पर मेरी तरफ से विचार करने की जरूरत है
  
  

क्या आपके पास इस या किसी अन्य लक्ष्य पर काम करने के लिए किसी प्रकार का टाइम-बॉक्स है जहां आप 'विलय के लिए तैयार' के रूप में परिवर्तन पर हस्ताक्षर करने के लिए तैयार हैं? जैसा कि हम सभी सहायता प्राप्त कर सकते हैं, मैं परिवर्तनों को खींचने और ठीक करने में भी सहज हूं क्योंकि हम आपके पास सीमित हैं।

और एक बार फिर, मैं मदद के लिए बहुत आभारी हूं और इसकी सराहना करता हूं। मुझे RC2 के साथ चीजों को संभालने का तरीका जानने के लिए शायद बेशुमार घंटे लगे होंगे (RC1 के साथ मैंने कुछ लड़ाई के बाद हार मान ली)।

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

यदि प्राथमिक क्वार्ट्ज प्रोजेक्ट से रिमोटिंग (और कुछ हद तक, मेल) को हटाया जा सकता है, तो इससे पोर्ट बहुत आसान हो जाएगा। मुझे कोई कारण नहीं दिखता कि वेब एपीआई प्लगइन या मेलकिट प्लगइन बाद में .NET कोर के साथ काम करने के लिए नहीं बनाया जा सका।

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

1. सबसे आसान समाधान ग्राहकों को यह बताना होगा कि क्वार्ट्ज.नेट का नया .NET कोर कार्यान्वयन पुस्तकालय के पिछले संस्करणों से डेटाबेस जानकारी का उपयोग नहीं कर सकता है और उन्हें .NET कोर संस्करण का उपयोग करने के लिए तब तक इंतजार करना चाहिए जब तक कि वे नए सिरे से शुरू नहीं कर सकते। डेटाबेस।
2. लाइब्रेरी के पूर्ण डेस्कटॉप संस्करण में Json क्रमांकन को बहुत आसानी से सक्षम किया जा सकता है, इसलिए हो सकता है कि डेस्कटॉप Quartz.Net के लिए एक कॉन्फ़िगरेशन सेटिंग जोड़ी जा सके। यदि उपयोगकर्ता बाइनरी क्रमांकन चुनता है, तो उन्हें कुछ आकार के लाभ (और पश्चगामी संगतता) मिलेंगे, लेकिन यदि वे जोंस क्रमांकन चुनते हैं, तो वे डेस्कटॉप और क्वार्ट्ज.नेट के .NET कोर कार्यान्वयन के बीच डेटाबेस को साझा करने में सक्षम होंगे।
3. यदि नए .NET Core Quartz.Net के साथ काम करने के लिए पुरानी डेटाबेस जानकारी को स्थानांतरित करने की मांग है, तो एक स्टैंड-अलोन डेस्कटॉप .NET उपकरण बनाना संभव हो सकता है जो रूपांतरण करता है। हालाँकि, हमें उस परिदृश्य के बारे में और सोचना होगा।

जहां तक ​​समय की कमी है, मैं संभवत: कम से कम अगले कुछ हफ्तों के लिए अपना आधा या अधिक समय इस परियोजना को दे सकूंगा। उसके बाद, मेरे पास अन्य परियोजनाएं होंगी जिन पर मेरा ध्यान केंद्रित करने की आवश्यकता है लेकिन मैं पोर्ट के पूरा होने तक सप्ताह में कुछ घंटे Quartz.Net के साथ जुड़ना जारी रख सकता हूं। जहां तक ​​​​हमें चीजों को मर्ज करना चाहिए, मुझे लगता है कि आप सही हैं कि जल्द ही बेहतर है, लेकिन आइए दोबारा जांचें कि डेस्कटॉप क्वार्ट्ज.नेट कार्यान्वयन में कुछ भी गलती से वापस नहीं आया है।

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

एक डिफ़ॉल्ट क्रमबद्धता भी क्यों है? आप आसानी से कोर में अमूर्तता प्राप्त कर सकते हैं और सीरिएलाइज़र एक प्लगइन है जो सेट करते समय पैरामीटर के रूप में अनिवार्य है।

पूर्वाह्न २७.०४.२०१६ um १७:४८ schrieb माइक रूसो नोटिफिकेशन @github.com :

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

यदि प्राथमिक क्वार्ट्ज प्रोजेक्ट से रिमोटिंग (और कुछ हद तक, मेल) को हटाया जा सकता है, तो इससे पोर्ट बहुत आसान हो जाएगा। मुझे कोई कारण नहीं दिखता कि वेब एपीआई प्लगइन या मेलकिट प्लगइन बाद में .NET कोर के साथ काम करने के लिए नहीं बनाया जा सका।

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

सबसे आसान समाधान ग्राहकों को यह बताना होगा कि क्वार्ट्ज.नेट का नया .NET कोर कार्यान्वयन पुस्तकालय के पिछले संस्करणों से डेटाबेस जानकारी का उपयोग नहीं कर सकता है और उन्हें .NET कोर संस्करण का उपयोग करने के लिए तब तक इंतजार करना चाहिए जब तक कि वे नए सिरे से शुरू नहीं कर सकते। डेटाबेस।
लाइब्रेरी के पूर्ण डेस्कटॉप संस्करण में Json क्रमांकन को बहुत आसानी से सक्षम किया जा सकता है, इसलिए हो सकता है कि डेस्कटॉप Quartz.Net के लिए एक कॉन्फ़िगरेशन सेटिंग जोड़ी जा सके। यदि उपयोगकर्ता बाइनरी क्रमांकन चुनता है, तो उन्हें कुछ आकार के लाभ (और पश्चगामी संगतता) मिलेंगे, लेकिन यदि वे जोंस क्रमांकन चुनते हैं, तो वे डेस्कटॉप और क्वार्ट्ज.नेट के .NET कोर कार्यान्वयन के बीच डेटाबेस को साझा करने में सक्षम होंगे।
यदि नए .NET Core Quartz.Net के साथ काम करने के लिए पुरानी डेटाबेस जानकारी को स्थानांतरित करने की मांग है, तो एक स्टैंड-अलोन डेस्कटॉप .NET उपकरण बनाना संभव हो सकता है जो रूपांतरण करता है। हालाँकि, हमें उस परिदृश्य के बारे में और सोचना होगा।
जहां तक ​​समय की कमी है, मैं संभवत: कम से कम अगले कुछ हफ्तों के लिए अपना आधा या अधिक समय इस परियोजना को दे सकूंगा। उसके बाद, मेरे पास अन्य परियोजनाएं होंगी जिन पर मेरा ध्यान केंद्रित करने की आवश्यकता है लेकिन मैं पोर्ट के पूरा होने तक सप्ताह में कुछ घंटे Quartz.Net के साथ जुड़ना जारी रख सकता हूं। जहां तक ​​​​हमें चीजों को मर्ज करना चाहिए, मुझे लगता है कि आप सही हैं कि जल्द ही बेहतर है, लेकिन आइए दोबारा जांचें कि डेस्कटॉप क्वार्ट्ज.नेट कार्यान्वयन में कुछ भी गलती से वापस नहीं आया है।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें

मैंने परिवर्तनों पर चर्चा करने के लिए एक पुल अनुरोध बनाया: #359 । मैंने कुछ सामान टिप्पणी की जैसे वे आए, दूसरी/तीसरी बार एक ही चीज़ को देखने पर दोहराया नहीं गया। झंकार करने और मेरी रैंबलिंग पढ़ने के लिए सभी का स्वागत है। सामान्य अवलोकन:

• हम शायद अपवादों के लिए क्रमांकन छोड़ सकते हैं
• रिमोटिंग भागों को हटाया जा सकता है, REST'ish वेब एपीआई को उजागर किया जा सकता है
• बहुत सारी डेटामेम्बर विशेषताएँ .. जिन्हें मैं निजी सदस्यों के लिए समझता हूं लेकिन उम्मीद है कि हम Json.NET के पक्ष में कॉन्फ़िगर कर सकते हैं
• जैसा कि मेरी समीक्षा टिप्पणी में उल्लेख किया गया है और जैसा कि @danielmarbach ने यहां भी किया था, मुझे लगता है कि हम केवल क्रमांकन रणनीति चयन को अनिवार्य बना सकते हैं, उपयोगकर्ता को वहां एक सूचित निर्णय करने की आवश्यकता है
• नया SimpleThreadPool कार्यान्वयन एक बड़ी अनुपलब्ध कड़ी है (नियंत्रणीय थ्रेड काउंट, प्राथमिकताएं आदि)

हम चिंताजनक डेटाबेस माइग्रेशन को बाद के चरण में छोड़ सकते हैं। मैं इस भूमि को शीघ्र ही v3 शाखा में देखना चाहता हूँ।

कुल मिलाकर, बढ़िया काम! :+1:

महान; धन्यवाद, @ लहमा। मैं पीआर पर एक नज़र डालूंगा और टिप्पणियों का जवाब दूंगा। और मैं मानता हूं कि यह समझ में आ सकता है कि केवल क्रमबद्धता प्लग करने योग्य है और उपयोगकर्ताओं को वह चुनना है जो वे उपयोग करना चाहते हैं।

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

हम Quartz.net का बेसब्री से इंतजार कर रहे हैं ताकि हमारे समाधान को vNext में पोर्ट किया जा सके।

क्या हमारे पास नगेट में अल्फा बिल्ड हो सकता है ताकि लोग कम से कम अपनी परियोजनाओं का संदर्भ और संकलन कर सकें?

उम्मीद है कि हम अगले कुछ हफ़्तों में कुछ अल्फा गुणवत्ता प्राप्त कर सकते हैं ताकि आप टायरों को किक कर सकें। एपीआई स्थिर नहीं होगा और न ही कोई दूरस्थ प्रबंधन समर्थन होगा।

व्यक्तिगत रूप से, मुझे लगता है कि दूरस्थ प्रबंधन कोरक्लर संस्करण से बाहर रह सकता है। मुझे लगता है कि लोग इसे एमवीसी ऐप के साथ सामने रखकर इसे संभालना चाहेंगे। यह एक क्वार्ट्ज चिंता का विषय नहीं होना चाहिए।

IThreadPool के लिए, मैंने एक संस्करण लिखा है जो उन कार्यों पर निर्भर करता है जिन्हें मैं आपकी रुचि होने पर वापस योगदान कर सकता हूं।

इसे अंदर लाओ। मेरे पास इसे फिर से काम करने की योजना है लेकिन वर्तमान में सैन्य सेवा में है। लगभग 2 सप्ताह में इस पर वापस जाएंगे

30.04.2016 पूर्वाह्न 13:12 शॉन बेकर अधिसूचनाएं @github.com :

IThreadPool के लिए, मैंने एक संस्करण लिखा है जो उन कार्यों पर निर्भर करता है जिन्हें मैं आपकी रुचि होने पर वापस योगदान कर सकता हूं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें

मेरे पास कार्यों का उपयोग करके IThreadPool कार्यान्वयन भी है। मैंने इसे चल रहे .NET कोर पीआर में जोड़ा है, हालांकि आप केवल IThreadPool से संबंधित परिवर्तनों को देखने के लिए यहां भी देख सकते हैं। @smbecker , @danielmarbach , कृपया एक नज़र डालें और मुझे बताएं कि क्या आप ऐसी चीजें देखते हैं जिन्हें यहां आपके अपने काम के आधार पर बेहतर बनाया जा सकता है।

मैंने अभी-अभी @mjrousos से परिवर्तनों के पहले बैच में

मैं आगे रिमोटिंग बिट्स को बदलने के लिए काम कर रहे पीओसी बनाने की कोशिश करूंगा।

:+1:

पूर्वाह्न ०३.०५.२०१६ उम ०६:५३ श्राइब मार्को लाहमा नोटिफिकेशन @github.com:

मैंने अभी-अभी @mjrousos से परिवर्तनों के पहले बैच में

मैं आगे रिमोटिंग बिट्स को बदलने के लिए काम कर रहे पीओसी बनाने की कोशिश करूंगा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें

धन्यवाद, @ लहमा! जब आप रिमोटिंग बिट्स को बदलने पर काम करते हैं तो मुझे बताएं कि क्या आपके पास कोई .NET कोर से संबंधित प्रश्न हैं।

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

इसका परीक्षण करने के लिए, मैंने एक साधारण .NET Core RC2 'साझा सूची' बनाई जो कि केवल एक सूची हैजो दूरस्थ मशीनों को सूची को देखने/हेरफेर करने के लिए कनेक्ट करने की अनुमति देता है। आप यहां (कुछ गड़बड़) कोड पर एक नज़र डाल सकते हैं।

यहाँ उस नमूने के प्रासंगिक अंश दिए गए हैं:
मेरे सरल प्रोटोटाइप में, IWebHost की स्थापना इस तरह दिखती है:

``` सी#
होस्ट = नया वेबहोस्टबिल्डर ()
.UseServer("Microsoft.AspNetCore.Server.Kestrel")
कॉन्फ़िगर करें (ऐप =>
{
// आने वाले अनुरोधों को संसाधित करने के लिए मिडलवेयर फ़ंक्शन
app.Use(async (HttpContext प्रसंग, Func .)अगला) =>
{
अगर (संदर्भ। अनुरोध। पथ। मान == पथ && संदर्भ। अनुरोध। सामग्री लंबाई> 0)
{
// अनुरोध के शरीर को एक InvokeRequest ऑब्जेक्ट (एक वर्ग जिसे हम परिभाषित करते हैं) में डिसेरिएलाइज़ करें
InvokeRequest invokeRequest = डिफ़ॉल्ट (InvokeRequest);
InvokeRequest = (InvokeRequest)invokeRequestSerializer.ReadObject(context.Request.Body);

            object reply = null;
            // Try to dispatch the call
            if (Invoke(invokeRequest, ref reply))
            {
                // I used DCS in my prototype, but probably we should use JSON.NET since Quartz.Net already uses it elsewhere
                var replySerializer = new DataContractJsonSerializer(reply.GetType());
                using (var ms = new MemoryStream())
                {
                    replySerializer.WriteObject(ms, reply);
                    await context.Response.WriteAsync(new string(Encoding.UTF8.GetChars(ms.ToArray())));

                    // Halt the HTTP request processing pipeline
                    return;
                }
            }
        }
        await next();
    });
})
.Start(new[] { $"http://0.0.0.0:{port}" });

``` C#
private bool Invoke(InvokeRequest invokeRequest, ref object reply)
{
    // In my simple test, the methods that could be invoked were just simple APIs to manipulate a list.
    // In the real Quartz.Net product, we will need to support more methods. Because of that, it may make sense to just use reflection to build the list of APIs that can be called dynamically when the host starts.
    switch (invokeRequest.MethodName)
    {
        case "Add":
            Console.WriteLine("Invoking 'Add'");
            list.Add(invokeRequest.Arguments[0] as string);
            return false;
        case "GetEnumerator":
            Console.WriteLine("Invoking 'GetEnumerator'");
            reply = list.ToArray();
            return true;
        default:
            Console.WriteLine($"Unknown method: {invokeRequest.MethodName}");
            return false;
    }
}    

C# public struct InvokeRequest { public string MethodName { get; set; } public object[] Arguments { get; set; } }

रिमोट कॉल करने के लिए, रिमोटिंग क्लाइंट सर्वर द्वारा एंडपॉइंट सेटअप को कॉल करने के लिए केवल HttpClient का उपयोग कर सकता है।

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

सहमत, @smbecker। मुझे नहीं पता कि यह पुरानी शैली के रिमोटिंग की तुलना में रनटाइम पर अधिक संसाधन-गहन है, लेकिन यह निश्चित रूप से एक उचित कोड है और इसमें बहुत सारे बदलाव की आवश्यकता होगी। यदि लोग इस तरह से पुराने Quartz.Net उत्पादों से भिन्न कोर पर Quartz.Net के साथ ठीक हैं, तो शायद यह अपने स्वयं के पुस्तकालय में अलग होने के लिए एक अच्छा उम्मीदवार है।

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

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

ऐसा लगता है कि यह काम कर सकता है (और कोर लाइब्रेरी से ASP.NET निर्भरता को हटा देगा, जो अच्छा होगा)। यदि आप Quartz.Net में HttpClient निर्भरता भी नहीं रखना चाहते हैं, तो संभवतः आपके पास क्लाइंट के लिए एक अलग पुस्तकालय भी हो सकता है, और यह मानक से प्राप्त एक बाल अनुसूचक बना सकता है। अनुबंध डीटीओ समझ में आता है लेकिन अगर हम उन्हें बाल कार्यान्वयन में उपयोग करना चाहते हैं तो उन्हें protected चिह्नित किया जा सकता है।

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

बस देखा कि RC2 गिर गया और यह देखना चाह रहा था कि क्या Quartz.net .net कोर तैयार है और मुझे यह देखकर खुशी हुई कि यह इस तरह से आगे बढ़ रहा है।

क्या अब इस पर कोई खबर है कि (मैं केवल एक सप्ताह तक जानता हूं)। नेट कोर 1.0.0 पर है?

जब मैं "डॉटनेट रिस्टोर" चलाने की कोशिश करता हूं, तो मुझे यह कहते हुए एक त्रुटि मिलती है कि क्वार्ट्ज 2.3.3 फ्रेमवर्क का समर्थन नहीं करता है। नेटस्टैंडर्ड, वर्जन = v1.6।

कृपया कृपया, मुझे नेट कोर के लिए काम करने के लिए वास्तव में इसकी आवश्यकता है। :)

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

मैंने स्रोत से निर्माण करने की कोशिश की लेकिन ऐसा नहीं लगता कि आप .NET कोर प्रोजेक्ट में बाहरी डीएलएल का संदर्भ दे सकते हैं (कम से कम, मैं इसे काम पर नहीं ला सकता) और मैं .NET के भीतर से कोड संकलित नहीं कर सकता कोर प्रोजेक्ट, शुरुआत के लिए क्योंकि Common.Logging Nuget पैकेज भी अभी तक संगत नहीं है। शायद मेरे पास इसे दूर करने के लिए आवश्यक आवश्यक अनुभव नहीं है ...

@robborden क्या आपने क्वार्टजनेट -3 शाखा खींची थी? यही वह शाखा है जिसे .Net Core में बनाया जा सकता है। (मैं वर्तमान में इसके साथ एक प्रोजेक्ट में खेल रहा हूं जिसे मैं बना रहा हूं और यह काम करता है)।

धन्यवाद @cjnanda , मैं इसे आज़मा दूंगा।

अल्फा 1 NuGet पर आ गया है, कृपया घोषणा देखें। अभी बहुत कुछ करना बाकी है लेकिन अब टायरों को किक करना आसान होना चाहिए।

कुछ नोट:

• अलग पैकेज के रूप में अलग क्वार्ट्ज। सीरियलाइजेशन। जेसन, क्वार्ट्ज की अब JSON.NET जैसी निर्भरता नहीं है
• रिमोटिंग विकल्प तैयार नहीं है
• ड्रेगन होंगे

बहुत बढ़िया! लोगों को आज़माने के लिए वहाँ बिट्स देखना बहुत अच्छा है।

अब जब 2.4 जारी किया गया है तो मैंने v3 शाखा को मास्टर में विलय कर दिया है। सभी v3 कार्य अब मास्टर के विरुद्ध हैं।

मैं इसे भी कोशिश करूँगा!

v3 के लिए ईटीए पर कोई विचार या उत्पादन के उपयोग के लिए यह कितना स्थिर है? मुझे नेटस्टैंडर्ड और एसिंक्स सपोर्ट दोनों में दिलचस्पी है।

वाह वाह। पिछले साल अक्टूबर के बाद से अजीब बात है, इस बारे में पूछने वाली एक टिप्पणी उसी दिन (और घंटे) पर है, मैं इसे खोजने आया हूं!

महान कार्य लोग। कोई विचार जब हमारे पास .NET कोर (Quartz.NET 3.0) उत्पादन रिलीज़ होगा?

कोई विचार है कि यह कितनी दूर है या इसे समाप्त करने के लिए सहायता की आवश्यकता है? हमारे कुछ उपयोगों को अपडेट करने में सक्षम होने के लिए बहुत अच्छा होगा। उदाहरण के लिए https://github.com/MassTransit/MassTransit/issues/909

बस यहां एक अपडेट देने के लिए, मेरे पास 2.x और 3.0 के साथ मौजूदा समस्याओं को दूर करने के लिए कुछ समय है, लेकिन अगला अल्पा ज्यादातर बग फिक्स और .net कोर 2 समर्थन + एपीआई सफाई के बारे में होगा। उम्मीद है कि मुझे अगला अल्फा जल्द ही मिल जाएगा (मेरी गर्मी की छुट्टी अपने अंत तक पहुंच रही है)।

@lahma बस इस परियोजना के लिए धन्यवाद कहना चाहता था और .net मानक समर्थन के लिए काम करना चाहता था! कुछ महीनों के लिए डॉकर + पोस्टग्रेज + क्लस्टर वातावरण में 3.0.0 अल्फा 2 चल रहा है और अधिकांश भाग के लिए एक इलाज काम करता है। .net कोर 2 समर्थन के लिए तत्पर हैं। मैं

और 3.0 अल्फा 3 बाहर है! हमेशा की तरह, सभी फीडबैक और परीक्षण अमूल्य हैं, कृपया टायरों को किक करें और देखें कि यह कैसा है।

मैं इस मुद्दे को बंद कर रहा हूं क्योंकि .NET कोर समर्थन मौजूद है, मैंने अभी बीटा 1 उपलब्ध कराया है ।

नमस्ते,

से: https://github.com/quartznet/quartznet/issues/355#issuecomment -215127050

1. यदि नए .NET Core Quartz.Net के साथ काम करने के लिए पुरानी डेटाबेस जानकारी को स्थानांतरित करने की मांग है, तो एक स्टैंड-अलोन डेस्कटॉप .NET उपकरण बनाना संभव हो सकता है जो रूपांतरण करता है। हालाँकि, हमें उस परिदृश्य के बारे में और सोचना होगा।

क्या यह उपकरण कभी बनाया गया था? हम इस परिदृश्य का सामना कर रहे हैं।
यदि ऐसा नहीं था, तो क्या इसे प्राप्त करने का कोई अनुशंसित तरीका है?
किसी भी जानकारी की सराहना करेंगे।

अग्रिम में धन्यवाद,
ईयाल