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

और मैं इस बात से सहमत नहीं हूं कि "JSON उन निर्भरताओं का प्रतिनिधित्व करने के लिए आसान है"। पक्ष-विपक्ष हैं। इसे देखें https://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

मैं परिवर्तन के बारे में सहमत हूं _if_ nuget.json पर जा रहे थे। यह प्रोजेक्ट का एकमात्र हिस्सा है। जेसन जिसे मैंने सोचा था कि वैसे भी संपादन योग्य होने की जरूरत है।

वर्बोसिटी के मामले में

@sandorfr यह है। हालांकि, मुझे संदेह है कि एक्सएमएल आधारित प्रोजेक्ट सिस्टम में वापस जाने के कारणों में से एक कारण .net पारिस्थितिकी तंत्र में एक्सएमएल आधारित प्रोजेक्ट सिस्टम के आसपास मौजूदा महत्वपूर्ण टूलिंग है। मेरी टिप्पणियां सर्वोत्तम प्रारूप को आजमाने और पहचानने के लिए नहीं हैं, केवल यह इंगित करने के लिए कि एक्सएमएल आंतरिक रूप से खराब नहीं है।

जी हां और यह इस हफ्ते की सबसे बुरी खबर है। यह समय पर वापस लाया जा रहा है ... :(वास्तव में एक्सएमएल खराब नहीं है, एमएसबिल्ड हालांकि ... और एक एमएसबिल्ड एक्सएमएल बेस प्रोजेक्ट उतना आसान नहीं होगा जितना आपने वर्णन किया है।

हालांकि, मुझे संदेह है कि एक्सएमएल आधारित प्रोजेक्ट सिस्टम में वापस जाने के कारणों में से एक कारण .net पारिस्थितिकी तंत्र में एक्सएमएल आधारित प्रोजेक्ट सिस्टम के आसपास मौजूदा महत्वपूर्ण टूलिंग है।

मुझे समझ में नहीं आता कि सभी चीजों को " कोर " के साथ क्यों जोड़ा गया है, यह इंगित करने के लिए कि यह एक नई चीज है यदि इरादा एमएसबिल्ड की तरह सामान को आगे ले जाने का भी है।

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

वहाँ बहुत से पारिस्थितिकी तंत्र नहीं हैं जिनमें XML आधारित विन्यास है। वास्तव में, सभी नए डिज़ाइन किए गए पारिस्थितिक तंत्र अन्य स्वरूपों (YAML, JSON, आदि) को अपना रहे हैं। सोशल मीडिया पर सभी लोगों की प्रतिक्रिया को देखिए, मुझे ऐसे बहुत से लोग नहीं दिख रहे हैं जो इस बदलाव को पसंद करते हैं। हालांकि, निजी तौर पर दी गई प्रतिक्रिया टीम के लिए अधिक महत्वपूर्ण लगती है। यह कोई बुरी बात नहीं है, मैं कारणों को समझता हूं लेकिन यह सिर्फ यह दिखा रहा है कि इस पारिस्थितिकी तंत्र पर निर्णय कैसे संसाधित किए जा रहे हैं।

सप्ताह की सबसे बुरी खबर पर +1। इस पर चर्चा कहां हुई? मुझे कुछ नहीं मिला, बस एकतरफा फैसला।

मुझे इस निर्णय के लिए कोई समुदाय समर्थन नहीं दिख रहा है, और इसके खिलाफ बहुत कुछ (अंतिम गणना में 85% से 15%)। किस सूचना के आधार पर निर्णय किसने लिया, चर्चा कैसी रही?

क्या हम .NET कोर में इस तरह काम कर रहे हैं? बंद दरवाजों के पीछे गुणवत्ता से समझौता करना क्योंकि हम विरासत तकनीक की एक अज्ञात सूची का समर्थन करना चाहते हैं?

हर तरह से एक VS एक्सटेंशन करते हैं जो एक project.json से .csproj बनाता है जिसका उपयोग करने वाले लोग उन पुरानी तकनीकों का उपयोग कर सकते हैं।

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

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

मेरी राय में यह होगा:

• प्रत्येक सीएस-फ़ाइल निर्दिष्ट करने की आवश्यकता नहीं है
• प्रोजेक्ट को अनलोड किए बिना फ़ाइल को संशोधित करने में सक्षम होना
• फ़ाइल में सीधे nuget निर्भरताओं को संशोधित करने में सक्षम होने के नाते (IntelliSense के साथ)
• Global.json के माध्यम से nuget संकुल को स्थानीय स्रोत से बदलने में सक्षम होने के नाते

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

यदि यह पूरा किया जा सकता है, तो मैं उनके द्वारा उपयोग किए जाने वाले सिंटैक्स के साथ ठीक हूं। एक्सएमएल बहुत अच्छा नहीं है लेकिन जेएसओएन के स्पष्ट रूप से इसके नुकसान भी हैं।

संपादित करें: मुझे लगता है कि यह .NET कोर आदि के किसी भी मौलिक (और महान) विचारों को नहीं बदलता है।

IMHO, मुख्य समस्या यह है कि RTM से ठीक पहले इस प्रकार के कठोर परिवर्तन अच्छे नहीं हैं। यदि बीटा समय में ऐसा होता है तो डेवलपर्स/टीमों को इतना आश्चर्य नहीं होगा। उन निवेशों के बारे में सोचें जो Project.json सिस्टम के आधार पर मौजूदा उत्पादों/पुस्तकालयों/ढांचे के बारे में सोचें। Asp.Net आरसी में पूर्वावलोकन/अल्फा/बीटा में नहीं है, इस प्रकार के परिवर्तन डेवलपर्स/टीमों के विश्वास को तोड़ते हैं :(।

IMHO, मुख्य समस्या यह है कि RTM से ठीक पहले इस प्रकार के कठोर परिवर्तन अच्छे नहीं हैं।

मैंने भी पहले ऐसा ही सोचा था लेकिन जहाँ तक मैं इसे समझता हूँ, इससे आपके आवेदन कोड में कोई परिवर्तन नहीं होगा। यह केवल आपकी project.json/xproj/csproj फ़ाइलों को प्रभावित करेगा और उन्होंने कहा कि परिवर्तन स्वचालित हो सकता है - इसलिए यह अच्छे पुराने प्रोजेक्ट माइग्रेशन चरणों के समान होगा जो पहले से ही कई बार हो चुके हैं जब आपने विजुअल स्टूडियो को अपग्रेड किया था।

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

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

शायद यह अजीब है लेकिन वे अलग-अलग चीजों का जवाब देते हैं project.json एक .net कोर प्रोजेक्ट बनाने के लिए आवश्यक एकमात्र फाइल है और xproj मालिकाना टूलिंग उर्फ ​​​​विजुअल स्टूडियो से संबंधित है। यदि आप अपने नोड प्रोजेक्ट पर काम करने के लिए वेबस्टॉर्म का उपयोग करते हैं तो यह package.json और .idea के समान ही है। बस चिंताओं को अलग करना। विजुअल स्टूडियो प्रोजेक्ट.जेसन को प्रॉपर्टीज के तहत छिपा सकता है यदि वे पसंद करते हैं और मर्ज किए गए क्यूरेटेड गुई अनुभव की पेशकश करते हैं यदि वे सब कुछ एक साथ मिलाए बिना पसंद करते हैं।

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

मुझे लगता है कि आप बहुत निराशावादी हो रहे हैं - और मुझे लगता है कि इसका मुख्य कारण यह है कि हम सभी इससे हैरान हैं

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

http://c2.com/cgi/wiki?XmlSucks
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
http://nothing-more.blogspot.co.za/2004/10/where-xml-goes-astray.html

अब, .NET कोर बनाया जा रहा है जब सभी को लगता है कि JSON सब कुछ हल कर देगा। मुझे विश्वास नहीं है कि जेएसओएन एक्सएमएल की तुलना में दीर्घकालिक समाधान है, लेकिन मुझे पता है कि एक्सएमएल की तुलना में जेएसओएन संघर्षों को मर्ज करना आसान है।

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

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

@DamianEdwards ने स्पष्ट रूप से कहा कि वे project.json मॉडल के अच्छे हिस्से रखना चाहते हैं।

मेरे दृष्टिकोण से, project.json मॉडल का सबसे अच्छा हिस्सा यह है कि यह csproj नहीं है, MSBuild नहीं है, और XML नहीं है। क्या उन "अच्छे" भागों को रखा जाएगा? जाहिरा तौर पर नहीं। जब हमें विश्वास हो गया कि वे अंततः टर्फ हो रहे हैं, तो यह पता चला कि यह सब गलत दिशा थी। हमें नए बिल्ड सिस्टम के बारे में बताया गया, गल्प और प्रोजेक्ट.जेसन के बारे में और अब चीजें कैसे अलग होंगी, और फिर यह पता चला कि यह सब एक दिखावा था और यह फिर से पुराना पुराना MSBuild है।

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

यदि आप इससे बचना चाहते हैं तो आपको वाईएएमएल आदि में जाना होगा।

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

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

इस पूरी चीज़ के बारे में मेरी मुख्य चिंता यह है कि मैंने इसके बारे में बहुत कुछ नहीं सुना है कि project.json जब संदर्भों की बात आती है तो .csproj प्रोजेक्ट फाइलों की तुलना में अधिक घोषणात्मक होता है। project.json फ़ाइल में निर्भरता की सुंदरता और मैं अपने कोडबेस को इसमें माइग्रेट करने के लिए क्यों उत्सुक था, यह है कि आप बस कहते हैं "मुझे इस निर्भरता की आवश्यकता है" और इससे कोई फर्क नहीं पड़ता कि यह एक स्थानीय परियोजना है या एक नुगेट पैकेज। हमारे मामले में, यह हमें बहुत अधिक लचीलापन और नए विकल्प प्रदान करेगा। इसके विपरीत, वर्तमान में .csproj फ़ाइल में एक संदर्भ डिस्क पर .dll फ़ाइल के लिए एक कठिन, सापेक्ष पथ है। अभी, एक पारंपरिक प्रोजेक्ट में आपके package.config में एक प्रविष्टि जोड़ने से वास्तव में कुछ नहीं होता है, आपको उस पैकेज से .csproj फ़ाइल में एक विशिष्ट .dll संदर्भ भी जोड़ना होगा। . यह आपके लिए विजुअल स्टूडियो के अंदर NuGet टूल द्वारा किया गया है, लेकिन मैं उन टूल का उपयोग नहीं करना चाहता जब project.json फ़ाइल में टेक्स्ट की एक पंक्ति जोड़ना बहुत आसान है।

मैं मानता हूं कि टीम project.json फ़ाइल द्वारा प्रदान की गई सभी कार्यक्षमताओं को रखना चाहती है और .csproj प्रारूप की सुविधाओं का विस्तार करना चाहती है, लेकिन उन्होंने project.json को फ़ाइल के रूप में रखने के बारे में भी बात की। अपने NuGet पैकेजों को निर्दिष्ट करने के लिए। मुझे नहीं लगता कि packages.config साथ वर्तमान स्थिति की तुलना में यह क्या जोड़ देगा, जहां केवल इसमें एक प्रविष्टि जोड़ना पर्याप्त नहीं है क्योंकि आपको अभी भी एक संदर्भ जोड़ने की आवश्यकता है .dll में .csproj भी। यदि .csproj फ़ाइल को भविष्य बनना है, तो मैं कोर टीम को पूरी तरह से आगे बढ़ते हुए देखना चाहूंगा और project.json या nuget.json को छोड़ दूंगा या फिर इसे _entirely_ कह कर जोड़ दूंगा .csproj प्रारूप में संदर्भ जोड़ने का एक अधिक घोषणात्मक तरीका। मैं एक JSON फ़ाइल के बजाय एक XML फ़ाइल को संपादित करने के साथ ठीक रह सकता हूं (हालांकि मैं निश्चित रूप से JSON पसंद करता हूं) लेकिन project.json की घोषणात्मक प्रकृति को खोना एक वास्तविक शर्म की बात होगी और मुझे दो की आवश्यकता नहीं है विभिन्न स्थान जहां मुझे अपनी निर्भरताओं को निर्दिष्ट करने की आवश्यकता है।

कृपया प्रतिक्रिया दें https://www.surveymonkey.com/r/H6Q88PP

बस स्पष्ट होने के लिए, स्टैंडअप नोट्स को पढ़ने में, यह उल्लेख करता है कि एक विकल्प nuget install --save प्रकार का विकल्प है (देखें https://blogs.msdn.microsoft.com/webdev/2016/05/11/ नोट्स-से-द-एएसपी-नेट-समुदाय-स्टैंडअप-मई-10-2016/)। जबकि मुझे लगता है कि यह एक अच्छा विचार है, 'एडिट .json फाइल को इंटेलिजेंस के साथ' से बदलना, मुझे लगता है कि यह एक बुरा विचार है। मुझे लगता है कि संपादक में रहना हममें से कुछ लोगों के लिए एक अच्छा विचार है जो सब कुछ करने के लिए एक खोल में स्विच नहीं करना चाहते हैं। मेरी प्राथमिकता, व्यक्तिगत रूप से, दोनों अनुभव प्राप्त करना है। कमांड-लाइन + UI निर्भरता जोड़ने के लिए पर्याप्त नहीं हैं।

मैं एक कोडर हूं, मैं संपादक को नहीं छोड़ना चाहता।

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

MSBUILD फाइलों पर मेरा पसंदीदा उद्धरण?

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

स्रोत

मुझे लगता है कि एमएसबिल्ड और विजुअल स्टूडियो वर्तमान में एमएसबिल्ड का उपयोग करने के तरीके के बीच अंतर करना महत्वपूर्ण है। मैं वर्षों से एमएसबिल्ड फाइलों को संपादित कर रहा हूं और मेरी सभी परियोजनाओं के लिए उनका उपयोग कर रहा हूं। जैसे https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj

विजुअल स्टूडियो द्वारा बनाई गई csproj फाइलें बहुत खराब हैं, लेकिन MSBuild पर यह दोष देना कि C# बकवास है क्योंकि आपने एक कोड जनरेटर को एक बार इसके साथ बदसूरत कोड बनाते देखा है।

@darrelmiller मैं सहमत हूँ।

आइए 6 महीने आगे बढ़ते हैं और देखते हैं कि क्या यह "आपको ऐसा बताया" क्षण है या "बुलेट को चकमा दिया" से अधिक है।

अपने ब्लॉग पर @shawnwildermuth कॉल के बाद मैं अपने 2 सेंट में फेंक दूंगा:

मैं नहीं देखता कि यह इतनी बड़ी बात क्यों है। मुझे XML-आधारित csproj पर वापस जाने में प्रसन्नता हो रही है, क्योंकि:

• JSON को मैन्युअल रूप से संपादित करना XML से अधिक स्वाभाविक/आसान नहीं है। यह वास्तव में विपरीत IMHO है। हर बेवकूफ संपादक मुझे एक्सएमएल टैग पूर्णता देता है, एक प्रारूप त्रुटि को मैन्युअल रूप से खोजना आसान है और इसी तरह। अगर मुझे इसे मैन्युअल रूप से लिखना है तो JSON आसान नहीं है। यह कहना मुझे बिंदु 2 पर लाता है ...
• पहली बार में एक संपादक के साथ एक प्रोजेक्ट फ़ाइल को संपादित करने के बारे में इतना उपद्रव क्यों है? किसी प्रोजेक्ट फ़ाइल को संपादित करना वह जगह नहीं है जहाँ मैं एक डेवलपर के रूप में अपना समय बिताना चाहता हूँ। यह एक नई परियोजना की शुरुआत में एक बार की बात होनी चाहिए, लेकिन उसके बाद आईएमएचओ बहुत बार नहीं होना चाहिए। अगर मुझे इसे JSON, XML, YAML, TOML या उस समय किसी की पसंद के साथ संपादित करना है, तो यह मेरे लिए पूरी तरह से अप्रासंगिक है।
• एक चीज जिसे मैं टालना चाहता हूं वह है ASP.NET के साथ NuGet को कसकर जोड़ना । NuGet बहुत अच्छा है, मुझे यह पसंद है और मैं चाहता हूं कि मेरा ASP.NET इसके साथ बहुत अच्छी तरह से काम करे, लेकिन ASP.NET को चलाने के लिए इसकी आवश्यकता नहीं है। हां, मुझे एमवीसी, आदि की सुविधाओं को प्राप्त करने के लिए एक NuGet फ़ीड से बायनेरिज़ खींचने की आवश्यकता हो सकती है, लेकिन क्या मैं इसे आधिकारिक NuGet फ़ीड के माध्यम से करता हूं, या यदि मैं स्रोतों को खींचता हूं, तो इसे स्थानीय रूप से संकलित करें और कॉपी पेस्ट करें। फ़ोल्डर एक लचीलापन होना चाहिए जो मेरे लिए उपलब्ध रहता है। मैं नहीं चाहता कि ASP.NET, csproj या किसी अन्य चीज़ को उन "समर्थन" तृतीय पक्ष प्रणालियों के साथ कसकर जोड़ा जाए। मैं चाहता हूं कि वे एक महान एकीकरण की अनुमति दें, लेकिन अनुकूलन के लिए दरवाजा खुला रखें ! इसलिए मुझे उम्मीद है कि NuGet संकुल को .csproj फ़ाइल में घोषित नहीं किया जाएगा और एक nuget.json को MSBuild में कसकर एकीकृत नहीं किया जाएगा।
  एक अच्छी तरह से परिभाषित इंटरफ़ेस के पीछे सख्त एकीकरण == महान।
  तंग युग्मन, यह मानते हुए कि यह सभी के लिए मानक है == BAD।
• अंत में, मैं यह कहना चाहता हूं कि project.json का .NET Core और ASP.NET Core से बहुत कम लेना-देना है। प्रोजेक्ट.json फ़ाइल की तुलना में कोर के पास देने के लिए बहुत कुछ है। Project.json कोई नई विशेषता नहीं थी, यह किसी ऐसी चीज़ को फिर से डिज़ाइन करने का प्रयास था जो पहले से ही किसी भिन्न स्वरूप में मौजूद थी। मैं इसके बारे में बहुत ज्यादा परवाह नहीं करता, क्योंकि एक डेवलपर के रूप में मैं .NET कोर द्वारा दी गई नई सुविधाओं और संभावनाओं पर ध्यान केंद्रित करता हूं ताकि मुझे एक बार में उबाऊ कॉन्फ़िगरेशन के बजाय क्लाउड में एक महान एप्लिकेशन विकसित करना पड़े।

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

यही कारण है कि मैं शायद एक नया क्रॉस प्लेटफॉर्म रनटाइम लागू करने के बजाय मोनो को बेहतर बनाना और अंतराल को बंद करना पसंद करता, लेकिन यह एक अलग चर्चा है।

अंतिम सर्वेक्षण परिणाम: 9 मिलियन .NET डेवलपर आबादी के लिए 100 प्रतिक्रियाएं, जो 95% विश्वास के साथ ± 10% है।

क्या आपको project.json का कदम पसंद आया?
हाँ, यह मेरी सबसे प्रत्याशित विशेषताओं में से एक थी 19.19%
हाँ 39.39%
नहीं 13.13%
नहीं, यह 16.16% लेने के लिए एक भयानक दिशा थी

क्या आप MSBuild में वापस जाने से खुश हैं?
हाँ, अब मैं इसे 9.09% अपनाने के बारे में सोच सकता हूँ
हाँ 16.16%
नहीं 30.30%
नहीं, यह मुझे दिशा पर सवाल खड़ा करता है। NET कोर 29.29% ले रहा है
परवाह मत करो 15.15%

क्या आप मानते हैं कि MSBuild में सुधार किया जाएगा
सुधार हुआ? यह पहले से ही एकदम सही है। 1.01%
हाँ 63.64%
नहीं 12.12%
यह मूल रूप से टूटा हुआ है, इसे कैसे सुधारा जा सकता है? 20.20%
परवाह मत करो 3.03%

क्या आपको लगता है कि यह निर्णय सही ढंग से लिया गया था?
हां, टीम ने बोर्ड पर फीडबैक लिया और दिशा बदल दी जब उन्हें 20.41% करना पड़ा
हाँ 6.12%
नहीं 24.49%
नहीं, टीम ने 39.80% समुदाय को शामिल किए बिना, गैर-जवाबदेह, बंद दरवाजे के निर्णय लिए
परवाह मत करो 9.18%

यह निर्णय .NET कोर के बारे में आपकी धारणा को कैसे प्रभावित करता है?
इसमें सुधार करता है, वे अंततः 13.00% विवेक के दौर में आ रहे हैं
इसमें सुधार करता है 11.00%
इसे खराब करता है 42.00%
इससे भी बदतर, मुझसे पूरी बात पर सवाल खड़ा करता है 18.00%
16% परवाह नहीं

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

वास्तव में, जैसा कि संकेत दिया गया है कि 100 लोग आपको 95% आत्मविश्वास के साथ त्रुटि का ± 10% मार्जिन देते हैं। यह देखने के लिए कि आप एक सच्चा प्रतिबिंब देख रहे हैं, आपको किस स्तर के आत्मविश्वास की आवश्यकता होगी? क्या हमें सभी 9 मिलियन डेवलपर्स का सर्वेक्षण करना चाहिए?

क्या UserVoice पर प्रोजेक्ट.json को शेष VS तक विस्तारित करने के लिए 800 वोट भी प्रवृत्ति नहीं दिखाते हैं?

और अगर हम वास्तव में प्रतिनिधि नमूना करने जा रहे हैं, तो शायद माइक्रोसॉफ्ट को ऐसा करना चाहिए। चूंकि उन्होंने कई दिशाओं से बार-बार शिकायत करने के बाद भी इस निर्णय के बारे में एक बार भी इनपुट

निजी सर्वेक्षण करने की तुलना में उनकी पहुंच मुझसे कहीं बेहतर होगी। मुझे अपनी कीमत पर 100 से अधिक परिणामों तक पहुंचने के लिए अपनी सर्वेमोनकी योजना को अपग्रेड करना होगा, ताकि मैं एक सर्वेक्षण चला सकूं जो माइक्रोसॉफ्ट को स्वयं

ठीक है यदि आप सार्थक संख्याएँ प्राप्त करना चाहते हैं तो आप 9 मिलियन डेवलपर्स के उचित प्रतिनिधित्व का लक्ष्य रखना चाहते हैं। अगर मेरे पास 100 ट्विटर फॉलोअर्स हैं, जो मुझे फॉलो करते हैं क्योंकि हम समान रुचि साझा करते हैं और मैं सभी से सर्वेक्षण करने के लिए कहता हूं तो आपके पास 100 लोग एकतरफा दृष्टिकोण वाले डेवलपर्स के केवल एक विशेष समूह का प्रतिनिधित्व करते हैं।

MSBUILD को पुनर्जीवित करने के लिए स्टैंडअप में दिया गया औचित्य मौजूदा उपकरणों के बीच एकीकरण को संभव बनाना और मौजूदा परियोजनाओं के लिए .NET कोर का उपयोग करना आसान बनाना था। हालांकि, एक बड़े प्रोजेक्ट को .NET कोर में माइग्रेट करने के बाद, ईमानदारी से कहूं तो प्रोजेक्ट सिस्टम मेरी चुनौतियों में सबसे कम था। इसलिए इसे एकमात्र औचित्य के रूप में उपयोग करना मेरे लिए एक बड़ा कारण नहीं लगता है। मैंने मैन्युअल रूप से फ़ाइलों को संपादित करने सहित csproj सिस्टम के साथ वर्षों तक काम किया है। वह हमेशा दर्दनाक था। Project.json आधारित प्रणाली बहुत आसान है और सभी (नौसिखियों सहित) द्वारा अधिक पहुंच योग्य है। मुझे लगता है कि यह लक्ष्य होगा। और फिर भी अब हम MSBUILD को पुनर्जीवित करके एक कदम पीछे ले जा रहे हैं। मेरी निजी राय है कि यह बहुत बड़ी भूल है। मैंने project.json रखने के लिए अपना वोट डाला।

वास्तव में मेरे लगभग कोई ट्विटर अनुयायी नहीं हैं, वे बड़े पैमाने पर .NET कोर देवों के अनुयायी हैं जिनके ट्विटर स्ट्रीम पर मैंने पोस्ट किया है।

और फिर, निश्चित रूप से ऐसा सर्वेक्षण करने वाले सही लोग Microsoft होंगे? यह मेरे लिए क्यों बचा है कि मैं वास्तव में लोगों से पूछ रहा हूं कि वे क्या चाहते हैं?

एमएस लोग क्या सोचते हैं, इस पर ध्यान क्यों नहीं देते?

टीबीएच मुझे नहीं पता था कि 30 मिनट पहले तक एक सर्वेक्षण हुआ था और मुझे नहीं पता था कि आप निजी तौर पर सर्वेक्षण कर रहे हैं। मैं सहमत हूँ... यदि Microsoft को इस परिवर्तन के प्रति डेवलपर की प्रतिक्रिया में रुचि है तो उन्हें ऐसा सर्वेक्षण चलाना चाहिए। लेकिन हो सकता है कि उन्होंने पहले ही अपना होमवर्क कर लिया हो और इसलिए वे यह बदलाव कर रहे हैं। मुझे नहीं पता, लेकिन मैं हमेशा चीजों को इतना नकारात्मक नहीं देखूंगा, क्योंकि आखिरकार ये लोग हमारे लिए यह सामान बना रहे हैं, इसलिए मुझे यकीन है कि उनके पास केवल हमारे लिए सबसे अच्छा हित है।

अगर उन्होंने अपना होमवर्क किया होता तो उन्हें पता होता कि 60% देव इस कदम के खिलाफ थे, और उसी के अनुसार संवाद और जुड़ाव करते। उन्होंने ऐसा नहीं किया, जिसका अर्थ है कि उन्हें प्रतिक्रिया का कोई पता नहीं था, जिसका अर्थ है कि उन्होंने सगाई नहीं की।

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

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

मैंने जो सुना है, उससे ऐसा लगता है कि उन्होंने उपकरण निर्माताओं की मदद करने के लिए उपयोगकर्ताओं को बस के नीचे फेंक दिया है। यदि हां, तो क्या वे उपकरण निर्माताओं से मेरी वीएस लाइसेंस फीस जमा कर सकते हैं, मुझसे नहीं।

@shederman जबकि मैं आपके सर्वेक्षण के परिणामों से सहमत हूं, इसके प्रश्न स्पष्ट रूप से w/json प्रारूप में रहने की पसंदीदा दिशा में

मैं आपसे सहमत हूं कि यह एक आदर्श सर्वेक्षण नहीं है। मैंने इसे 5 मिनट के अंतराल में बनाया है। मुद्दा यह है: मैं इसे क्यों बना रहा हूं?

Microsoft यह जानने में दिलचस्पी क्यों नहीं रखता कि लोग क्या सोचते हैं?

मुझे केवल 30 प्रतिक्रियाओं की उम्मीद थी, और मुझे आशा थी कि यह उन्हें चर्चा को फिर से खोलने, अपनी सोच को खुले तौर पर साझा करने और राय पर किसी तरह की सवारी करने के बजाय हमारे साथ ठीक से जुड़ने के लिए मनाने के लिए पर्याप्त होगा।

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

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

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

मैं Microsoft से क्षमा याचना करने वाले और सहानुभूति रखने वाले (एमवीपी या समुदाय के सदस्य) से अनुरोध करता हूं कि कृपया इस समय यथार्थवादी बनें।

@शेडरमैन

अगर उन्होंने अपना होमवर्क किया होता तो उन्हें पता होता कि 60% देव इस कदम के खिलाफ थे,

यह मुझे आश्चर्यचकित करेगा यदि .net पारिस्थितिकी तंत्र में 20% से अधिक देवों को भी project.json के अस्तित्व के बारे में पता है। हम कभी-कभी भूल जाते हैं कि हम नए तकनीकी विकास के मामले में सबसे आगे चलकर एक डेवलपर बुलबुले में रहते हैं।

मेरा मानना ​​है कि project.json की अधिकांश अपील इसकी सादगी है। हालाँकि, यदि आप 3 साल पहले ASP नेट इनसाइडर्स डे पर पहली बार पेश किए जाने के बाद से इसके विकास का अनुसरण कर रहे हैं, तो यह अधिक जटिलता जमा करना शुरू कर देता है क्योंकि यह अधिक उपयोग-मामलों का समर्थन करने का प्रयास करता है। पूरे .net ईको-सिस्टम का समर्थन करने के लिए मुझे डर है कि बहुत सी प्यारी सादगी खो जाएगी।

यह कहना नहीं है कि project.json कुछ भयानक नई सुविधाएँ नहीं लाता है, और मेरा मानना ​​है कि प्रोजेक्ट प्रारूप को अधिक मानवीय बनाना एक अच्छी बात है। हालांकि, मुझे लगता है कि MSBuild के लिए उस अच्छाई को लाना अधिक प्राप्त करने योग्य है और हर जगह project.json लाने की कोशिश करने की तुलना में कहीं अधिक लोगों को लाभ होगा।

यह मुझे आश्चर्यचकित करेगा यदि .net पारिस्थितिकी तंत्र में 20% से अधिक देवों को भी project.json के अस्तित्व के बारे में पता है।

मैं शर्त लगाता हूं कि .net ईको में 20% से कम देव एमवीसी और वेब एपी के बारे में जानते हैं। 70 से अधिक लोग WebForms, WCF, WebService का उपयोग कर रहे हैं। फिर से मैं माइक्रोसॉफ्ट के क्षमाप्रार्थी से अनुरोध करता हूं और सहानुभूतिपूर्ण कृपया यथार्थवादी बनें

@shederman आपके सर्वेक्षण के परिणामों से किसी भी विश्वास की आपकी रिपोर्ट शायद बड़े पैमाने पर .NET डेवलपर्स की आबादी के लिए गलत है, और यह एक अच्छा प्रतिनिधि नमूना भी नहीं हो सकता है ... "वे बड़े पैमाने पर .NET कोर देवों के अनुयायी हैं जिनके ट्विटर स्ट्रीम पर मैंने पोस्ट किया है।" आपका नमूना एक यादृच्छिक नमूना नहीं है , जो आपके लिए किसी भी तरह के विश्वास अंतराल को बताने के लिए बिल्कुल आवश्यक है जैसा कि आप समग्र रूप से जनसंख्या के लिए करते हैं। भले ही यह .NET डेवलपर्स का एक यादृच्छिक नमूना था, आप प्रत्येक उत्तर में 95% विश्वास की रिपोर्ट नहीं कर सकते क्योंकि आप एक साथ अनुमान के लिए समायोजन करने में विफल रहे।

समग्र रूप से जनसंख्या के लिए आपके सर्वेक्षण के आधार पर कोई उपयोगी सांख्यिकीय निष्कर्ष नहीं निकाला जा सकता है। हालांकि, मुझे खुशी है कि आपने सर्वेक्षण किया। आपने कई बेहतरीन बिंदु प्रस्तुत किए हैं। मुझे लगता है कि परिणाम यह संकेत देते हैं कि बहुत से लोग या तो परेशान हैं या बदलाव को लेकर चिंतित हैं। हालांकि, कृपया झूठे सांख्यिकीय निष्कर्ष प्रकाशित न करें ... संख्याओं को पास करना जो वस्तुतः अर्थहीन हैं और इस तरह की अपमानजनक टिप्पणी कर रहे हैं जैसे "उन्हें पता होगा कि 60% देव इस कदम के खिलाफ थे।"

तो फिर कुछ भी बदलने का क्या मतलब है अगर हम बाजार आधार के 70%+ को परेशान करने जा रहे हैं? आइए ठीक वहीं रहें जहां हम हैं और वृद्धिशील विकास करते रहते हैं। अगर यह टूटा नहीं है तो इसे ठीक मत करो, है ना?

मुझे पता है कि project.json ने जटिलता जमा कर ली है। मैं उस बिंदु पर 100% सहमत हूं। क्या csproj में वापस विलय करने का समाधान था? मैंने पहले लोगों से कहा था, मैं जल्दी में शिपिंग के बजाय चीजों को सही करने के लिए माइक्रोसॉफ्ट से पूरी तरह पीछे हूं। csproj की ओर बढ़ना जल्दबाजी दिखाई देता है।

RC2 के बाद ऐसा क्यों करें? यह कहां से आया है? क्या ज़ामरीन के अधिग्रहण का इससे कोई लेना-देना था? क्या यह dotnet-cli एकीकरण था? क्या यह एक बड़ा ग्राहक था? कौन जाने...

मैं जनता को समझा सकता था कि RC1 -> RC2 सर्वश्रेष्ठ के लिए था। डॉटनेट क्ली के साथ एकीकृत। लेकिन प्रोजेक्ट.जेसन बदल जाता है? मुझे इसे समझाने के लिए कुछ नहीं कहना है। बस इतना ही मुझे नहीं पता। लोग भ्रमित हैं और मेरे पास उनके लिए कोई जबरदस्त तर्क नहीं है।

RC2 के बाद ऐसा क्यों करें? यह कहां से आया है? क्या ज़ामरीन के अधिग्रहण का इससे कोई लेना-देना था? क्या यह डॉटनेट-क्ली एकीकरण था? क्या यह एक बड़ा ग्राहक था? कौन जाने...

यही बिंदु विचार है। हम csproj पर जाने के पीछे की पूरी कहानी नहीं जानते हैं। अब पीछे झुककर आराम करने और देखने और समझने की बजाय कि ऐसा क्यों हो रहा है, हर कोई माइक्रोसॉफ्ट को कोस रहा है और बुरा मान रहा है। इसका कोई मतलब नहीं है। ये लोग इस सामान को हमारे और हमारे लिए ही बना रहे हैं। वे निश्चित रूप से 1 बड़े ग्राहक के कारण इस तरह के बदलाव नहीं करते हैं, क्योंकि यदि आप अपने पूरे समुदाय को खोने का जोखिम उठाते हैं तो 1 बड़ा ग्राहक बेकार है। Microsoft .NET इको सिस्टम HUUUUUUGE है और इसमें .NET Core को अच्छी तरह से फिट करना स्पष्ट रूप से एक जटिल काम है, इसलिए मैं सुझाव दूंगा कि हर कोई थोड़ा शांत हो जाए और मान लें कि इन लोगों के पीछे कुछ चतुर लोग हैं, जो सही निर्णय ले रहे हैं ताकि हम इसका सबसे अधिक लाभ उठा सकते हैं - दीर्घकालिक। मैं यहां से बाहर हूं, क्योंकि यह सभी नकारात्मक समयपूर्व अटकलें मुझे बोर कर रही हैं।

@darrelmiller क्षमा करें, जब मैं 60% कहता हूं, तो मेरा मतलब उन 60% लोगों से है जिन्होंने सर्वेक्षण का जवाब दिया।

@GuardRex आप बिल्कुल सही कह रहे हैं। एकमात्र संगठन जो हमें उचित परिणाम दे सकता है वह है एमएस, और वे परवाह नहीं करते हैं।

मेरा सर्वेक्षण केवल समर्थन के अस्पष्ट स्तर का आकलन करने के लिए था, न कि सांख्यिकीय रूप से महत्वपूर्ण नमूना प्रदान करने के लिए। मेरा मानना ​​​​है कि मैंने दिखाया है कि इस निर्णय को खोलने के लिए पर्याप्त नाखुशी है, लेकिन ऐसा लगता है कि माइक्रोसॉफ्ट सहमत नहीं है, ठीक है अगर उनकी रेडियो चुप्पी कोई संकेत है।

यहां प्रश्न है: एमएस को यह स्वीकार करने के लिए वास्तव में क्या आवश्यक होगा कि उन्होंने शायद गलती की है? चर्चा को फिर से शुरू करने के लिए उन्हें क्या करना होगा? क्योंकि इस समय ऐसा लगता है कि उत्तर "हमें आपकी बात की परवाह नहीं है, हमारा निर्णय खड़ा है, और हम कारणों को साझा नहीं करने जा रहे हैं"

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

मैंने जो कहा वह इसे करीबी स्रोत बनाता है क्योंकि इसके पीछे चतुर लोग हैं और वे हमेशा सही होते हैं और खुला स्रोत समुदाय मूर्ख होता है।

@shederman "सांख्यिकीय रूप से महत्वपूर्ण नमूना प्रदान नहीं करना" ... यह ठीक है, लेकिन मेरी इच्छा है कि आप सर्वेक्षण को अपनी योग्यता पर खड़े होने दें और इस लाइन को हटा दें ...

अंतिम सर्वेक्षण परिणाम: 9 मिलियन .NET डेवलपर आबादी के लिए 100 प्रतिक्रियाएं, जो 95% विश्वास के साथ ± 10% है।

यही वह हिस्सा है जो वास्तव में पासा हो जाता है। यह सही हो सकता है कि 60% .NET डेवलपर इस परिवर्तन से घृणा या नापसंद करते हैं; हालांकि, आप इसे उस नमूने के साथ नहीं दिखा सकते हैं। मान लीजिए, हाँ, बहुत से देवों को परिवर्तन और इसे संभालने के तरीके के बारे में एक बड़ी चिंता है। यह स्पष्ट है, और सर्वेक्षण वास्तव में उस बिंदु को अच्छी तरह से उजागर करता है।

@abcplex : ओपन सोर्स का मतलब यह नहीं है कि आपको हर बार 16 लोगों को

@MaximRouller स्टैंडअप नोट्स परिवर्तनों के लिए प्रेरणा को समझाने का एक बहुत अच्छा काम करते हैं। और वास्तविकता, जैसा कि मैंने इसे पढ़ा है, यह है कि xproj को csproj द्वारा प्रतिस्थापित किया जा रहा है और project.json का नाम बदलकर nuget.json होने की संभावना है और _some_ सामान को project.json से बाहर ले जाया जाएगा।

और स्टैंडअप में की गई टिप्पणियों से, यह एक बहुत ही हालिया निर्णय था, समुदाय को लगभग तुरंत ही बता दिया गया है, RTM के बाद तक project.json कहीं नहीं जा रहा है, इसलिए परिवर्तन फिर से हो सकते हैं।

मेरे लिए, यह सबसे समावेशी और पारदर्शी प्रक्रिया की तरह लगता है जो संभवतः हो सकता था।

@darrelmiller कि, मुझे आपसे सहमत होना होगा। काफी पारदर्शी।

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

अब यह तो वक्त ही बताएगा।

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

यह किसी और की तुलना में जल्दी अपनाने वालों को अधिक प्रभावित करता है।

JSON अच्छा पढ़ता है, लेकिन केवल तभी जब यह सरल हो। मेरी राय में </system> की तुलना में ]} को समझना आसान है।

यहां पर सबसे उचित टिप्पणियां परियोजनाओं की अनलोडिंग/लोडिंग और निर्भरता प्रबंधन के बारे में मेरे अपने विचारों को प्रतिबिंबित करती हैं जिन्हें एक्सएमएल में निहित वर्बोसिटी की आवश्यकता नहीं है।

क्या यह वास्तव में JSON बनाम XML के बारे में चर्चा होनी चाहिए? वास्तव में कोई फर्क नहीं पड़ता IMHO
(निश्चित रूप से, व्यक्तिगत रूप से मुझे XML से अधिक JSON पसंद है लेकिन यह महत्वपूर्ण नहीं है)

ASP.NET Core के बारे में जो मुझे वास्तव में पसंद है, वह यह है कि यह विजुअल स्टूडियो और किसी भी अन्य IDE से काफी खुला और स्वतंत्र है। यदि यह अभी भी दिया गया है, तो मुझे इस निर्णय से कोई समस्या नहीं है।

इस मुद्दे पर काफी जहरीली चर्चा चल रही है, जो मुझे लगता है कि बहुत से लोगों की दृष्टि खो रही है। ऐसा लगता है कि सामान्य तर्क "एमएसबिल्ड खराब है!" लेकिन दोनों दृष्टिकोणों के बारे में क्या अच्छा/बुरा है, इसकी पर्याप्त समझ नहीं बनाई जा रही है।

हर किसी के लिए यह कहते हुए कि यह एक "कदम पीछे की ओर" है, इस बात से अवगत रहें कि यद्यपि यह "csproj" पर वापस जा रहा है, यह _same_ नहीं होगा जैसा कि csproj फ़ाइलें हमारे पास वर्षों से हैं। एक के लिए, उन्होंने स्पष्ट रूप से कहा है कि आपको "नए" csproj प्रारूप में

तुरंत यह एक तत्काल अंतर है। आज ही xproj पर एक नज़र डालें और आपको बहुत कुछ इस बात का अंदाजा हो जाएगा कि "नए" csproj से क्या उम्मीद की जाए। यह थोड़ा बड़ा होगा, लेकिन केवल इसलिए कि इसमें project.json से कुछ अतिरिक्त गुण लेने जा रहे हैं। वास्तविक चर्चा "एमएसबिल्ड कितना खराब है" के बारे में नहीं है और नहीं होनी चाहिए, लेकिन आप नए csproj में क्या देखना चाहते हैं और आप .json फ़ाइल में क्या छोड़ना चाहते हैं।

@dustinmoris आप अनुचित हैं, मुझे लगता है कि समुदाय ने अधिकांश परिवर्तनों का स्वागत किया लेकिन यह एक। यह हमें पीछे ले जा रहा है, और वे पहले से ही इस बारे में बात कर रहे हैं कि वे इसे कैसे करेंगे, बिना किसी अंतर्दृष्टि के क्यों। वे यह ध्वनि करते हैं कि निर्णय अंतिम है, इसलिए समुदाय के लिए बेहतर प्रस्ताव के साथ आने के लिए कोई जगह नहीं है।

और हाँ हम सीधे प्रोजेक्ट फाइलों को संपादित करते हैं और हम इसे प्रोजेक्ट.जेसन से पहले दर्दनाक तरीके से कर रहे थे। Msbuild सभी आदिवासी ज्ञान के बारे में है और इसमें महारत हासिल करना थोड़ा कठिन है।

और "यह .net 4.5 से .net कोर में माइग्रेशन को आसान करेगा" थोड़ा बेईमान लगता है। यह निश्चित रूप से दर्द बिंदु नहीं है ...

यह उन csproj फ़ाइलों के समान नहीं होगा जो हमारे पास वर्षों से हैं।

क्या यह एक्सएमएल होगा? हां मेरी भी यही सोच थी।

मुख्य लाभ और मुख्य कारण ज्यादातर लोगों ने प्रोजेक्ट को पसंद किया है। फाइलों की यह सूची नहीं होने के कारण जेसन प्रारूप नीचे है।

आप यह किस जानकारी के आधार पर कहते हैं? मेरा मतलब है, फाइलों की सूची नहीं होना प्रमुख प्लस है, लेकिन किसी भी तरह से मेरे लिए केवल एक ही नहीं है।

आज ही xproj पर एक नज़र डालें और आपको बहुत कुछ इस बात का अंदाजा हो जाएगा कि "नए" csproj से क्या उम्मीद की जाए।

मेरे पास आज xproj नहीं है। मुझे ऐसी चीज़ की आवश्यकता क्यों होगी?

वास्तविक चर्चा "एमएसबिल्ड कितना खराब है" के बारे में नहीं है और नहीं होनी चाहिए

यह चर्चा क्यों _नहीं होनी चाहिए? .NET कोर को अपनाने के लिए टर्फिंग MSBuild एक प्रमुख प्लस पॉइंट था। मेरे (जाहिरा तौर पर) अवैज्ञानिक, इको चैंबर, पक्षपाती सर्वेक्षण पर उत्तरदाताओं में से 20% सहमत हैं कि यह मौलिक रूप से टूटा हुआ है।

@shederman आपकी प्रतिक्रिया ठीक उसी तरह की जहरीली चर्चा है जिसका मैं जिक्र कर रहा हूं। आप केवल सामान्य दावे कर रहे हैं (जैसे "एमएसबिल्ड खराब है!") लेकिन आप किसी भी प्रकार की रचनात्मक चर्चा के साथ उनका समर्थन नहीं कर रहे हैं।

क्या यह एक्सएमएल होगा? हां मेरी भी यही सोच थी।

हां। और? यदि आपकी समस्या यह है कि आपको _XML_ पसंद नहीं है, तो काफ़ी है। अगर आपको लगता है कि JSON XML से बेहतर है, तो आगे बढ़ें और अपने कारणों को फिर से बताएं, लेकिन इसका _प्रोजेक्ट स्ट्रक्चर_ और सिंटैक्स के साथ करने वाली हर चीज़ से कोई लेना-देना नहीं है। दुर्भाग्य से आपके लिए, एक्सएमएल और जेएसओएन दोनों का दुनिया में अपना स्थान है, दोनों के लिए अलग-अलग पक्ष और विपक्ष हैं और कभी भी एक निश्चित "सही" उत्तर नहीं होगा जो बेहतर है। फिर, अगर मैं तुम होते तो मैं इस बात पर ध्यान केंद्रित करता कि इस कदम के साथ _project structure_ में क्या अंतर होगा।

आप यह किस जानकारी के आधार पर कहते हैं? मेरा मतलब है, फाइलों की सूची नहीं होना प्रमुख प्लस है, लेकिन किसी भी तरह से मेरे लिए केवल एक ही नहीं है।

मैंने कभी दावा नहीं किया कि यह एकमात्र लाभ था, मैंने बस इतना कहा कि यह _main_ लाभ था। प्रोजेक्ट.जेसन प्रारूप के बारे में महीनों पहले होने वाली किसी भी चर्चा को देखें और सबसे पहली बात यह है कि लोग बात करते हैं कि यह कितना छोटा और सरल है। ऐसा इसलिए नहीं है क्योंकि JSON वाक्य रचनात्मक रूप से क्लीनर है, यह प्रोजेक्ट फ़ाइलों की सूची को हटाने के लिए नीचे है। लोगों का सबसे बड़ा प्लस यह है कि यह अच्छी तरह से विलीन हो जाता है और यह अच्छी तरह से विलीन हो जाता है क्योंकि इसमें फ़ाइल संदर्भों का एक समूह सूचीबद्ध नहीं होता है।

मेरे पास आज xproj नहीं है। मुझे ऐसी चीज़ की आवश्यकता क्यों होगी?

यह पूरी चर्चा नए प्रोजेक्ट फ़ाइल स्वरूप के बारे में है, यदि आप वर्तमान परिदृश्य की तुलना करने के लिए तैयार नहीं हैं तो आपकी राय बेख़बर होगी।

यह चर्चा क्यों नहीं होनी चाहिए? .NET कोर को अपनाने के लिए टर्फिंग MSBuild एक प्रमुख प्लस पॉइंट था। मेरे (जाहिरा तौर पर) अवैज्ञानिक, इको चैंबर, पक्षपाती सर्वेक्षण पर उत्तरदाताओं में से 20% सहमत हैं कि यह मौलिक रूप से टूटा हुआ है।

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

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

@neoKushan आपको बिना किसी अच्छे कारण के उनका बचाव करके जल्द ही Microsoft से किसी प्रकार का पुरस्कार प्राप्त करना चाहिए। वास्तविक बिंदु पर आएं कि यह पिछले दरवाजे में किया गया सबसे खराब निर्णय है। मैं एएसपी नेट को फिर से बंद स्रोत बनाने की सलाह देता हूं और माइक्रोसॉफ्ट और उनके समर्थकों को यह तय करने की अनुमति देता हूं कि ओपन सोर्स समुदाय के सदस्यों से पूछे बिना क्या करना चाहते हैं

@abcplex क्या आप नेम-कॉलिंग और फिंगर-पॉइंटिंग के अलावा बातचीत में कुछ भी योगदान देने जा रहे हैं?

अब तक आपने कुछ भी नहीं किया है, केवल एक कारण बताए बिना परिवर्तन के बारे में शिकायत की है कि इसके साथ आपकी वास्तविक समस्या क्या है।

@neoKushan सबसे बड़ी बात यह है कि यह इस तरह के बदलाव का समय नहीं है, सिर्फ एक महीने पहले RTM का। इस समय यह बदलाव करने का कोई मतलब नहीं है।

@abcplex आरटीएम में परिवर्तन नहीं हो रहा है। यह एक क्रमिक, पोस्ट-आरटीएम परिवर्तन होने जा रहा है। RTM में जो कुछ भी होता है, वह यह है कि आपके xproj का नाम बदलकर csproj कर दिया जाता है - शाब्दिक रूप से और कुछ भी नहीं बदलता है और चरणों में परिवर्तन किए जाएंगे, आपके लिए आपके परिवर्तन माइग्रेट करने वाले टूल के साथ।

सहमत हैं कि जेएसओएन बनाम एक्सएमएल (बनाम एक्सएएमएल, स्टैंडअप ब्लॉग पोस्ट पर कुछ लोग इसके लिए पूछ रहे हैं) पिछले टूलींग के साथ किसी भी प्रकार की पिछड़ा संगतता होने के गुणों से एक व्याकुलता है।

और मैं तर्क दूंगा कि यह सोचने का एक बेहद गुमराह करने वाला तरीका है। यह पसंद है या नहीं, csproj और MSBuild चींटी की परंपरा का पालन करते हैं, जो टूलचेन को निर्देश देने के बारे में है कि इसे कैसे परिभाषित किया जाए, बजाय इसे परिभाषित करने के। ये बहुत अलग चीजें हैं, लेकिन ऐसा लगता है कि यह विरासत परियोजना को "परिभाषा" शक्ति देती है, क्योंकि अब हम इसमें तर्क लागू कर सकते हैं, और इसी तरह। वह जो करता है वह चीजों को अविश्वसनीय रूप से जटिल बना देता है।

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

एक प्रोजेक्ट फ़ाइल में कई गुण होने चाहिए जो इसे टूलचेन के आकार के लिए अज्ञेय बनाते हैं जो कि दी गई दुकान का उपयोग करने का निर्णय लेती है:

• यह मानव संपादन योग्य/पठनीय होना चाहिए
• इसे टिप्पणियों की अनुमति देनी चाहिए
• यह घोषणात्मक होना चाहिए
• यह स्वयं निहित होना चाहिए
• इसे मर्ज संघर्षों को कम करने/विलय को सरल बनाने के लिए, यदि संभव हो तो डिजाइन किया जाना चाहिए
• यह पूरी तरह से दस्तावेज योग्य होना चाहिए (दस्तावेजीकरण पर लागू होने वाले स्व-रोकथाम सिद्धांत के साथ)
• यह उपकरण-स्वतंत्र होना चाहिए

और "यह .net 4.5 से .net कोर में माइग्रेशन को आसान करेगा" थोड़ा बेईमान लगता है। यह निश्चित रूप से दर्द बिंदु नहीं है ...

100% सहमत। मुझे स्पष्ट करना चाहिए कि हमारे लिए क्या चुनौतियाँ रही हैं: कोडबेस को माइग्रेट करने में अब तक की एकमात्र कठिनाइयाँ कुछ .NET क्लास लाइब्रेरीज़ (सिस्टम। ड्रॉइंग को देखते हुए), .NET कोर का समर्थन करने में Microsoft टीमों की ओर से मितव्ययिता है। (आपको DocumentDB देखकर) और मानक ब्रेकिंग परिवर्तन जो प्रमुख संस्करणों के बीच अपेक्षित हो सकते हैं।

किसी भी समय project.json कोई समस्या नहीं थी। वास्तव में, वह लाभ का था। डिट्टो MSBuild को एक अदृश्य विवरण में डंप करने में सक्षम है जो जादुई रूप से तब होता है जब Ctrl + Shift + B।

@neoKushan

1. मुझे एक्सएमएल पसंद नहीं है। यह प्रोजेक्ट और कॉन्फ़िगरेशन फ़ाइलों के लिए एक खराब प्रारूप है। यह एक बुरा विचार था जब इसे "एक्सएमएल फॉर एवरीथिंग" चरण के दौरान पेश किया गया था, और अब यह एक बुरा विचार है।
2. मुझे लगता है कि जेएसओएन फाइलें एक्सएमएल फाइलों की तुलना में काफी बेहतर विलय करती हैं। मैं स्वीकार करता हूं कि यह एक राय है, लेकिन यह मेरी है, और मेरे अनुभवों पर आधारित है।
3. मैं vscode का उपयोग कर रहा हूं जिसकी आवश्यकता नहीं है और xproj फ़ाइलों का उपयोग नहीं करता है। _that_ मेरा वर्तमान परिदृश्य है, और मुझे ऐसी xproj फ़ाइल नहीं चाहिए या इसकी आवश्यकता नहीं है जिसका मेरे लिए कोई अर्थ नहीं है।
4. नहीं, मैं एमएसबिल्ड पर चर्चा कर रहा हूं। मैंने एमएसबिल्ड और टीम बिल्ड के साथ बहुत सी चीजें की हैं। वे कभी मज़ेदार कभी भी आसान
5. MSBuild सरल कार्यों को भी कठिन बना देता है। मेरा सुझाव है कि आप विकल्पों को देखें, और एमएसबिल्ड द्वारा ब्लिंकर न करें। विशेष रूप से देखें कि गल्प और एसबीटी कैसे काम करते हैं।

@शेडरमैन

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

इनमें से कोई भी नहीं बताता है _why_ यह एक बुरा विचार है।

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

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

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

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

उदाहरण के लिए, एक बात जो अभी भी तय नहीं है, वह यह है कि अगर nuget निर्भरताएँ csproj का हिस्सा बन जाएँगी, या यदि वह nuget.json बन जाएगी - वहाँ आपकी प्राथमिकता है। एक बार जब आपके पास .json फ़ाइल में निर्भरताओं की सूचियां हों, तो csproj में जाने के लिए क्या बचा है? वह कितनी बार बदलेगा? _that_ का विलय करना कितना कठिन होगा?

मैं व्यक्तिगत रूप से यह चाहूंगा कि यह सब एक ही परियोजना फ़ाइल में समाहित हो, लेकिन मैं नगेट को परियोजना से अलग करने की अपील और लाभ देख सकता हूं। दोनों के पक्ष और विपक्ष हैं और शायद सबसे अच्छा समाधान दोनों के लिए अनुमति देना है, निर्भरता की सूची के साथ एक csproj है, लेकिन आपको अपनी निर्भरताओं के साथ .json फ़ाइल को इंगित करने देता है। MSbuild के लिए कुछ अतिरिक्त जटिलता की कीमत पर, दोनों दुनिया के सर्वश्रेष्ठ और हर कोई जीतता है।

नहीं, मैं एमएसबिल्ड पर चर्चा कर रहा हूं। मैंने एमएसबिल्ड और टीम बिल्ड के साथ बहुत सी चीजें की हैं। वे कभी मज़ेदार नहीं रहे, और कभी भी आसान नहीं रहे, और हमेशा कीचड़ में सुअर के साथ कुश्ती में शामिल रहे हैं। मुझे एमएसबिल्ड से नफरत है, और मैं निश्चित रूप से अकेला नहीं हूं।

टीएफएस की एक्सएएमएल आधारित बिल्ड परिभाषाओं से निपटने के बाद, मैं कम से कम आपके साथ (कुछ) इस पर सहमत हो सकता हूं।

MSBuild सरल कार्यों को भी कठिन बना देता है। मेरा सुझाव है कि आप विकल्पों को देखें, और एमएसबिल्ड द्वारा ब्लिंकर न करें। विशेष रूप से देखें कि गल्प और एसबीटी कैसे काम करते हैं।

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

एक ऐसे भविष्य की कल्पना करें जहां आपको एक्सएमएल आधारित प्रोजेक्ट फाइल से निपटना पड़े

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

कैसा रहेगा:

var gulp = require('gulp')
, minifyCss = require("gulp-minify-css");

gulp.task('minify-css', function () {
    gulp.src('./Css/one.css') // path to your file
    .pipe(minifyCss())
    .pipe(gulp.dest('path/to/destination'));
});

या हो सकता है

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

libraryDependencies ++= Seq(
  "org.scalatra" %% "scalatra" % "2.0.4",
  "org.scalatra" %% "scalatra-scalate" % "2.0.4",
  "org.scalatra" %% "scalatra-specs2" % "2.0.4" % "test",
  "ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
  "org.eclipse.jetty" % "jetty-webapp" % "7.6.0.v20120127" % "container",
  "javax.servlet" % "servlet-api" % "2.5" % "provided",
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1"
)

resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"

अरे हाँ, जिस xproj से आपने लिंक किया है वह बहुत बेहतर है। अच्छा और स्पष्ट और संक्षिप्त। और अभिव्यंजक, अभिव्यंजक मत भूलना। वह प्रोजेक्टगाइड किस लिए है? और मुझे टूल संस्करण सेट करने के लिए 90 वर्ण पसंद हैं। और DnxInvisibleContent? मेरे निर्माण प्रणाली के लिए यह जानना उपयोगी है? मेरे द्वारा नहीं चलाए जा रहे IDE में कौन-सी फ़ाइलें नहीं दिखानी हैं?

मेरा सुझाव है कि आप अपने खिलौनों को प्राम से बाहर फेंकना बंद कर दें

नहीं चाहता :-)

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

[पेटुलेंस को दूर करने के लिए संपादित]

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

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

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

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

हाँ, MSBuilds सबसे बड़ा मुद्दा यह है कि यह सब एक सिस्टम में करने की कोशिश करता है।

मुझे लगता है कि जो मुझे समझ में नहीं आ रहा है वह यह है: मुझे कुछ ऐसे उपयोग के मामले दिखाएं जो प्रोजेक्ट सिस्टम के रूप में एमएसबिल्ड का उपयोग करके बेहतर किए गए हैं, केवल प्रोजेक्ट बनाने के विरोध में। जेसन काम। मैं इसे नहीं देखता। हो सकता है कि मेरे उपयोग के मामले बहुत सरल हों, इसलिए मुझे कुछ दिखाएँ।

@shederman स्टैंडअप नोट्स में परियोजनाओं में स्रोत फ़ाइलों को साझा करने में सक्षम होने का उल्लेख है

तो ... यह एक ओपन सोर्स प्रोजेक्ट है, और मुझे पता है कि माइक्रोसॉफ्ट "शक्तियां हैं" लेकिन अगर यह लोगों के लिए इतना महत्वपूर्ण है, तो - और मुझे लगता है कि मैं यहां एक अज्ञानी प्रश्न पूछ रहा हूं - कितना समय .NET कोर को MSBuild के विकल्प के रूप में project.json का उपयोग जारी रखने की अनुमति देने के लिए / प्रयास/ऊर्जा खर्च करने की आवश्यकता होगी? यदि पर्याप्त लोग योगदान करते हैं, और कोड काफी अच्छा है, तो एमएस इसे इस परियोजना में क्यों स्वीकार नहीं करेगा? ओपन सोर्स की सुंदरता (और पतन) का एक हिस्सा कोड को फोर्क करने का खतरा है यदि प्राथमिक अनुरक्षक दूसरों द्वारा दी जाने वाली पेशकश से बहुत अधिक मना कर देता है। ओपन सोर्स कोड के बिंदु का एक हिस्सा सिर्फ देखने के लिए नहीं है, बल्कि संशोधित करने और सुधारने के लिए है।

परिवर्तन पर मेरा व्यक्तिगत विचार यह है कि इसका ज़ामरीन से कोई लेना-देना नहीं है, इसमें यह भविष्य की योजनाओं के बारे में है। साथ ही, हाल के स्टैंड-अप में मेरा मानना ​​है कि मैंने उन्हें यह कहते सुना है कि वे एक प्रथम श्रेणी के नागरिक होने के लिए कंसोल ऐप्स बनाना चाहते हैं। याद रखें कि मूल रूप से, नया .NET (ASP.NET 5 + DNX) वेब ऐप बनाने पर केंद्रित था, अब यह और अधिक है। यह सब अपेक्षाकृत हाल ही में हुआ है, .NET और ASP.NET टीमों का विलय हुआ है, और Xamarin की खरीद भी हुई है। वे इस निष्कर्ष पर पहुंचे कि उन्हें इन कई परिदृश्यों (और नए भविष्य के परिदृश्य जिनके बारे में मैं यहां अनुमान नहीं लगाऊंगा) का समर्थन करने के लिए एक बेहतर परियोजना प्रणाली की आवश्यकता है, और वे जल्द ही .NET कोर को भी शिप करना चाहते हैं। क्या करें? पूर्व-मौजूदा एमएसबिल्ड को पूरी तरह से अनदेखा करें जो पहले से ही आवश्यक चीज़ों को संभाल सकता है और खरोंच से शुरू कर सकता है? क्षमा करें, मुझे पता है कि मैं कौन सा रास्ता चुनूंगा।

चिंता का एक अच्छा सा विलय के आसपास लगता है लेकिन अगर परियोजना फ़ाइल में परियोजना में फाइलों के नाम शामिल नहीं हैं, और यदि निर्भरता को एक अलग कॉन्फ़िगरेशन फ़ाइल में धकेल दिया जाता है तो मर्ज समस्या गायब हो जानी चाहिए क्योंकि प्रोजेक्ट फाइलों को बदलना चाहिए अपेक्षाकृत कम ही।

एकदम मेरे विचार

मर्ज का मुद्दा केवल एक मुद्दा है। एमएसबिल्ड से दूर होना एक और है। इस परिदृश्य का एक पागल परिणाम यह है कि वे अब MSBuild को Linux और OSX में पोर्ट करने में समय और प्रयास खर्च करने जा रहे हैं! कल्पना करो कि।

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

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

तो, यह या तो हम प्रयास खर्च करते हैं और प्रोजेक्ट.जेसन बिल्ड सिस्टम को फोर्क करते हैं, या हम किसी अन्य बिल्ड सिस्टम (नकली?) पर स्विच करते हैं, या आप इसे चूसते हैं, या आप किसी अन्य प्लेटफॉर्म का उपयोग करते हैं। मेरा मानना ​​है कि मैंने वहां सभी विकल्पों की गणना कर ली है।

@shederman MSBuild 2015 की शुरुआत से खुला स्रोत रहा है, और बिल्ड OSX/Ubuntu पर गुजर रहे हैं, इसलिए मुझे नहीं लगता कि यह उतना काम है जितना आप पोर्ट के बारे में सोच सकते हैं (https://github.com/Microsoft/msbuild) , रेपो ब्राउज़ करने से ऐसा लगता है कि OSX उदाहरण के लिए मार्च में ओके बैक बना रहा था।

ओह प्रिय। मुझे इस बात की चिंता है कि क्या हमें ऐसा करना चाहिए, और उन्होंने जाकर इसे किया है...

कुछ ऐसा महसूस करें जैसे कोई फ्रेंकस्टीन मॉन्स्टर को दूर से दूर जाते हुए देख रहा हो। दिलचस्पी, उत्सुक, चिंतित, और थोड़ा घृणित :-)

@darrelmiller स्टैंडअप नोट्स में परियोजनाओं में स्रोत फ़ाइलों को साझा करने में सक्षम होने की आवश्यकता का उल्लेख है

सच में? लोग अभी भी ऐसा करते हैं? मेरा मतलब है कि मैं इसे AssemblyInfo.cs के लिए करता था, और अंधेरे युग में वापस, हम अपनी मजबूत नाम कुंजी को साझा स्रोत फ़ाइल में डाल देंगे।

ठीक है, यह एक उपयोग का मामला है, लेकिन अब मैं वास्तव में उपयोग के मामले के लिए उपयोग के मामले को सुनना चाहता हूं। जिज्ञासु।

@शेडरमैन

उम। ठीक है, तो मुझे एक ऐसे भविष्य की कल्पना करनी चाहिए जो मैं नहीं चाहता और आपको समझाता हूँ कि यह कैसे काम करेगा? उम, नहीं, मुझे ऐसा नहीं लगता

आपको बस इतना करना है JSON के बजाय एक्सएमएल स्वीकार करते हैं, यह देखने के लिए क्या लाभ हो सकता है, लेकिन आप क्योंकि सभी आप क्या करना चाहते कितना बुरा एक्सएमएल वास्तव में क्यों बताते हुए बिना है के बारे में बात यह है कि खेल खेलने के लिए तैयार नहीं कर रहे हैं।

ओह प्रिय। मुझे इस बात की चिंता है कि क्या हमें यह करना चाहिए, और उन्होंने जाकर इसे किया है...

वे सचमुच _years_ के लिए "जा रहे हैं और इसे कर रहे हैं"। उन्होंने वर्षों पहले ओपन-सोर्सिंग .net के बारे में बात की, उन्होंने रोडमैप दिया और यह स्पष्ट किया कि यह किसी भी प्लेटफॉर्म पर चलने के बारे में था, किसी भी उपयोग के मामले के लिए।

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

अरे हाँ, जिस xproj से आपने लिंक किया है वह बहुत बेहतर है। अच्छा और स्पष्ट और संक्षिप्त। और अभिव्यंजक, अभिव्यंजक मत भूलना।

कम से कम आपने अंत में इसे देखा है। इससे पहले कि आप भी परेशान हों, इस मुद्दे में 72 टिप्पणियों ने क्या लिया? मैं आपको यह बताता रहता हूं, लेकिन आपको यह नहीं मिल रहा है: एमएसबिल्ड कितना भयानक है, इसके बारे में शिकायत करने के बजाय, इस बारे में बात करें कि यह भयानक क्यों है ।

मर्ज का मुद्दा केवल एक मुद्दा है। एमएसबिल्ड से दूर होना एक और है।

यह भी एक मुद्दा क्यों है? आप एमएसबिल्ड से नफरत करते हैं, हम इसे प्राप्त करते हैं, लेकिन एमएसबिल्ड के बारे में आप इस तथ्य से अलग क्या नफरत करते हैं कि यह एक्सएमएल का उपयोग करने के लिए _dares_ है?

इस परिदृश्य का एक पागल परिणाम यह है कि वे अब MSBuild को Linux और OSX में पोर्ट करने में समय और प्रयास खर्च करने जा रहे हैं! कल्पना करो कि।

तुम सही कह रही हो! यह बहुत ही भयानक होने वाला है, किसी भी तरह के .net ऐप को किसी भी प्लेटफॉर्म पर विकसित करने में सक्षम होने के नाते, किसी भी आईडीई का उपयोग करके आप चाहते हैं। बच्चों के बारे में सोचो!
Microsoft की हिम्मत कैसे हुई कि वह अपने स्वयं के बंद-स्रोत तकनीक में निवेश करने के बजाय अपने काम को ओपन-सोर्स करने और अपने टूल को अन्य प्लेटफॉर्म पर पोर्ट करने में समय व्यतीत करे।

मुझे उनके कारण मिलते हैं, लेकिन उनके कारण मेरे लिए बिल्कुल भी काम नहीं करते हैं, और बहुत से लोगों के लिए काम नहीं करते हैं।

लेकिन हो सकता है कि वे आपसे ज्यादा लोगों के लिए काम करें?

हमने जिस दिशा में ले जा रहे थे, उसके बारे में दृढ़ आश्वासन के आधार पर निवेश किया, और वे शून्य जवाबदेही के साथ वापस चले गए हैं, और एक संकेत से ज्यादा कुछ नहीं है कि शायद उन्हें निर्णय को बेहतर ढंग से सूचित करना चाहिए था।

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

वे MSBuild द्वारा समर्थित किनारे के मामलों के आधार पर project.json पर निर्णय ले रहे हैं

यह _edge_ मामलों से बहुत आगे है, यह कहना भी हास्यास्पद है कि project.json लगभग पूर्ण है।

निश्चित रूप से ASP.NET परियोजनाओं को करने वाले किसी को भी उन किनारे के मामलों की आवश्यकता नहीं है।

मुझे लगता है कि यह इस मुद्दे की जड़ है: आप अपने अलावा किसी और की परवाह नहीं करते हैं, एक एएसपीनेट डेवलपर। पर्याप्त रूप से, लेकिन फिर से मैं आपसे कहूंगा: स्वीकार करें कि अन्य डेवलपर्स मायने रखते हैं और अपनी बाहों को ऊपर फेंकने के बजाय, इसे सबसे अच्छी प्रणाली बनाने की दिशा में काम करें। इसका मतलब पूरी तरह से अलग मार्कअप के लिए मनमाना सिंटैक्स बनाना नहीं है, इसका मतलब है कि यह स्वीकार करना कि तस्वीर सिर्फ आप से बड़ी है और इसे सभी के लिए महान बनाने के लिए दूसरों के साथ काम करना।
जैसा कि मैं कहता रहता हूं, अगर nuget.json ने आपकी सभी निर्भरताओं को सूचीबद्ध किया है, तो क्या बचा है? एक्सएमएल के नामित तत्वों में कुछ काफी स्थिर क्षेत्रों को परिभाषित करने में समस्या क्या है?

हकीकत यह है कि यह वास्तव में एक ओपन सोर्स प्रोजेक्ट नहीं है

जैसा कि अन्य ने कहा है, ओपन सोर्स होने का मतलब कुछ शिकायतकर्ताओं को पीछे की ओर झुकना नहीं है। वे पुल अनुरोध स्वीकार करते हैं, कुछ बेहतर लिखें।

यह देखते हुए कि सब कुछ कितना बड़ा और एकीकृत है, प्रासंगिक कोड सीखने पर भी विचार करना एक कठिन संभावना है।

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

तो, यह या तो हम प्रयास खर्च करते हैं और प्रोजेक्ट.जेसन बिल्ड सिस्टम को फोर्क करते हैं, या हम किसी अन्य बिल्ड सिस्टम (नकली?) पर स्विच करते हैं, या आप इसे चूसते हैं, या आप किसी अन्य प्लेटफॉर्म का उपयोग करते हैं। मेरा मानना ​​है कि मैंने वहां सभी विकल्पों की गणना कर ली है।

या ... और मेरा मतलब है कि यह सिर्फ एक पागल, आउट-ऑफ-द-बॉक्स विचार है, लेकिन आप वास्तव में बातचीत में कुछ रचनात्मक योगदान देने का प्रयास कर सकते हैं।

विषय पर वापस आना ....

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

csproj को केवल स्थिर भागों को परिभाषित करने दें।

हालांकि, इस दृष्टिकोण का नकारात्मक पक्ष जो मैं देख सकता हूं वह यह है कि मुझे यकीन नहीं है कि एकाधिक ढांचे को लक्षित करते समय यह कितना अच्छा काम करेगा, मुझे वास्तव में यह नहीं लगता कि इसे nuget.json में रखना समझ में आता है लेकिन nuget.json है अभी भी इसके बारे में जानना होगा।

project.json सिर्फ एक json फ़ाइल नहीं है।
csproj केवल एक XML फ़ाइल नहीं है।

आईएमएचओ, मेरे जैसे कई लोग, माइक्रोसॉफ्ट को देखने के लिए उत्साहित थे, अधिक सटीक रूप से Asp.Net टीम,
खुद को बहुत पुराने विरासत कोड/अवधारणाओं/प्रणाली/उपकरण/उपस्थिति/... से मुक्त करना

इसने हमें 'आशा' दी!

मैं पहले पूर्वावलोकन बिट्स के बाद से Asp.Net विकसित करता हूं। मैं ज्यादातर इसके साथ काम करना पसंद करता हूं। लेकिन 15 साल बाद
एक्सएमएल की तरह 'पुरानी' चीजें वास्तव में, वास्तव में भारी और पुरानी लगती हैं। धारणा महत्वपूर्ण है।

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

Project.json को हटाना कोई बड़ी बात नहीं है, लेकिन इसे बंद दरवाजों के पीछे लगभग आखिरी समय में करना उस 'आशा' को तुरंत मार देता है।

अचानक यह अब एक ओपन सोर्स प्रोजेक्ट की तरह महसूस नहीं होता है।

fyi: "Asp.Net Core" में कई शानदार विशेषताएं हैं। मैं ज्यादातर इसे प्यार करता हूँ।
Asp.Net टीम बहुत अच्छी है और मैं Asp.Net डेवलपर बनने के लिए गर्व महसूस नहीं कर सकता।

लेकिन मैं आहत हूं। शायद मैं अकेला नहीं हूं।

बस मेरे 2 सेंट।

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

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

अगर वे उन 3 वस्तुओं को ठीक करने का कोई तरीका ढूंढते हैं तो शायद मैं csproj फ़ाइलों के बारे में इतना अधिक शिकायत नहीं करता।

@neoकुशन

आप बस इतना करना चाहते हैं कि एक्सएमएल कितना खराब है, वास्तव में यह बताए बिना कि क्यों?

पूरी तरह से उचित नहीं है, मैं इस बारे में भी बात करना चाहता हूं कि एमएसबिल्ड कैसे खराब है :-)

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

इससे भी बदतर - कोई टिप्पणी नहीं

मेरा मानना ​​है कि कई लोगों ने यहां विकल्प पेश किए हैं। HJson सिर्फ एक विकल्प है। वाह! हमें इस पर पुनर्विचार करने की ज़रूरत नहीं है ;-)

आप इस बदलाव से काफी परेशान हैं

निष्पक्ष होने के लिए, मैं ज्यादातर इस बात से परेशान हूं कि एक बंद कमरे में यह परिवर्तन कैसे किया गया था, बिना उस समुदाय पर विचार किए या उसमें शामिल हुए, जिसने पिछले, बहुत दृढ़ समर्थन के लिए अंकित मूल्य पर project.json लिया था। बेटा, दोबारा ऐसी गलती नहीं करेगा!

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

मुझे संदेह है कि परिवर्तन से परेशान अधिकांश लोग सभी वेब डेवलपर हैं

उम्म, हाँ, ऐसा इसलिए होगा क्योंकि वे एकमात्र ऐसे डेवलपर हैं जिन्हें आपने project.json की पेशकश की थी। अन्य समाचारों में, स्विफ्ट डेवलपर्स भी निर्णय से परेशान नहीं हैं। मेरा मतलब है कि आप यहाँ क्या कह रहे हैं, इसके बारे में सोचें:

1. केवल वेब डेवलपर्स को ही मिली यह नई सुविधा
2. जब हम इसे ले गए तो उनमें से कई वास्तव में परेशान थे
3. किसी और को इसका इस्तेमाल नहीं करना पड़ा
4. जिन लोगों ने इसका इस्तेमाल नहीं किया, वे इस बात से परेशान नहीं हैं कि इसे ले लिया गया है
   अन्य सभी देव इसे नहीं चाहेंगे।

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

और "वेब डेवलपर्स" से आपका क्या मतलब है? आप किसी छोटी कंपनी के लिए कुछ छोटी वेबसाइट के बारे में सोच रहे हैं? प्रबंधन के तहत अरबों डॉलर के साथ एक परिसंपत्ति प्रबंधन व्यवसाय का समर्थन करने वाले माइक्रोसर्विसेज के ढेर के बारे में कैसे। ज़रूर, वहाँ एक वेबसाइट भी है। लेकिन यह सिस्टम का लगभग 10% है। ओह, और हाँ, यह वास्तव में क्लाउड पर भी लक्षित है, इसलिए शायद हम वास्तव में "क्लाउड डेवलपर्स" की बात कर रहे हैं।

ऐसा लगता है कि आप यह भी नहीं समझ पा रहे हैं कि जिस तकनीक पर आप जल्दबाजी में निर्णय ले रहे हैं, उसका उपयोग कैसे किया जा रहा है, या किसके द्वारा किया जा रहा है।

एमएसबिल्ड के बारे में आप इस तथ्य से अलग क्या नफरत करते हैं कि यह एक्सएमएल का उपयोग करने की हिम्मत करता है

यह 'अत्यधिक जटिल' है
यह एक प्रतिबाधा बेमेल है, जो अनुमान आधारित तर्क को उन स्थितियों में धकेलता है जहां लोग मुख्य रूप से अनिवार्य या घोषणात्मक तर्क से निपट रहे हैं।
माई गॉड मैन, क्या आपने वास्तव में एमएसबिल्ड फाइलों पर _देखा है? ठीक है, क्षमा करें, आपने एक्सएमएल का उपयोग करने से अलग कहा ;-)
जिस तरह से संपत्तियों और वस्तुओं की घोषणा की जाती है, वह उन लोगों के लिए प्रति-सहज है जो नियमित रूप से इसका उपयोग नहीं करते हैं
इसका उपयोग एक आकार के रूप में किया जाता है जो सभी उपकरण फिट बैठता है जो स्क्रिप्ट में किए जाने वाले कार्यों को करने का प्रयास करता है। कील पर हथौड़ा मारो।
बड़ी संख्या में मामलों में, यह एक बड़ी फ़ाइल में जो कुछ भी करता है उसे स्क्रिप्ट की 3 पंक्तियों में व्यक्त किया जा सकता है
इसमें उगने वाला वीएस कचरा। मैंने सुना है कि इसे ठीक किया जा रहा है। यह देखने के लिए कि क्या वह भी कट जाता है, कुछ घबराहट के साथ प्रतीक्षा कर रहा है। जैसा कि ऊपर उल्लेख किया गया है, मैं अब वादों के बारे में थोड़ा चिंतित हूं।

ऐसा क्या है जिससे आप इतना प्यार करते हैं? और सबसे महत्वपूर्ण बात, क्या आप यह स्वीकार करने को तैयार हैं कि दूसरे आपके विचार साझा नहीं कर सकते? यदि हां, तो क्या आप स्वीकार कर सकते हैं कि "एक आकार सभी के लिए उपयुक्त है" सही दृष्टिकोण नहीं हो सकता है?

आप किस दिशा की बात कर रहे हैं

project.json हमारे नए प्रोजेक्ट दृष्टिकोण का आधार है जिसे संप्रेषित किया गया था। हमने उस प्रतिबद्धता के आधार पर वास्तविक धन और समय और दर्द का निवेश किया।

लेकिन हो सकता है कि वे आपसे ज्यादा लोगों के लिए काम करें?

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

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

आप अपने अलावा किसी और की परवाह नहीं करते हैं, एक asp.net डेवलपर

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

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

हम चर्चा कर सकते हैं कि यह कितना व्यवहार्य है, और शायद यह नहीं है, लेकिन हम नहीं जानते , क्योंकि हमसे कभी परामर्श नहीं किया गया था या इसमें शामिल नहीं किया गया था।

आप वास्तव में बहिष्कृत मध्य के अपने तर्क से प्यार करते हैं।

वे पुल अनुरोध स्वीकार करते हैं

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

ठीक है, तो मैं मूल रूप से इसे पढ़ रहा हूं ...

वाह आपने उसमें बहुत कुछ पढ़ा। भगवान अगर मैं आपकी तरह पढ़ता, तो मैं कभी किताब खत्म नहीं करता। और यह लेखक ने जो लिखा है उससे काफी अलग होगा।

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

धिक्कार है! मैं तुम्हारी तरह पढ़ता हूँ! सिवाय इसके कि यह वास्तव में आपकी कुछ हिस्टेरिकल व्याख्याओं की तुलना में मूल पाठ को थोड़ा बेहतर बनाता है।

आप वास्तव में बातचीत में कुछ रचनात्मक योगदान देने का प्रयास कर सकते हैं।

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

मुझे क्या मिला? बाधा, अपमान और अपवंचन। तो मुझे बताओ, आप यह पूछने के लिए असंरचित क्यों मानते हैं कि लाखों लोगों को प्रभावित करने वाला कोई बड़ा निर्णय लेने वाले ने अपना होमवर्क किया है? और क्या आप इसे रचनात्मक या संदिग्ध मानते हैं जब कहा जाता है कि लोग होमवर्क बुक दिखाने से इनकार करते हैं?

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

और आप जानते हैं कि क्या, यदि आप निर्णय को फिर से खोलते हैं, विचारों की याचना करते हैं, और निर्णय उसी तरह नीचे आता है जैसे उसके पास है, तो क्या नुकसान है? और अगर, विचारों की मांग करने के बाद, आपको पता चलता है कि आपके निर्णय लेने में कुछ त्रुटिपूर्ण था, और आप इसे ठीक करते हैं, तो क्या यह वास्तव में बेहतर नहीं है?

वाह, गंभीरता से। क्या हम इसे खत्म कर सकते हैं?

सरल प्रश्न: क्या आप विपक्ष को साथ लेकर चलेंगे और नई जानकारी के आधार पर निर्णय पर फिर से विचार करेंगे?

या क्या आप केवल यह कह रहे हैं कि जो लोग आपसे असहमत हैं, वे पागल, मूर्ख, अकुशल, _अनसूचित_ हैं, या अन्यथा एक सूचित, वैध राय रखने में असमर्थ हैं?

सुझाव: Microsoft fork msbuild csproj लीगेसी ग्राहकों का समर्थन करेगा। #carryOnAsNormal

मैं भी एक लंबे समय से नेट डेवलपर हूं, मार्केटिंग से पहले 1.0 के पूर्वावलोकन के साथ काम कर रहा था, यहां तक ​​​​कि नेट नाम का आविष्कार भी किया था। मातम में खोए बिना, यहाँ मेरे दो सेंट हैं।

मैं अपना शेष जीवन बिना किसी अन्य xml कॉन्फ़िग फ़ाइल को देखे और पूरी तरह से खुश रह सकता था।

मुझे एक्सएमएल कॉन्फ़िगरेशन नहीं चाहिए। कहीं भी। कभी।

मुझे परवाह नहीं है अगर टीम csproj के हर एक दर्द को ठीक करती है; अगर यह अभी भी एक एक्सएमएल कॉन्फ़िगरेशन फ़ाइल है जब आप कर चुके हैं, तो मुझे कोई दिलचस्पी नहीं है। आप भी जा सकते हैं बस .net 4.5 प्रोजेक्ट सिस्टम रखें।

MSBuild के लिए ... MSBuild एक आग में मर सकता है।

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

अगर आपके पास एएसपीनेट कोर 1.0 टाइमफ्रेम के लिए एमएसबिल्ड के लिए एक अच्छा प्रतिस्थापन बनाने का समय नहीं है, तो सुनिश्चित करें ... एएसपीनेट कोर 2.0 तक एमएसबिल्ड का लाभ उठाने का एक तरीका लेकर आएं। चक्र; लेकिन कम से कम उस कली को किसी ऐसी चीज़ से बदलने की दिशा में काम करते रहें जिसके साथ हममें से बाकी लोग काम कर सकें।

इस बीच, जितना हो सके json में कॉन्फिगरेशन रखने की कोशिश करें। मुझे विशेष रूप से परवाह नहीं है अगर यह project.json है, या कुछ नया और बेहतर है। यदि आवश्यक हो, तो टूलींग को फ्लाई पर विरासत एमएसबिल्ड फाइलें उत्पन्न करें जब/यदि आवश्यक हो - उन्हें उप-फ़ोल्डर में कहीं या कुछ में चिपकाएं।

मैं नहीं चाहता कि मेरा फाइल सिस्टम इस तरह दिख रहा है:

• बोवर.जेसन
• पैकेज.जेसन
• nuget.json
• सब कुछ-बाकी.जेसन
• Microsoft-old-ass.xml.csproj

साथ ही, क्या आप कृपया 260 वर्ण पथ लंबाई सीमा तय कर सकते हैं... कृपया... हाँ, मुझे पता है कि विंडोज़ के साथ इसका बहुत कुछ लेना-देना है, लेकिन गंभीरता से... यह 2016 है।

पुनश्च. आप, विपक्ष की अनदेखी पर ले जाने के लिए जा रहे हैं, तो आप निम्न जानकारी प्रदान करें कर सकते हैं:

• हम बिल्ड टूल्स डेवलपर स्लैक चैनलों तक कैसे पहुंच प्राप्त करेंगे
• वर्तमान आर्किटेक्चर और कोड का एक उच्च स्तरीय दृश्य, और जहां MSBuild/xproj में जाने के लिए परिवर्तन किए जा रहे हैं, इसलिए हम अपने इच्छित बिट्स को रखने और अच्छी तरह से एकीकृत करने के लिए अपने दृष्टिकोण की योजना बना सकते हैं।
• आश्वासन है कि अगर गुणवत्ता मानदंडों को पूरा करते हैं तो प्रोजेक्ट.जेसन आधारित टूलिंग में बेक करने के अनुरोधों को स्वीकार किया जाएगा
• यह आश्वासन कि यदि गुणवत्ता मानदंड पूरे होते हैं, तो हम पूर्ण प्रोजेक्ट.जेसन के लिए "डॉटनेट बिल्ड" समर्थन के साथ-साथ ASP.NET सरल टेम्प्लेट, और संभावित रूप से अधिक मानक प्रोजेक्ट प्रकारों के लिए कुछ टेम्प्लेट शामिल कर सकते हैं।

"रचनात्मक बनें", "योगदान न करें, आवाज न उठाएं"। खैर, आप जो मांगते हैं वह आपको मिलता है ...

@ माइक-ईईई, SimpleUseCaseBuild के लिए Xaml क्रमांकन करना चाहते हैं?

यह सब पढ़ने के बाद मैं इस निष्कर्ष पर पहुंचा:

• project.json बहुत सुधार लाया। इनमें से कोई भी संभव नहीं होता अगर .net और asp.net कोर को लीगेसी कोड और टूल्स से जोड़ा जाता
• project.json (और json) सही नहीं है
• एक्सएमएल बनाम जेसन बनाम कोई सीरियलाइजेशन भाषाएं बाँझ हैं। .net कोर चुनौतियों का उत्तर देने के लिए उनका लाभ कैसे उठाया जाए, इस बारे में चर्चा अधिक दिलचस्प होगी
• एमएसबिल्ड में वापस जाना विरासत को वापस ला रहा है और शायद इसका मतलब है कि हम परियोजना प्रणाली में अब और सुधार नहीं देखेंगे, क्योंकि .net टीमों को उनकी कुछ स्वतंत्रता खोने की संभावना है

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

LOL @shederman आपने मुझे अब क्या खींचा है ?! : मुस्कान: और क्या चर्चा है! वास्तव में आश्चर्यजनक।

एक्सएमएल बनाम जेसन बनाम कोई सीरियलाइजेशन भाषाएं बाँझ हैं। .net कोर चुनौतियों का उत्तर देने के लिए उनका लाभ कैसे उठाया जाए, इस बारे में चर्चा अधिक दिलचस्प होगी

हां, मेरे लिए जो महत्वपूर्ण है वह है परियोजनाओं का वर्णन करने के लिए इस्तेमाल किया जाने वाला समर्थन मॉडल और/या वे क्या करते हैं, और इस बातचीत में से कुछ ने उस पर छुआ है। मैं एक बेहतर प्रोजेक्ट मॉडल/एपीआई देखना चाहता हूं जिसका वर्णन करना और उसके साथ काम करना आसान है (इसमें वर्णित प्रारूप से कोई फर्क नहीं पड़ता - हालांकि हाँ मैं करता हूं: दिल: मेरा एक्सएमएल!)। इस संबंध में और रोसलिन के प्रोजेक्ट सिस्टम (https://github.com/dotnet/roslyn-project) के संबंध में यहां एमएसबिल्ड के रेपो (https://github.com/Microsoft/msbuild/issues/613) पर मेरी खुली चर्चा है। -सिस्टम/मुद्दों/37) के रूप में अच्छी तरह से रुचि रखते हैं।

यहां वास्तव में बहुत सारे महान बिंदु हैं, और मैं व्यक्तिगत रूप से "असंरचित" या अन्यथा ऊर्जा खोद रहा हूं। मुझे लगता है कि यहां हर किसी का दिल एमएसएफटी को बेहतर बनाने और उत्पादित होने वाले उत्पादों से सर्वश्रेष्ठ बनाने में है। :+1:

मेरे 2 सेंट:

मेरा मानना ​​है कि इस बदलाव पर दो तरह के लोग चर्चा कर रहे हैं:

• डेवलपर्स जो _विभिन्न प्रकार की परियोजनाओं के निर्माण के लिए VS और .NET का उपयोग कर रहे हैं और उन्हें लंबे समय से उन परियोजनाओं का समर्थन करना है
• डेवलपर्स जिनके पास ऐसा सामान नहीं है और वे नए, स्वच्छ और फैंसी, क्रॉस प्लेटफॉर्म ASP.NET कोर फ्रेमवर्क चाहते हैं

व्यक्तिगत रूप से, मैं पहली श्रेणी में हूं इसलिए मैं चाहता हूं कि नया ASP.NET कोर जितना संभव हो सके अन्य VS प्रोजेक्ट प्रकारों के साथ संगत हो, और "पुराने" csproj/msbuild समाधान पर जाना मेरे लिए एक जीत है (+ my टीम और शायद कई अन्य डेवलपर्स)। इस तरह संक्रमण बहुत आसान और स्पष्ट होगा। हो सकता है कि दूसरी श्रेणी के लोग मुझसे सहमत न हों (या वे परवाह नहीं करते)।

एकमात्र बड़ी समस्या जो मैं अब देख रहा हूं वह यह है कि कैसे NuGet संकुल को परिभाषित और संदर्भित किया जाता है। package.config और csproj दोनों फाइलों को बनाए रखना एक दर्द है (जैसा कि @cwe1ss की तरह किया जाना चाहिए)। यह इस विषय में सबसे रचनात्मक टिप्पणियों में से एक था बीटीडब्ल्यू ...

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

@Funbit लोगों को वर्गीकृत करने की कोशिश करने से मदद नहीं मिलेगी। और मैं आपकी किसी भी श्रेणी में फिट नहीं बैठता। मैं v1 बीटा के बाद से एएसपीनेट डेवलपर हूं। मैंने लगभग 2 साल पहले एक होना बंद कर दिया था, लेकिन .net कोर ने मुझे वापस लाया क्योंकि यह साफ स्लेट और .net और नोड दुनिया का सबसे अच्छा था।

मैं चाहता हूं कि .net कोर सफल हो, न कि कोई पुरानी कॉर्पोरेट तकनीक, जिसमें कोई अंगीकरण न हो और कोई समुदाय न हो।

मेरे हिस्से के लिए, मुझे वास्तव में इस निर्णय की परवाह नहीं है, मुझे एक्सएमएल की ज्यादा परवाह नहीं है, और एक उद्धरण चोरी करने के लिए: "घुंघराले ब्रेसिज़ कोण ब्रैकेट से बेहतर हैं", लेकिन यह वास्तव में मुझे वापस जाने से परेशान नहीं करता है csproj/msbuild - मैं लचीला हूं मैं सामना कर सकता हूं।

हालांकि मैं @shederman टिप्पणियों में से कुछ को प्रतिध्वनित करना चाहूंगा:

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

तथा

निष्पक्ष होने के लिए, मैं ज्यादातर इस बात से परेशान हूं कि एक बंद कमरे में यह परिवर्तन कैसे किया गया था, बिना उस समुदाय पर विचार किए या उसमें शामिल हुए, जिसने पिछले, बहुत दृढ़ समर्थन के लिए अंकित मूल्य पर project.json लिया था। बेटा, दोबारा ऐसी गलती नहीं करेगा!

यह मुझे परेशान करता है, माइक्रोसॉफ्ट ने ओपन सोर्सिंग .NET का एक बड़ा सौदा किया है और वास्तव में समुदाय के साथ शामिल होना और काम करना चाहता है, उनकी प्रतिक्रिया प्राप्त करना और समुदाय का एक अच्छा 'सदस्य' (साझेदार?) बनना चाहता है। लेकिन इस तरह की चीज वास्तव में उस पूरे प्रयास को पीछे छोड़ देती है और .NET पारिस्थितिकी तंत्र को देती है कि पूरे "बोर्गिश" को लगता है कि /. समुदाय ने इसे वर्षों से लेबल किया है।

Microsoft के प्रति निष्पक्ष होने के लिए, कॉर्पोरेट प्रायोजित परियोजना के साथ इस तरह का काम करने वाले वे अकेले नहीं हैं; नोडज समुदाय में विभाजन याद रखें (जिसके कारण io.js कांटा हुआ)? लेकिन मुझे लगता है कि जब यह माइक्रोसॉफ्ट है, तो यह बहुत बुरा है।

यह उस अनुपात से बाहर हो गया जो शुरू में इरादा था।

यह उस अनुपात से बाहर हो गया जो शुरू में इरादा था

@MaximRouiller क्या आप भी डेवलपर हैं, भाई ??? :मुस्कुराओ:

@ माइक-ईईई मैं करता हूँ। मैं कुछ गरमागरम बहस की उम्मीद कर रहा था लेकिन मैंने बहुत अधिक व्यक्तिगत हमले देखे हैं। :निराश:

परियोजनाओं में स्रोत फ़ाइलों को साझा करने में सक्षम होने की आवश्यकता है

@darrelmiller यह मेरे लिए डरावना लगता है, क्योंकि ऐसा लगता है कि .csproj में लिस्टिंग फ़ाइलें वापस आ रही हैं।

@lokitoth शायद कोई कारण नहीं है कि लिंक की गई फ़ाइलें वाइल्डकार्ड ग्लब्स का भी उपयोग नहीं कर सकती हैं।

@MaximRouiller मैं भी, @shederman जानता है कि कैसे फेंकना है! हाहा। संयोग से, मैं यह कहने जा रहा था कि @shederman मेरे आंतरिक कोडिंग जानवर का प्रतिनिधित्व करता है, लेकिन इससे पहले कि मुझे पता था कि एक @CodingGorilla है। :हंसना:

मुझे लगता है कि हमें खुद को यह याद दिलाने की जरूरत है कि हम जो करते हैं वह वास्तव में कड़ी मेहनत है, और तभी यह काम करता है! वहां पहुंचना और भी मुश्किल है। सिल्वरलाइट के साथ मेरे अनुभव में (हाँ, मैं उसके साथ जल गया था, इसलिए मुझे पता है कि @shederman कहाँ से आ रहा है), इसने मुझे यह देखने में मदद की कि शायद मुझे _everything_ (या यहां तक ​​​​कि _anything_ कभी-कभी, ऐसा लगता है!) और चीजों के बारे में खुले दिमाग रखने के लिए। मैं अभी भी असफल हूं। यहां तक ​​कि जब मैंने प्रोजेक्ट.जेसन पहल देखी तो मैंने उस विभाजन को इंगित करने के लिए अपनी पूरी कोशिश की, लेकिन ऐसा करने में रेपो में यहां के लोगों के साथ थोड़ा बहुत कठोर हो सकता था।

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

ठीक है... पर्याप्त उपदेश और दिन के लिए राह-राह। :stuck_out_tongue: हमारे नियमित रूप से निर्धारित स्लगफेस्ट पर वापस जाएं!

यह मेरे लिए डरावना लगता है, क्योंकि ऐसा लगता है कि .csproj में लिस्टिंग फ़ाइलें वापस आ रही हैं।

इसके अलावा, एक तरफ के रूप में, क्या मैं ग्रह पर अकेला व्यक्ति हूं जो इस विशेषता की सराहना करता है? :अटक_बाहर_जीभ:

यह मेरे लिए डरावना लगता है, क्योंकि ऐसा लगता है कि .csproj में लिस्टिंग फ़ाइलें वापस आ रही हैं।

इसके अलावा, एक तरफ के रूप में, क्या मुझे लगता है कि ग्रह पर केवल वही व्यक्ति है जो इस विशेषता की सराहना करता है? :अटक_बाहर_जीभ:

@ माइक-ईईई हां, मुझे लगता है कि आप हैं। :आँख मारना:

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

@shederman जानता है कि कैसे फेंकना है!
मैं

मैं कोशिश करता हूँ। मुझे उम्मीद है कि मैंने हालांकि किसी का अपमान नहीं किया। मैंने केवल तर्क-वितर्क के पीछे जाने की बहुत कोशिश की।

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

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

क्या मुख्य उद्देश्य यह है कि लोग विजुअल स्टूडियो में डिबग करते समय पहले से बिल्ड और आफ्टरबिल्ड चरणों को जोड़ने के लिए csproj फाइलों को संपादित करना चाहते हैं?

@ माइक-ईईई हो सकता है; बहुत बड़ी संख्या में फाइलों (जैसे एक्सप्रेशन ब्लेंड, विजुअल स्टूडियो एक्सएएमएल डिज़ाइनर, इत्यादि) के साथ परियोजनाओं से निपटने के दौरान मुझे ज्यादातर यह याद है कि यह बट में शाही दर्द है, इस बिंदु पर कि हमने इसे वाइल्डकार्ड चयन के लिए बदल दिया है - जो वीएस करता है ठीक से काम करना नहीं जानता, जिसका अर्थ है कि हर बार जब मैं कोई फ़ाइल जोड़ता हूं तो मुझे प्रोजेक्ट को फिर से लोड करना पड़ता है (या "यह फ़ाइल पहले से ही जोड़ा जा चुका है" बिल्ड पर त्रुटि)

आप वास्तव में इस "सुविधा" के बारे में क्या पसंद करते हैं (परियोजनाओं में फ़ाइलों को साझा नहीं करना, जो स्पष्ट रूप से उपयोगी है, लेकिन वीएस के बारे में केवल तभी ठीक से काम कर रहा है जब प्रत्येक फ़ाइल व्यक्तिगत रूप से सूचीबद्ध हो)?

आप वास्तव में इस "सुविधा" के बारे में क्या पसंद करते हैं (परियोजनाओं में फ़ाइलों को साझा नहीं करना, जो स्पष्ट रूप से उपयोगी है, लेकिन वीएस के बारे में केवल तभी ठीक से काम कर रहा है जब प्रत्येक फ़ाइल व्यक्तिगत रूप से सूचीबद्ध हो)?

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

मैं csproj फ़ाइलों को संपादित करने के लिए उपयोग-मामलों के बारे में उत्सुक हूँ

.csproj के लिए (इनमें से हर एक मैंने किया है, और बहुमत के लिए, कई बार)

• यदि आपको डेस्कटॉप एप्लिकेशन से UWP प्रकारों को संदर्भित करने की आवश्यकता है
• यदि आपको NuGet के साथ VS ब्रेकिंग चीजों को ठीक करने की आवश्यकता है (विशेषकर a.targets फ़ाइलों को जोड़ने और .proj/.props में शामिल हैं)
• यदि आपको उत्पन्न आउटपुट के लेआउट को बदलने की आवश्यकता है
• यदि आप परियोजनाओं को पुन: सक्रिय कर रहे हैं और असेंबली का नाम बदल रहे हैं
• यदि आप एक बड़ी रिफैक्टरिंग कर रहे हैं जो बहुत सारी फाइलों को प्रभावित करती है
• यदि आपके पास एक मर्ज विरोध था क्योंकि एक ही प्रोजेक्ट में कई लोग काम कर रहे हैं और आप वाइल्डकार्ड का उपयोग नहीं कर रहे हैं
• यदि आपको यह समझने की आवश्यकता है कि निर्माण अचानक क्यों काम नहीं कर रहा है (संपादित करें: मुझे निर्दिष्ट करना चाहिए था - यह "मुझे इसे पढ़ने योग्य होने की आवश्यकता क्यों है, और 'स्व-निहित'" से अधिक है)
• यदि आपको कष्टप्रद निर्भरताओं के कारण असेंबली संस्करण संघर्षों को डीबग करने की आवश्यकता है
• यदि आप एक "लिंक्ड" (साझा) फ़ाइल जोड़ने का प्रयास कर रहे हैं

Project.json . के लिए

• फ़ाइल को खरोंच से हाथ से बनाना (गंभीर रूप से महत्वपूर्ण)
• NuGet पैकेज जोड़ना/निकालना
• लक्ष्य ढांचे को बदलना
• आउटपुट पैकेज संस्करण बदलना

@shederman मुझे एहसास है कि आप निराश हैं, लेकिन जब आप जवाब देते हैं

सच में? लोग अभी भी ऐसा करते हैं? मेरा मतलब है कि मैं इसे AssemblyInfo.cs के लिए करता था, और वापस अंधेरे युग में करता था

आप एक स्वर सेट कर रहे हैं। आमने-सामने बातचीत करना ठीक है, लेकिन इस प्रकार के वातावरण में, यह भावनाओं पर आधारित टिप्पणियों की एक पूरी श्रृंखला के लिए द्वार खोलता है जो बातचीत को ध्रुवीकृत करता है और महत्वपूर्ण बिंदुओं पर ध्यान केंद्रित करना कठिन बनाता है। मुझे पता है कि इन चर्चाओं से भावनाओं को बाहर रखना कठिन है (मेरी जीभ काटने के निशान से भरी हुई है;-)) लेकिन हमें चर्चा को उपयोगी बनाए रखने के लिए वास्तव में प्रयास करना होगा।

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

रिकॉर्ड के लिए, मुझे वास्तव में @ माइक-ईईई के प्रस्ताव wrt को रोसलिन का उपयोग करना पसंद है और प्रोजेक्ट फ़ाइल को क्रमबद्ध एएसटी होना चाहिए। लेकिन केवल तभी जब हम केवल नोटपैड का उपयोग करके काम करना उतना ही आसान बना सकें। (हां, मेरा मतलब नोटपैड से है, नोटपैड ++ या कुछ और उन्नत नहीं: यह मानव-संपादन योग्य फ़ाइल प्रारूप की उपयोगिता के लिए "स्मोक टेस्ट" है)

@CodingGorilla मैं इसके लिए

तो मूल रूप से, "ऑप्ट-इन" के बजाय "ऑप्ट-आउट" मॉडल को देखते हुए।

उन लोगों के लिए जो बिना लोड किए प्रोजेक्ट फाइलों को संपादित करना चाहते हैं।... https://twitter.com/migueldeicaza/status/730978470734401536

उन लोगों के लिए जो बिना लोड किए प्रोजेक्ट फाइलों को संपादित करना चाहते हैं ....

@darrelmiller मैं यहाँ क्या देख रहा हूँ ... इसके बजाय Xamarin Studio का उपयोग करने का सुझाव दे रहा हूँ? हाँ, वह अनलोडिंग/लोडिंग व्यवसाय/वर्कफ़्लो/अनुभव सबसे खराब है! यह लगभग 2003 से है, हे।

मैं इस धारणा को दूसरा मानता हूं कि मानक टेक्स्ट एडिटर (यानी नोटपैड) के साथ अंतिम फ़ाइल आसानी से संपादन योग्य और पठनीय होनी चाहिए, प्रारूप जो भी हो।

मुझे यह भी लगता है कि बेहतर टूलिंग वर्तमान csproj के पीछे बहुत सारे दर्द बिंदुओं को दूर करेगा। वीएस सबसे अच्छा उदाहरण नहीं है और मुझे लगता है कि वीएस आपको जो अनुभव देता है वह वास्तव में एमएसबिल्ड प्रोजेक्ट सिस्टम के बारे में बहुत से लोग नफरत करते हैं।

@ माइक-ईईई मिगुएल की टिप्पणी का उत्तर डेविड कीन से था जो नई परियोजना प्रणाली पर काम करता है। टीम को पता है कि वीएस को भी ऐसा करने में सक्षम होना चाहिए।

@ माइक-ईईई मुझे लगता है कि मेरी बात यह है कि मैं जो कुछ भी लेकर आता हूं उससे निपट सकता हूं। एमएसबिल्ड प्रोजेक्ट सिस्टम कुछ भी करने के लिए पर्याप्त मजबूत है (जब तक @shederman कहते हैं, यह सिर्फ _can't_ एक्सएमएल नहीं है)। मुझे लगता है कि कुछ लोग सिर्फ "यह मेरा रास्ता होना चाहिए या यह एक असफल है" का दावा कर रहे हैं, और जैसा कि किसी और ने कहा (क्षमा करें भूल गए कि यह धागा YUUUUUUGE है!) "मैं खुले दिमाग रखने की कोशिश करता हूं ..." और बस अनुकूलित करें।

और इसके अलावा, आप कुछ नया सीख सकते हैं, और यह हमेशा एक अच्छी बात है। :मुस्कुराना:

@neoKushan मैं खरोंच से

@CodingGorilla वास्तव में मेरा मुख्य गोमांस MSBuild के साथ है। एक्सएमएल एक समस्या है, लेकिन एमएसबिल्ड जितना बुरा नहीं है।

मैंने xproj के साथ प्रोजेक्ट.json सपोर्ट को साथ-साथ चलने के लिए खुद काम करने की पेशकश की है। वह जो सबसे ज्यादा परवाह करता है, काम करता है, है ना?

और यह वास्तव में क्रूक्स है। क्या टीम मुझे यह योगदान करने की अनुमति देगी? और यदि नहीं तो बतायें, क्यों नहीं? आखिर यह ओएसएस है, है ना?

फिर, यदि आप MSBuild को पसंद करते हैं और इसकी शक्ति चाहते हैं, तो आप xproj का उपयोग करते हैं।

और अगर आपको ASP.NET कोर के लिए बनाया गया टूलींग पसंद है, तो आप उसका उपयोग करते रहें।

वे एक ही अंतर्निहित कंपाइलर का उपयोग करते हैं।

और यह किसी भी मामले में इतना काम भी नहीं होना चाहिए। मुझे बस इतना करना है कि उस कोड को दोबारा दोहराएं जिसे वे किसी अन्य कमांड में बहिष्कृत कर रहे हैं।

आदर्श रूप से मैं "डॉटनेट बिल्ड" का उपयोग करने और डीआईआर को देखने में सक्षम होना चाहता हूं और तय करता हूं कि कौन सी फाइलों के आधार पर उपयोग करना है। लेकिन बिल्ड या यहां तक ​​​​कि एक नया कमांड पर एक विकल्प ध्वज ठीक रहेगा।

@sandorfr मैं पूरी तरह से MSBuild फाइलें लिखने से सहमत हूं जो आपकी _entire_ निर्माण प्रक्रिया को परिभाषित करती हैं, यह एक विशाल दर्द से कम नहीं है, लेकिन अगर मुझे गलत नहीं लगता है तो हम वास्तव में यहां बात नहीं कर रहे हैं - हम _just_ परियोजना के बारे में बात कर रहे हैं संरचना।

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

आपकी पसंद की बिल्ड सिस्टम का उपयोग करने से आपको अभी भी कुछ भी नहीं रोक रहा है, चाहे वह केक हो या टीएफएस टीम सर्विसेज या जो भी हो।

फिर, यह निर्धारित कर रहा है कि टीम इसे "राइट" करती है।

वीएस सबसे अच्छा उदाहरण नहीं है और मुझे लगता है कि वीएस आपको जो अनुभव देता है वह वास्तव में एमएसबिल्ड प्रोजेक्ट सिस्टम के बारे में बहुत से लोग नफरत करते हैं।

@neoKushan इस तरह मैं टीएफएस बिल्ड और

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

MSBuild परियोजना प्रणाली कुछ भी करने के लिए पर्याप्त मजबूत है

यह समस्या का हिस्सा है और इसे पढ़ते समय csproj फ़ाइल में क्या हो रहा है, यह समझना इतना कठिन है, जो इसे प्रोजेक्ट फ़ाइल प्रारूप के लिए एक खराब विकल्प बनाता है (बिल्ड परिभाषा फ़ाइल प्रारूप के साथ भ्रमित नहीं होना चाहिए)

(संपादित करें: जोड़ा गया)

आपकी पसंद की बिल्ड सिस्टम का उपयोग करने से आपको अभी भी कुछ भी नहीं रोक रहा है, चाहे वह केक हो या टीएफएस टीम सर्विसेज या जो भी हो।

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

हाहा हाँ @ cwe1ss (टूलिंग सुधार की बात कर रहे हैं!) मैं बस सोच रहा था कि जब बातचीत में चीजें टूट जाती हैं तो

क्या मैं सुझाव दे सकता हूं कि हम सभी बुधवार को अगले सामुदायिक स्टैंडअप पर कूद जाएं? मुझे संदेह है कि यह ज्यादातर एक या दो दिन पहले आरसी 2 के रिलीज के बारे में बात कर रहा होगा (कोई उम्मीद कर सकता है!) जो वास्तव में उत्तर दे सकता है।

क्या मैं सुझाव दे सकता हूं कि हम सभी बुधवार को अगले सामुदायिक स्टैंडअप पर कूद जाएं?

केवल अगर @shederman प्रतिनिधित्व करता है। मैं उसे वास्तविक समय में डेवलपर्स और उनके विचारों को तोड़ते हुए देखना चाहता हूं। WWE पीपीवी इवेंट की तरह!

मुझे लगता है कि [projectName].csproj पर project.json का लाभ प्रारूप के बारे में नहीं है। यह सभी पुराने सामानों के साथ पीछे की ओर संगत होने की आवश्यकता नहीं है। इसने इसे बहुत सरल होने दिया। यह मानते हुए कि डेमियन एडवर्ड और टीम उसके सभी निर्दिष्ट लक्ष्यों को पूरा कर सकते हैं, मुझे वास्तव में एक्सएमएल बनाम जेएसओएन बनाम वाईएमएल बनाम की परवाह नहीं है ... मेरे लिए जो महत्वपूर्ण है वह सादगी है और जब मैं लिनक्स पर हूं तो विंडोज़ के लिए वहां मौजूद सामान नहीं देखना है .

@glennsills मुझे नहीं लगता कि MSBuild प्रोजेक्ट फ़ाइल में वास्तव में बहुत कुछ है जो _windows_ के लिए विशिष्ट है, यह अधिक है कि यह MS बिल्ड के लिए विशिष्ट है, या अन्य प्रोजेक्ट प्रकार जिनकी आपको परवाह नहीं है। MSBuild को खुश रखने के लिए वास्तव में खाली तत्वों का एक गुच्छा रखने की आवश्यकता नहीं है। मुझे उम्मीद है कि टीम जितना संभव हो उतना कटौती करने की योजना बना रही है, लेकिन हम देखेंगे।

@ माइक-ईईई केवल अगर @shederman प्रतिनिधित्व करता है। मैं उसे वास्तविक समय में डेवलपर्स और उनके विचारों को तोड़ते हुए देखना चाहता हूं। WWE पीपीवी इवेंट की तरह!

मैं इसे बनाने की कोशिश करूंगा। मैं आपको चेतावनी देता हूं कि मैं टाइप करने की तुलना में धीमी गति से बात करता हूं, इसलिए अपनी आशाओं को मत बढ़ाओ 😄

इसलिए, https://github.com/dotnet/roslyn-project-system/issues/40 दिए गए वर्म्स के कैन को खोलने के जोखिम पर, लोग वास्तव में कट-डाउन csproj फ़ाइल के बारे में कैसा महसूस करेंगे जिसमें केवल निहित है (डिफ़ॉल्ट रूप से) ) परियोजना के लिए नंगे अनिवार्य?

(कृपया इसे "आई हेट एक्सएमएल!" में न बदलें।

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

@शेडरमैन

क्या होगा यदि हमने MSBuild को JSON फ़ाइलों को स्वीकार करने के लिए बनाया है? :हँसना: (विरोध नहीं कर सका)

@shederman किसी भी प्रकार के तीखेपन को गंभीरता से लेना कठिन है और मैं चाहूंगा कि Microsoft ने इस _discussion_ को गंभीरता से लिया।

जिस तरह से यह 5 वर्षों में चल रहा है, आप स्विफ्ट, जावा (!!), नोड.जेएस या अमृत प्रोग्रामिंग करेंगे। ;)

इन दिनों .NET परियोजनाओं/समाधानों/जो भी हो, में दो तरह की प्रौद्योगिकियां हैं। Nuget और .csproj फ़ाइलें। यदि आप Git (और जैसे GitFlow) का उपयोग करके 5+ टीम में काम करते हैं तो यह कुल दुःस्वप्न है। "ओह बकवास अगर फ़ाइल को .csproj में शामिल करना भूल गया" थकाऊ हो रहा है। टूलिंग को इसे ठीक करना चाहिए, टूलिंग को मुझे यह भी चेतावनी देनी चाहिए कि मेरे पास परस्पर विरोधी डीएलएल संस्करण हैं, टूलिंग को विलय के साथ मेरी मदद करनी चाहिए।

बकवास काटो। Project.json पहले अच्छा लगा, लेकिन फिर राजनीति और भावनाएँ हुईं।

एमएस टीम को इसे बीटा कहना चाहिए, आरसी नहीं।
ऐसा लगता है कि जब आरटीएम जारी किया जाएगा तब भी मैं भरोसा नहीं कर सकता, 'यदि संभव हो तो एमएस टीम आरटीएम 2 को शिप करने का फैसला करती है जिसने सब कुछ फिर से तोड़ दिया।
मैं निराशावादी नहीं हूं लेकिन .NET Core के आसपास यह आंदोलन बहुत अजीब है।

@neoKushan मैं कोशिश करूंगा और नागरिक तीखा हमला नहीं करूंगा। उस ने कहा, मुझे विश्वास नहीं है कि कोई एमएसबिल्ड विकल्प अच्छा है, और मुझे यह भी विश्वास नहीं है कि एक्सएमएल एक अच्छा विकल्प है।

मैं चर्चा की शर्तों से सहमत नहीं हूं जहां मुझे चर्चा में प्रवेश करने के लिए अपने पदों को छोड़ना होगा। मैं सुनता रहता हूं कि हम में से जो लोग project.json के लिए हैं उन्हें मूल रूप से ठीक वही स्वीकार करना चाहिए जो MS ने तय किया है, शायद एक मामूली संशोधन या दो के साथ।

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

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

शायद ही कोई क्रांतिकारी अनुरोध।

मेरे 2 सेंट:

मेरा मानना ​​है कि इस बदलाव पर दो तरह के लोग चर्चा कर रहे हैं:

डेवलपर्स जो विभिन्न प्रकार की परियोजनाओं के निर्माण के लिए वीएस और .NET का उपयोग कर रहे हैं और उन्हें लंबे समय तक उन परियोजनाओं का समर्थन करना है
डेवलपर्स जिनके पास ऐसा सामान नहीं है और वे नए, स्वच्छ और फैंसी, क्रॉस प्लेटफॉर्म ASP.NET कोर फ्रेमवर्क चाहते हैं
व्यक्तिगत रूप से, मैं पहली श्रेणी में हूं इसलिए मैं चाहता हूं कि नया ASP.NET कोर जितना संभव हो सके अन्य VS प्रोजेक्ट प्रकारों के साथ संगत हो, और "पुराने" csproj/msbuild समाधान पर जाना मेरे लिए एक जीत है (+ my टीम और शायद कई अन्य डेवलपर्स)। इस तरह संक्रमण बहुत आसान और स्पष्ट होगा। हो सकता है कि दूसरी श्रेणी के लोग मुझसे सहमत न हों (या वे परवाह नहीं करते)।

एकमात्र बड़ी समस्या जो मैं अब देख रहा हूं वह यह है कि कैसे NuGet संकुल को परिभाषित और संदर्भित किया जाता है। package.config और csproj दोनों फाइलों को बनाए रखना एक दर्द है (जैसा कि @cwe1ss की तरह किया जाना चाहिए)। यह इस विषय में सबसे रचनात्मक टिप्पणियों में से एक था बीटीडब्ल्यू ...

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

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

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

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

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

एक अन्य संभावित समाधान एक अधिक प्लग करने योग्य बिल्ड सिस्टम है, लेकिन यह एक दीर्घकालिक समाधान है और वर्तमान बातचीत में मदद नहीं करता है। मूल रूप से, या तो/या/3-पक्ष को अनुमति दें।

प्रोजेक्ट निर्भरता के बारे में, हमारे पास पहले से ही बहुत सारे पैकेज हैं। कॉन्फिग फाइलें इधर-उधर तैर रही हैं, उन्हें पैकेज में पोर्ट करना।json/nuget.json कोई बड़ी बात नहीं है। निर्भरता के लिए भंडारण प्रारूप के मुकाबले मेरे पास असंगत असेंबली बाध्यकारी रीडायरेक्ट के साथ और अधिक समस्या है।

@shederman आपने MSBuild पर अपनी राय बहुत प्रसिद्ध कर दी है, लेकिन आपने जो स्पष्ट नहीं किया है वह MSBuild के साथ आपका वास्तविक _issue_ है। यही वह है जो मुझे बहुत निराशाजनक लग रहा है, मैं सिर्फ एमएसबिल्ड के साथ आपके सामने आने वाली वास्तविक समस्याओं को जानना चाहता हूं क्योंकि मुझे वास्तव में लगता है कि उन्हें संबोधित किया जा सकता है।

ठीक है तो आपको XML पसंद नहीं है, ठीक है - JSON और XML के बीच की बहस कोई नई बात नहीं है और हम इसे यहां कभी भी हल नहीं करेंगे। हालांकि, यह _only_ कारण नहीं हो सकता है जिससे आप MSBuild से बहुत नफरत करते हैं। आपने जिन वास्तविक समस्याओं का सामना किया है वे क्या हैं?

कारण मैं पूछता हूं - और कारण मैं पूछता रहता हूं कि ये वही समस्याएं हैं जिन्हें माइक्रोसॉफ्ट ठीक करना चाहता है और जब तक हम यह स्पष्ट नहीं करते कि समस्याएं क्या हैं, वे ठीक नहीं होंगे। MSBuild के बारे में जिन चीजों से हमें नफरत थी उनमें से कई पहले से ही तय की जा रही हैं जिनके बारे में हम जानते हैं:

1. परियोजना में प्रत्येक फ़ाइल की सूची - हटाया/निश्चित किया जा रहा है (वास्तव में एक वीएस मुद्दा)
2. नरक में विलय - ज्यादातर मामलों में 1. द्वारा निश्चित
3. अनावश्यक जटिलता/शब्दकोश - उम्मीद है कि https://github.com/dotnet/roslyn-project-system/issues/40 द्वारा हल किया जा रहा है
4. आसानी से हाथ से संपादित नहीं किया जा सकता - फिर से, 1 और 3 द्वारा तय किया गया।

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

इस पर मेरा 2 प्रतिशत:
इस तरह का बदलाव अभी क्यों हो रहा है? रोडमैप के मुताबिक फाइनल रिलीज होने में सिर्फ 1 महीना बचा है।
जब मैंने पहली बार इसे देखा तो मुझे लगा कि यह एक मजाक है। लेकिन दुख की बात है कि ऐसा नहीं है।
यह समाज के चेहरों पर एक बड़ा तमाचा है। इस तरह के निर्णय को अपनाने से पहले लंबी बातचीत होनी चाहिए, बाद में नहीं।

@laskoviymishka (और कुछ अन्य) जैसा कि @neoKushan द्वारा यहां नोट किया गया है, यह परिवर्तन _not_ हो रहा है, यह एक पोस्ट RTM परिवर्तन होगा (यहां तक ​​कि RTM चरणों में होगा)। तो "आखिरी मिनट में बदलाव क्यों" की सारी बातें एक भ्रांतिपूर्ण तर्क है, यह देखने के लिए _is_ समय है कि चीजें कैसे विकसित होंगी।

@laskoviymishka आरटीएम से पहले परिवर्तन

आरटीएम अभी भी प्रोजेक्ट.जेसन का उपयोग करेगा जैसे आज इसका उपयोग किया जाता है (मेरा मानना ​​​​है कि आरसी 2 के लिए स्कीमा बदल रहा है लेकिन यह परवाह किए बिना हो रहा था)। एक "नए" csproj में स्थानांतरण RTM के बाद होने वाला है और यह धीरे-धीरे किया जाएगा। आरटीएम में कुछ भी नहीं बदलता है (सिवाय xproj का नाम बदल दिया जाता है)।

@CodingGorilla यह RC2 है, जिसे एक महीने में 1.0 संस्करण में स्थानांतरित किया जाएगा। वास्तविक दुनिया में इसका मतलब है कि आप सब कुछ विकसित करना बंद कर देते हैं और स्थिरीकरण पर ध्यान केंद्रित करते हैं। यह परिवर्तन वास्तव में कुछ भी स्थिर नहीं है।

@neoKushan अगर यह आरटीएम के बाद होगा, तो इसके बारे में

IMHO इस कदम को project.json से project.csproj तक अपनाने से पहले इस पर चर्चा की जानी चाहिए। अभी यह अच्छा निर्णय नहीं है, कम से कम मेरे लिए।

@laskoviymishka समुदाय से स्टैंड अप नोट्स : (जोर जोड़ा गया)

RC2 / Preview 1 में कोई बदलाव नहीं होगा । RTM/पूर्वावलोकन 2 में, _केवल परिवर्तन आप देखेंगे कि क्या xproj फ़ाइलों का नाम बदलकर Visual Studio द्वारा csproj_ कर दिया जाएगा। उस समय से, project.json csproj के बगल में रहेगा। तब टीम project.json से csproj फ़ाइल में सुविधाओं को माइग्रेट करना शुरू करेगी। यह संभव है कि project.json फ़ाइल बनी रहे, और इसमें NuGet के सभी पैकेज संदर्भ हों और इसका नाम बदलकर nuget.json कर दिया जाए। टीम ने पहले से ही कुछ काम का परीक्षण किया है जो दिखाता है कि आपको अपनी प्रोजेक्ट फ़ाइल में सभी फाइलों को सूचीबद्ध करने की आवश्यकता नहीं होगी, जो प्रोजेक्ट.जेसन मॉडल के प्रमुख लाभों में से एक है।

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

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

माइक्रोसॉफ्ट, या कम से कम एएसपीनेट टीम ने इस पर प्रतिक्रिया मांगी है और इसमें कोई संदेह नहीं है कि वे इन धागे को पढ़ रहे हैं, लेकिन शायद हम जो याद कर रहे हैं वह माइक्रोसॉफ्ट से एक निश्चित बुलेटिन या पोस्ट है "यदि आप इस पर चर्चा करना चाहते हैं, इसे _यहाँ_" करें। हालांकि, मुझे लगता है कि लोगों के विचार से संक्रमण बहुत पहले है। अब तक वे केवल एक ही चीज़ जानते हैं कि वे निश्चित रूप से xproj का नाम बदलकर csproj कर रहे हैं।

मैं व्यक्तिगत रूप से महसूस करता हूं कि हालांकि यह करने के लिए एक बकवास परिवर्तन है, मैं इसे करने के उनके कारणों को समझता हूं। मेरे पास इससे बेहतर उत्तर नहीं है, इसलिए मेरा मानना ​​है कि अगर हमें csproj शैली की परियोजनाओं से निपटना है, तो हम इस अवधि का लाभ उठाकर csproj का सबसे अच्छा _kind_ पेश कर सकते हैं जो हम कर सकते हैं। यह project.json नहीं होगा, लेकिन अगर हम दोनों दुनिया के सर्वश्रेष्ठ प्राप्त कर सकते हैं तो लंबे समय में, हम सभी बेहतर होंगे। हर कोई सहमत नहीं है और यह ठीक है।

@neoKushan यह एक अच्छी बात है, आशा है कि MS इसे देखेगा। कोर टीम से कोई प्रतिक्रिया देखना वाकई अच्छा होगा।

@CodingGorilla अच्छी तरह से अभी भी अंतिम संस्करण में बदलाव है, जो टूट रहा है। इस तरह के बदलाव का मुख्य मुद्दा यह है कि कोर टीम को बिना कुछ लिए बहुत समय बिताना पड़ता है। यह शायद प्रबंधकों का मुद्दा है। आइए एक काम करने वाली चीज़ को दूसरी शायद काम करने वाली चीज़ में बदलने के लिए बहुत सारे देव घंटे बिताएँ। बिना किसी वास्तविक अच्छे कारण के।

@neoकुशन

आइए वास्तव में MSBuild के साथ समस्याओं पर चर्चा करें

मुझे राय बनाने के लिए पर्याप्त जानकारी खोजने में मुश्किल हो रही है। बहुत सारे बदलाव थे जिन्हें _seem_ को project.json और .csproj फ़ाइलों को छोड़ने से सक्षम किया जाना था। मैं नहीं चाहता कि ये सुधार चले जाएं, लेकिन मुझे नहीं पता कि "नए और बेहतर" एमएसबिल्ड में जाने से मेरा वर्कफ़्लो कैसे बदल जाएगा:

• वर्तमान में, हम प्रत्येक निर्माण कार्य के लिए गल्प का उपयोग करते हैं। क्या यह बदलता है? मेरा gulpfile वास्तव में .cs फ़ाइलों के संग्रह को असेंबली में बदलने के लिए केवल डीएनयू या डॉटनेट-क्ली को निष्पादित करता है। मैं इसे रख सकता हूँ, है ना?
• क्या वीएस कार्य एक्सप्लोरर का समर्थन करना जारी रखेगा, और मेरे गल्प कार्यों के लिए आफ्टरबिल्ड/प्रीबिल्ड/आदि ट्रिगर करेगा, ताकि वीएस उपयोगकर्ता चलाने के लिए F5 कर सकें? या क्या मुझे एमएसबिल्ड किक ऑफ गल्प करना है जिसका अर्थ है कि मेरे सभी गल्प कार्यों को रैपर एमएसबिल्ड कार्यों को परिभाषित करने की आवश्यकता है? (आउच)
• क्या msbuild एक अलग इंस्टाल में है? क्या इसे डॉटनेट क्ली या रनटाइम से अलग से संस्करणित किया जाएगा? यह मेरे सीआई बिल्ड सर्वर पर उपलब्ध होने वाले न्यूनतम को कैसे बदलता है? एक देव वातावरण पर स्थापित करने के लिए न्यूनतम?
• यदि मैं nuget निर्भरता या .cs फ़ाइलें जोड़ने के लिए टेक्स्ट संपादक का उपयोग कर रहा हूं, तो मुझे अब कौन से अतिरिक्त चरण जोड़ने होंगे, यदि कोई हों?
• जब मैं एक बदलाव की समीक्षा कर रहा हूं जहां एक वीएस उपयोगकर्ता ने एक nuget निर्भरता और एक .cs फ़ाइल जोड़ा है, तो क्या csproj परिवर्तन सरल और मानव-पठनीय होंगे? (तुलना के लिए, .net 4.6 और VS2015 के साथ, मेरी राय है कि csproj में परिवर्तन _not_ आसानी से मानव-पठनीय हैं।)

मैं उन लोगों को देखना चाहता हूं जो यह परिवर्तन कर रहे हैं उन परिदृश्यों के लिए पहुंचें जिन पर उन्हें विचार करने की आवश्यकता है (जैसे मेरा!), और इनके आसपास होने वाली चर्चा। मुझे आशा है कि "अरे हम आपके पनीर को बिना किसी चर्चा के आगे बढ़ा रहे हैं" इस तरह की चीज .net कोर का एसओपी नहीं बनती है।

वह टूलींग कमोबेश आपके लिए काम करेगा

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

"आरटीएम में आपका स्वागत है। यह एक अनुस्मारक है कि आपकी प्रोजेक्ट फ़ाइल बहुत निकट भविष्य में कभी-कभी बदल जाएगी। हमने पहले ही यह तय कर लिया है। कारण, लेकिन अधिकतर हम कर्ली से बेहतर कोण पसंद करते हैं ओह और टूल बनाएं, हाँ, बिल्ड करें टूल्स। हमने अंतिम स्कीमा निर्धारित नहीं किया है (लेकिन यह एक्सएमएल-आधारित होगा, ऊपर देखें), और फ़ाइल का नाम निश्चित रूप से .csproj के साथ समाप्त हो जाएगा ताकि किसी भी लीगेसी टूलिंग में अधिकतम मात्रा में भ्रम हो। चुस्त। (पीएस यदि आप एक उपकरण विक्रेता हैं: :o)"

@Oceanswave सुंदर उदाहरण है कि आपको अपने सॉफ़्टवेयर विकास का प्रबंधन कैसे नहीं करना चाहिए

@neoकुशन

लेकिन जो आपने स्पष्ट नहीं किया है वह MSBuild के साथ आपका वास्तविक मुद्दा है

हो सकता है कि आपको मेरे इसी प्रश्न के पिछले उत्तर को आप से पढ़ना चाहिए? https://github.com/aspnet/Home/issues/1433#issuecomment -218993559

मैंने MSBuild फ़ाइलों को ठीक करने, विकसित करने और डीबग करने के वर्षों में सैकड़ों घंटे बर्बाद किए हैं। मैंने टीम बिल्ड किया है, मैंने पाइपलाइनों का बहुत बड़ा निर्माण और परिनियोजन किया है। मैंने घंटों बिताए हैं वर्बोज़ लॉग पर घंटों तक यह पता लगाने की कोशिश कर रहा हूं कि नरक कुछ अजीब स्थिति क्यों हो रही है। मैंने इस तकनीक पर वर्षों से अपने बकाया का भुगतान किया है, और मैं व्यक्तिगत रूप से इससे कोई लेना-देना नहीं चाहता। project.json ताजी हवा की सांस थी। MSBuild के साथ वर्षों के कष्ट के बाद, हमें अंततः यह आभास हुआ कि MS को यह मिल गया है, कि एक बदलाव की आवश्यकता है और इसे लागू किया जा रहा है।

और यह गौरवशाली था। सरल बिल्ड, सरल संपादन, त्वरित और समझने में आसान आउटपुट। इसने MSBuild लिपियों में शपथ ग्रहण के उन घंटों की स्मृति को धो डाला। ऐसा लगा कि हम अंत में अतीत की लाश से खुद को अलग कर रहे हैं। लेकिन नहीं, अब हम उस लाश से बंधे हैं जिससे हम बहुत नफरत करते हैं, इस वादे के बावजूद कि ऐसा नहीं होगा।

बिना चर्चा के, बिना समीक्षा के, बिना किसी तरह के जुड़ाव के।

तथ्य यह है कि आप यह भी नहीं जानते हैं कि कुछ तिमाहियों में MSBuild से कितनी नफरत है, यह केवल

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

मेरी टीमों में, हम C# डेवलपर्स के साथ काम कर रहे हैं। वे दबाव में हैं, तंग समय सीमा, उच्च तनाव। वे ऐसा कुछ भी नहीं चाहते हैं जो उनके रास्ते में आए या उन्हें देरी हो।

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

मैं पिछले 5 वर्षों या उससे अधिक समय में एक भी सी # डेवलपर से नहीं मिला हूं जो उत्साहित है, या एमएसबिल्ड के साथ काम करने का आनंद लेता है। पिछले कुछ दिनों में जीथब पर कुछ टिप्पणियों को देखें। मैं एमएसबिल्ड के नापसंद में अकेला नहीं हूं। MSBuild को एक दशक से .NET डेवलपर की गर्दन के चारों ओर एक चक्की के रूप में माना जाता रहा है। क्या उस धारणा का अधिकांश भाग अनुचित है? हाँ, शायद।

लेकिन तो क्या? सॉफ्टवेयर इंजीनियरिंग के प्रमुख के रूप में मेरे दृष्टिकोण से, मुझे ऐसे उपकरणों की आवश्यकता है जो मेरे इच्छित परिणाम उत्पन्न करें। मुझे एमएसबिल्ड के साथ वे परिणाम नहीं मिलते हैं। मैं उन परिणामों को project.json + gulp.js + powerhell से प्राप्त करता हूं।

_Can_ MSBuild मुझे वे परिणाम दिलाएगा? निश्चित रूप से यह कर सकता है, लेकिन केवल तभी जब डेवलपर्स एमएसबिल्ड में उन परिणामों को प्राप्त करने के लिए काम करते हैं। और वे बस नहीं करते हैं। जब हम उन्हें मजबूर करते हैं, तो वे ऐसा करते हैं, और फिर इसे बनाए नहीं रखते।

मैं ऐसे टूल पर भरोसा नहीं कर सकता जिससे देव नफरत करते हैं। यही सरल वास्तविकता है। और यह देखते हुए कि मैंने स्वयं इसका उपयोग न करके कितना प्यार किया है, मैं वास्तव में उन्हें दोष नहीं दे सकता।

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

अच्छा, तो क्या किया जा सकता है?

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

मुझे नहीं पता कि यह कैसे ठीक हो सकता है, मैं वास्तव में नहीं करता। मुझे लगता है कि कुछ बड़े क्लीन ब्रेक होने चाहिए। जो कुछ है उसे तोड़े बिना आप उन्हें कैसे बनाते हैं? बहुत कम है, बहुत देर हो चुकी है। इसलिए मुझे MSBuild के साथ आगे का रास्ता नहीं दिख रहा है, मेरे लिए नहीं, मेरे लिए काम करने वाले देवों के लिए नहीं, मेरे भागीदारों के साथ नहीं, या _them_ के लिए काम करने वाली टीमों के लिए नहीं, न कि उन ग्राहकों के लिए जिनसे हम परामर्श करते हैं। उन दर्शकों में से कोई भी एमएसबिल्ड का उपयोग नहीं करना चाहता है, वे इसे टूलींग में उपयोग करते हैं क्योंकि उन्हें करना है, और वे बार-बार इसके बारे में कसम खाता है। आम तौर पर मर्ज समय के आसपास।

तो _now_ आप मर्ज को बेहतर बनाना चाहते हैं? 10 साल पर। उपकरण के बाद कई तिमाहियों में एक शपथ है?

मूल रूप से आप 90 के दशक के उत्तरार्ध में बिल्ड मास्टर्स के लिए डिज़ाइन किए गए टूल का उपयोग कर रहे हैं जिसका उपयोग वास्तव में डेवलपर्स द्वारा 2010 के बाद अपने दांत काटने के लिए किया जा रहा है। इसके तर्क के लिए अनुमान का उपयोग करने वाला उपकरण डेवलपर्स द्वारा अनिवार्य कार्य और अनिवार्य टूल के लिए उपयोग किया जा रहा है। एक उपकरण जो डेवलपर्स द्वारा उपयोग किए जा रहे गुणों को सेट करने का एक बहुत ही लचीला, लेकिन स्पष्ट तरीका नहीं है, जो सोचते हैं कि एक संपत्ति सेट एक साधारण असाइनमेंट ऑपरेटर है और समझ में नहीं आता कि आप PropertyGroup क्यों करना चाहते हैं और डॉन पता लगाने की परवाह नहीं है।

यही वह चर्चा है जो मैं करना चाहता हूं।

ज़रूर, मैं समझ गया। मैं जो चर्चा करना चाहता हूं वह अलग है, हालांकि, यह "हमें वह दें जो आपने हमसे वादा किया था, या हम इसे खुद को दे दें, क्योंकि हमें आपका पुराना विचार पसंद नहीं है, और हम वही करते हैं जो वादा किया गया था"।

क्या मैं कुछ दुख की बात साझा कर सकता हूँ? मेरे व्यापार भागीदारों में से, जिनके पास मेरे लिए समान लंबाई का अनुभव है (वास्तव में), मैं दिन में सबसे अधिक समर्थक एमएसबिल्ड था। मैंने वास्तव में इसे _इस्तेमाल किया है। मैंने इसे सीखा। मैंने बड़ी पाइपलाइनें बनाईं। लेकिन वह 5 साल पहले था, और तब से पुल के नीचे बहुत पानी चला गया है।

यार मैं @shederman की टिप्पणियों और इतिहास को पढ़ते हुए खुद को

सोचो: विजुअल स्टूडियो एक्सटेंशन (.vsix)। कोई भी उन्हें छूना नहीं चाहता क्योंकि विरासत/पुरानी/अलग-अलग चीजों की तुलना में उनकी तुलना इन दिनों कितनी है। ठीक है, आपके पास कुछ डेवलपर हैं जो चाहते हैं, क्योंकि उन्होंने इसके रहस्यमय प्रणाली को सीखने में अपने बकाया का भुगतान किया है - ठीक MSBuild की तरह।

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

यदि यह "अधिक .NET- जैसा" था (और बेहतर एकीकरण w/VS था) तो मुझे लगता है कि हम सभी सहमत होंगे कि यह काम करने के लिए एक बेहतर उत्पाद और विचार करने के लिए आकर्षक प्रस्ताव होगा।

@ माइक-ईईई और @shederman माइक के बिंदु पर, इसके पुराने, पुरातन और "किसी और चीज के विपरीत (.NET) डेवलपर्स के साथ काम करना है ..."। लेकिन क्या यह मरम्मत से परे है? उन्होंने स्वीकार किया है कि इसमें कुछ समस्याएं हैं जिन्हें वे ठीक करना चाहते हैं, तो सवाल यह है: क्या इसे ठीक किया जा सकता है? मुझे लगता है कि मुझे @shederman प्रतिक्रिया पता है, मैं भी ज्यादातर उनके तर्क से सहमत हूं (मैं इस विषय से सहमत हूं कि सिस्टम बनाना और प्रोजेक्ट करना चिंताओं का एक अजीब मिश्रण है)।

फिर से, मेरे पास इस दौड़ में एक घोड़ा नहीं है, मुझे कोई फर्क नहीं पड़ता कि वे किस रास्ते पर जाना चाहते हैं। मुझे वास्तव में थम्स अप प्रतिक्रियाएं प्राप्त करना और खुद को बोलते हुए सुनना पसंद है (बातचीत में वास्तविक बौद्धिक रुचि के पक्ष के साथ: हंसना:)

मुझे वास्तव में थम्स अप प्रतिक्रियाएं प्राप्त करना और खुद को बोलते हुए सुनना पसंद है (बातचीत में वास्तविक बौद्धिक रुचि के पक्ष के साथ: हंसना:)

मदद करने में खुशी होगी! :मुस्कुराओ:

लेकिन क्या यह मरम्मत से परे है? क्या इसे ठीक किया जा सकता है?

निर्भर करता है कि आप किससे पूछते हैं, वास्तव में। उनके रेपो पर मुद्दों को लाना जैसा कि @shederman ने सुझाव दिया है कि यह कठिन और चुनौतीपूर्ण रहा है (और हाँ, मैंने अपने शब्दों को वहां सेंसर कर दिया :stuck_out_tongue:)। ऐसा लगता है कि वे अपने तरीके से सेट हैं। लेकिन, जैसा कि आप सॉफ्टवेयर की प्रकृति के साथ जानते हैं, पर्याप्त समय और प्रयास दिए जाने पर कुछ भी संभव है। :आँख मारना:

@PhilipRieck आप वास्तव में कुछ बेहतरीन प्रश्न पूछ रहे हैं! दुर्भाग्य से मेरे पास उन सभी के लिए निश्चित उत्तर नहीं हैं, लेकिन आइए देखें:

वर्तमान में, हम प्रत्येक निर्माण कार्य के लिए गल्प का उपयोग करते हैं। क्या यह बदलता है? मेरा gulpfile वास्तव में .cs फ़ाइलों के संग्रह को असेंबली में बदलने के लिए केवल डीएनयू या डॉटनेट-क्ली को निष्पादित करता है। मैं इसे रख सकता हूँ, है ना?

मुझे नहीं लगता कि _थिंक_ यह बदलेगा, मुझे 95% विश्वास है कि हम यहां जिस बारे में बात कर रहे हैं वह केवल प्रोजेक्ट _definition_ को प्रभावित करता है, न कि प्रोजेक्ट वास्तव में कैसे बनाया जाता है (कम से कम डॉटनेट बिल्ड को कॉल करने से परे)। डॉटनेट सीएलआई किसी बिंदु पर एमएसबिल्ड में कॉल कर सकता है लेकिन उस समय तक यह एक अंडर-द-हूड चीज है।

क्या msbuild एक अलग इंस्टाल में है? क्या इसे डॉटनेट क्ली या रनटाइम से अलग से संस्करणित किया जाएगा? यह मेरे सीआई बिल्ड सर्वर पर उपलब्ध होने वाले न्यूनतम को कैसे बदलता है? एक देव वातावरण पर स्थापित करने के लिए न्यूनतम?

मेरे पास इसका शून्य निश्चित उत्तर है, लेकिन मैं _कल्पना_ करूंगा कि एमएसबिल्ड डॉटनेट सीएलआई के हिस्से के रूप में पूरी तरह से अलग इंस्टॉल के रूप में आता है, भले ही आप पहले से ही एमएसबिल्ड पहले ही इंस्टॉल कर चुके हों (वीएस के साथ कहें)। हालांकि मेरी ओर से शुद्ध अटकलें। मुझे पता है कि इस पूरे ".net हर जगह" परियोजना का एक बड़ा लक्ष्य लोगों को विकसित करने के लिए कम से कम उपद्रव करना है। सचमुच उपयुक्त होना चाहिए-डॉटनेट-क्ली (या जो कुछ भी), डॉटनेट नया, डॉटनेट बिल्ड। प्रोजेक्ट बनाने के लिए आपको कभी भी एमएसबिल्ड में कॉल नहीं करना चाहिए, यह डॉटनेट-क्ली का काम है।

यदि मैं nuget निर्भरता या .cs फ़ाइलें जोड़ने के लिए टेक्स्ट संपादक का उपयोग कर रहा हूं, तो मुझे अब कौन से अतिरिक्त चरण जोड़ने होंगे, यदि कोई हों?

.cs फ़ाइलों के लिए, निश्चित रूप से आज की तरह और कुछ नहीं - एक बात जो वे बहुत स्पष्ट कर चुके हैं, वह यह है कि आपके प्रोजेक्ट में प्रत्येक .cs फ़ाइल को निर्दिष्ट करने के दिन हमारे पीछे हैं (हालाँकि यदि आप चाहें तो संभवतः आप अभी भी ऐसा कर सकते हैं) , आपको @ माइक-ईईई देख रहे हैं)। जहां तक ​​निर्भरता का सवाल है, निश्चित रूप से अल्पावधि (लघु अवधि के महीने) में, वे project.json में बने रहेंगे और ठीक पहले की तरह काम करेंगे। एक मौका है कि project.json nuget.json बन जाएगा और इसलिए नाम परिवर्तन के अलावा, कुछ भी नहीं बदलता है, लेकिन इसके लिए अन्य संभावनाएं हैं और यह उन मुख्य चीजों में से एक है जो Microsoft बहुत अनिश्चित है - अपनी आवाज दें इसके लिए अपनी पसंद के बारे में सुना जा सकता है।
(मेरी निजी पसंद कुछ ऐसा करने में सक्षम हो रही है.नुगेट.जेसन लेकिन वह सिर्फ मुझे स्पिटबॉल कर रहा है)।

जब मैं एक बदलाव की समीक्षा कर रहा हूं जहां एक वीएस उपयोगकर्ता ने एक nuget निर्भरता और एक .cs फ़ाइल जोड़ा है, तो क्या csproj परिवर्तन सरल और मानव-पठनीय होंगे? (तुलना के लिए, .net 4.6 और VS2015 के साथ, मेरी राय यह है कि csproj में परिवर्तन आसानी से मानव-पठनीय नहीं हैं।)

.cs फ़ाइल के लिए, csproj बिल्कुल नहीं बदलना चाहिए। नगेट निर्भरता के लिए - अच्छा सवाल, फिर से यह कुछ हद तक हवा में है। यह वास्तव में csproj को बदलने का कारण नहीं होना चाहिए, लेकिन इस समय बड़ा निर्णायक यह है कि अगर nuget को nuget.json में रहना चाहिए या यदि csproj में वह सामान होना चाहिए - और यदि वे अलग हैं, तो कोरल करना कितना मुश्किल होगा दो?

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

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

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

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

@shederman एमएसबिल्ड के साथ आपकी समस्या यह है कि एक बड़ी, जटिल प्रणाली में यह बड़ी और जटिल है ....

मैंने टीम बिल्ड के साथ भी काम किया है और मुझे इससे बिल्कुल नफरत भी है (पिंगिंग @ माइक-ईईई क्योंकि हम दोनों ने बात की है कि यह अनुभव कितना भयानक है), मुझे यह मिलता है लेकिन आप जो वर्णन कर रहे हैं वह पूरी तरह से अलग है परिदृश्य। MSbuild _can_ बड़ा और जटिल हो और डिफ़ॉल्ट रूप से VS इसे बड़ा और जटिल बनाता है - लेकिन यही बदल रहा है ।

नई csproj फ़ाइल बहुत छोटी होनी चाहिए, जिसका अर्थ है कि "डीबगिंग" को बहुत सरल किया जाना चाहिए। नहीं (या थोड़ा) क्रॉफ्ट। आप अभी भी जो भी _बिल्ड सिस्टम_ चाहते हैं उसका उपयोग कर सकते हैं, नरक आप एक .bat फ़ाइल को कॉल कर सकते हैं जो केवल *.csproj पर "डॉटनेट बिल्ड" को कॉल करती है और आपको वह आउटपुट मिलेगा जो आप आज की तरह चाहते हैं। डॉटनेट क्ली को एमएसबिल्ड से निपटने दें और आपको इसे छूना भी नहीं चाहिए।

@neoKushan नहीं धन्यवाद।

मुझे वह चाहिए जो वादा किया गया था, न कि उस पर लिपस्टिक जो हमें बताया गया था कि हम दूर जा रहे हैं।

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

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

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

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

@शेडरमैन

और यदि आप हमें वह नहीं देना चाहते हैं जिसका वादा किया गया था, तो आइए हम इसे अपने आप को दें।

वे आपको कुछ भी करने से नहीं रोक रहे हैं। आगे बढ़ो और इसे कांटा करो, कुछ भी आपको रोक

यह सब वहाँ पहले से ही है। यह सिर्फ रिफैक्टरिंग रखने का मामला होना चाहिए। मैं काम करूंगा, जैसा कि मैंने पहले कहा है।

तो इसे करें? फिर, कुछ भी आपको रोक नहीं रहा है।

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

वे परवाह भी क्यों करेंगे? यदि आप MSbuild या कुछ और का उपयोग करते हैं तो Microsoft को इससे क्या फर्क पड़ता है?

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

मुझे खेद है, लेकिन पुरानी तकनीक को लाइफ सपोर्ट पर रखना .NET कोर के डिजाइन लक्ष्यों में से एक नहीं है। यह है?

नहीं, लेकिन लोगों को उनकी पुरानी, ​​मौजूदा परियोजनाओं को .net कोर में पोर्ट करने में मदद करना एक लक्ष्य है। इसके अलावा, हम MSBuild के .net कोर संस्करण के बारे में बात कर रहे हैं, न कि पूरी तरह से विकसित डेस्कटॉप संस्करण के बारे में, एक अंतर है ।

आपकी एकमात्र समस्या यह है कि उन्होंने इसे एमएसबिल्ड कहने की हिम्मत की। अगर वे एक नई परियोजना शैली के साथ आए जो एक्सएमएल हुई, लेकिन उसे "कोरबिल्ड" या कुछ और कहा जाता था, तो आप कोई भी समझदार नहीं होंगे और आपको केवल "आई हेट एक्सएमएल!" पर जाना होगा।

आप Microsoft की अनुमति की प्रतीक्षा कर रहे हैं, तो आप इसे पहले ही प्राप्त कर चुके हैं

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

आपकी एकमात्र समस्या यह है कि उन्होंने इसे एमएसबिल्ड कहने की हिम्मत की

नहीं, कि वे _use_ MSBuild करना चाहते हैं। थोड़ा, लेकिन महत्वपूर्ण अंतर। नई परियोजना का नाम बदलें। जेसन बिल्ड सिस्टम और इसे एमएसबिल्ड कहते हैं और मैं इसे खुशी से इस्तेमाल करूंगा।

आप कोई भी समझदार नहीं होंगे और आपको केवल "मुझे एक्सएमएल से नफरत है!"

शायद

वैसे भी, हलकों में घूम रहे हैं।

सोने जा रहा हूँ।

मैं कहता हूं कि इसे स्टैंडअप के लिए छोड़ दें। कोई किसी को आश्वस्त नहीं कर रहा है। मुझे पूरा यकीन है कि मैं प्रो-एमएसबिल्ड पक्ष को समझता हूं, लेकिन मैं इससे सहमत नहीं हूं। और मुझे पूरा यकीन है कि प्रो-एमएसबिल्ड पक्ष एमएसबिल्ड पक्ष को समझता है, लेकिन इससे सहमत नहीं है।

मैं केवल इतना कह रहा हूं कि हमारे पास दोनों हो सकते हैं। एमएस टीम से बिना (या बहुत कम) अतिरिक्त प्रयास के लिए। फिर विकल्पों को वास्तविक उत्पादन उपयोग की चकाचौंध में डूबने या तैरने दें।

प्रति @neoKushan के प्रश्न:

क्या बाकि है?

मैं वास्तव में अपनी प्रतिक्रिया को फ्रेम करना चाहता हूं, यदि मैं कर सकता हूं, तो "सिद्धांतों" के आसपास मैंने wrt के ऊपर उल्लिखित किया है जो मुझे विश्वास है कि एक अच्छी, प्रयोग योग्य परियोजना फ़ाइल के लिए बनाता है:

• यह मानव संपादन योग्य/पठनीय होना चाहिए

ऊपर दिए गए @neoKushan के बयान का मतलब यह है कि इसे संबोधित किया जाएगा - मैं मान रहा हूं कि MSFT में किसी ने यह कहा/लिखा है। इसके साथ ही, मैं एक एमएसबिल्ड-आधारित प्रस्ताव देखना चाहता हूं जहां एमएसबिल्ड को "प्रतिबद्ध" (एक समुदाय/फ्रेमवर्क के रूप में) से पहले इसे वास्तव में पहले संबोधित किया जाता है।

मुझे लगता है कि ग्रिड प्रोजेक्ट टाइप से छुटकारा पाने के लिए शीर्ष वस्तुओं में से एक है?

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

• इसे टिप्पणियों की अनुमति देनी चाहिए

MSBuild में पहले से ही काम कर रहा है

• यह घोषणात्मक होना चाहिए

प्रथम-स्तर का क्रम बदलना (सीधे बच्चे) प्रोजेक्ट के पूरे अर्थ को बदल सकता है, अक्सर मुश्किल-से-डीबग तरीकों से। यह कहीं अधिक उल्लेखनीय नहीं है यदि आप दुर्घटना से .targets आयात को शीर्ष पर लाते हैं।

• यह स्वयं निहित होना चाहिए

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

यह मानव पठनीयता/संपादन योग्यता चिंता के समान है।

• इसे मर्ज संघर्षों को कम करने/विलय को सरल बनाने के लिए, यदि संभव हो तो डिजाइन किया जाना चाहिए

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

• यह पूरी तरह से दस्तावेज योग्य होना चाहिए (दस्तावेजीकरण पर लागू होने वाले स्व-रोकथाम सिद्धांत के साथ)

मेरा मानना ​​​​है कि एमएसबिल्ड के पास दस्तावेज है। वह दस्तावेज, विशेष रूप से एमएसबिल्ड के वीएस _flavor_ के लिए वांछित होने के लिए काफी कुछ छोड़ देता है। मैं अक्सर हैरान होता हूं कि वे जिस समूह में हैं, उसमें अलग-अलग चीजें क्यों हैं, और वीएस "मदद" उन्हें चारों ओर ले जाने में बहुत मददगार नहीं है।

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

(हां, मुझे पता है, मैं इस पर एक बग फाइल करने जा रहा हूं)

• यह उपकरण-स्वतंत्र होना चाहिए

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

एक बिल्ड डेफिनिशन फ़ाइल एक प्रोजेक्ट फ़ाइल स्वरूप नहीं है। वह वीएस इसे काम करने में कामयाब रहा (कुछ हद तक) इसका उपयोग जारी रखने के लिए अच्छा तर्क नहीं है। मुझे एक वास्तविक फ़ाइल चाहिए जो केवल परियोजना का प्रतिनिधित्व करती है, और इसके द्वारा उत्पन्न कलाकृतियों के बारे में जानकारी (निर्देश नहीं कि इसे कैसे बनाया जाए)। इसमें, project.json भी विफल हो जाता है क्योंकि यह हमें "commands" को परिभाषित करने की अनुमति देता है। वे क्यों मौजूद हैं? बस परिभाषित करें कि आउटपुट का प्रकार क्या है, और यह कहां पाया जा सकता है।

मैंने इस पूरे सूत्र को पढ़ा, और project.json बनाम project.csproj इस चर्चा में एक बात जो मेरे सामने अटक गई, वह यह है कि उन फ़ाइलनामों में से केवल एक में पूरी प्रोग्रामिंग भाषा बेक की गई है। मैं एफ # में एएसपी.नेट विकास करना पसंद करता हूं। क्या यह ASP.NET कोर में भी संभव है? इस बिंदु पर मेरे पास बेहोश विचार नहीं है, लेकिन मुझे लगता है कि यह नहीं है। मैं नहीं यकीन है कि भले ही लोग प्रयोग कर रहे हैं रहा हूँ csproj के लिए एक आशुलिपि के रूप में csproj, fsproj, vbproj या अगर वे वास्तव में मतलब csproj केवल।

अद्यतन: एफ # लोग कोरसीएलआर समर्थन पर काम कर रहे हैं, लेकिन अभी तक कोई वास्तविक ईटीए नहीं है। मेरा कहना यह है कि अभी जो भी परियोजना प्रणाली तय की गई है, वह उन प्रोग्रामिंग भाषाओं को प्रभावित करेगी जो अभी लोगों के रडार पर भी नहीं हैं। जितना मैं एक्सएमएल पर जेएसओएन पसंद करता हूं, अगर प्रोजेक्ट.जेसन मुझे सी # में लॉक करने जा रहा है (और संकलन में फ़ाइल-ऑर्डर एफ # में महत्वपूर्ण रूप से महत्वपूर्ण है) तो मैं इसके लिए नहीं हूं।

अभी के लिए, ऐसा लगता है कि यह मेरे लिए FAKE और Paket पर वापस आ गया है ...

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

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

आपके वास्तविक निर्माण प्रणाली को बदलने की आवश्यकता नहीं है। यदि आप नैन का उपयोग कर रहे हैं, तो नैन का उपयोग करते रहें। यदि आप psake का उपयोग कर रहे हैं, तो psake का उपयोग करते रहें। यदि आप पॉवरशेल स्क्रिप्ट का उपयोग कर रहे हैं, तो उसका उपयोग करते रहें। आदि! सबसे अधिक संभावना है, केवल "डॉटनेट बिल्ड" भाग को एमएसबिल्ड को कॉल के साथ बदलना होगा। (शायद यह भी आवश्यक नहीं होगा यदि डॉटनेट एमएसबिल्ड में कॉल करता है)

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

लेकिन निश्चित रूप से, जैसा कि मैंने पहले ही इस धागे की शुरुआत में कहा है, हमें निश्चित रूप से csproj के साथ बेहतर व्यवहार करने के लिए project.json और विजुअल स्टूडियो के कुछ _features_ की आवश्यकता है - और मुझे नहीं पता कि वे क्यों नहीं करेंगे उस पहुंचाने में सक्षम हो।

@jtmueller बिल्कुल कोई _technical_ कारण नहीं है कि आपको F # (या यदि आप इतने इच्छुक हैं तो VB.net) का उपयोग करने में सक्षम क्यों नहीं होना चाहिए। मुझे आश्चर्य नहीं होगा अगर एमएसबिल्ड परियोजना फाइलों में बदलाव का हिस्सा इसे सुविधाजनक बनाने में मदद करना है। डीएनएक्स इससे वास्तव में कभी खुश नहीं था, लेकिन कोरसीएलआर निश्चित रूप से एफ # का समर्थन करता है। मुझे नहीं पता कि आप F# कम RTM का उपयोग कर पाएंगे या नहीं, लेकिन यह निश्चित रूप से पाइपलाइन में है।

@jtmueller project.json निर्भरता मैनिफेस्ट, साथ ही कस्टम कमांड के साथ एक प्रोजेक्ट परिभाषा है। वहाँ कुछ भी एक विशिष्ट भाषा से बंधा नहीं है।

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

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

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

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

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

चरण दो यह है कि हमें एक बिल्ड सिस्टम की आवश्यकता है। हमें बहुत ही सरल उपयोग के मामलों के साथ-साथ अत्यधिक जटिल मामलों को भी संभालने की आवश्यकता है। लेकिन कोई नियम नहीं कहता है कि एक बिल्ड सिस्टम को _दोनों_ को संभालना होता है। मेरे दिमाग में, जो सबसे अधिक समझ में आता है वह एक सरल, हल्का निर्माण प्रणाली है जो मूल रूप से केवल परियोजना परिभाषा बनाता है। यह restore , build , test , और pack ।

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

लेकिन जबकि यह शायद 80% उपयोग के मामलों के लिए पर्याप्त है, यह अन्य 20% के लिए पर्याप्त नहीं है। उन्हें कुछ और चाहिए। (चेतावनी: उपयोग के मामलों के अनुपात पर राय भिन्न हो सकती है)।

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

मुझे खुशी है कि नई निर्माण प्रक्रिया एमएसबिल्ड को खोलने में सक्षम होनी चाहिए, लेकिन मुझे विश्वास नहीं है कि एमएसबिल्ड के रूप में कुछ (आईएमओ) पुराना, कठोर, और फूला हुआ भविष्य में सभी निर्माणों का आधार होना चाहिए।

वेब ढांचे जैसी चीजों के साथ, हम देखते हैं कि एमएस टीमें तेजी से पुनरावृत्ति कर रही हैं। क्योंकि उनके पास प्रतिस्पर्धा है। उदाहरण के लिए उन्हें नैन्सी की गर्दन नीचे सांस लेने की चिंता करनी होगी। किसी और चीज़ पर स्विच करना _आसान_ है। और यह इसके लिए MVC/WebAPI को बेहतर बनाता है।

MSBuild के पूरे .NET टूलिंग में बेक होने के साथ, किसी और चीज़ का उपयोग करना एक दर्द बन जाता है। प्रतियोगिता कहां है? और आप इसका प्रभाव MSBuild Github बोर्ड में देख सकते हैं। बस सभी बंद प्रस्तावों की समीक्षा करें। केवल यही कारण है कि वे इन "स्लिमिंग" परिवर्तनों के बारे में बात कर रहे हैं क्योंकि वे चाहते हैं कि लोग प्रोजेक्ट.जेसन से एमएसबिल्ड में स्थानांतरित हो जाएं।

यदि MSBuild को शुरू से .NET Core में बेक किया गया होता, तो मेरा मानना ​​है कि हम MSBuild टीम से अब जो आंदोलन देख रहे हैं, उसका _none_ देख रहे होंगे। लेकिन एक बार जब हम वापस लॉक हो जाते हैं तो क्या होता है? एक बार प्रतियोगिता को मूल रूप से बाहर कर दिया गया है? क्या होने जा रहा है? प्रतिस्पर्धा रहित परिदृश्यों में हमेशा क्या होता है, और अब तक के वर्षों में क्या हुआ है: बड़े पैमाने पर दलबदल को रोकने के लिए पर्याप्त सुधार, लेकिन विशेष रूप से दिलचस्प कुछ भी नहीं।

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

यह किसी भी ढांचे की सफलता का नुस्खा नहीं है।

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

इसे हर हाल में बनाए रखें, लेकिन सामने और केंद्र को सिस्टम के मूल में नहीं बनाया गया है।

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

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

चरण तीन यह है कि हम उस निर्माण प्रणाली के लिए एक्स्टेंसिबिलिटी के एक बहुत ही सरल रूप की अनुमति देते हैं।

एक प्रदाता-आधारित निर्माण प्रणाली/मॉडल ?! प्रतिभावान! मैं इस संदेश को स्वीकार करता हूं।

बीटीडब्ल्यू, अगर आप अपनी इच्छा प्राप्त करते हैं और अपने स्वयं के निर्माण प्रणाली तक पहुंच प्राप्त करते हैं, तो मेरा सुझाव है कि हम इसे कॉल करें ... बर्सरकर बिल्ड! "बेर्ज़रकर @shederman" के नाम पर ... आपके लिए मेरा नया उपनाम। :मुस्कुराओ:

@ माइक-ईईई बहुत उत्साहित न हों। किसी भी तरह से मैं इतना कठोर कुछ भी प्रस्तावित नहीं कर रहा हूं जितना कि _अभी तक।

अभी के लिए मुझे लगता है कि चरण तीन के लिए एमएसबिल्ड समर्थन के साथ यह केवल चरण एक और दो होना चाहिए।

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

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

क्या यह बातचीत करने के लिए यह सही जगह है

मुझे ऐसा नहीं लगता, नहीं। इसके अलावा, यह मत सोचो कि यह अभी सही समय है। क्या दिशाएं संभव हैं, यह देखने से पहले हमें इस मुद्दे को बंद करना होगा।

निडर निर्माण! "बेर्ज़रकर @shederman" के नाम पर ... आपके लिए मेरा नया उपनाम। :मुस्कुराओ:

सुनिश्चित नहीं है कि इसके बारे में कैसा महसूस करना है

निडर बनने की कोशिश नहीं कर रहा है। जब हम आगे बढ़ते हैं तो मैं पीछे नहीं हटना चाहता।

अरे दोस्तों, शायद पहिया को फिर से खोजने के बजाय ( nuget.json या इसे जो भी कहा जाएगा) आइए मौजूदा, समुदाय संचालित समाधान का उपयोग करें जो अधिकांश निर्भरता प्रबंधन समस्याओं को हल कर रहा है - Paket ।

1. इसमें सकर्मक निर्भरता की अवधारणा है
2. यह MsBuild . के साथ अच्छी तरह से एकीकृत है
3. इसमें निर्भरता को परिभाषित करने के लिए मानव पठनीय फ़ाइल स्वरूप है
4. इसमें packages.config से बहुत अच्छा माइग्रेशन पथ है
5. और कई अन्य विशेषताएं (लेकिन जाहिर तौर पर वे 4 सभी के लिए सबसे महत्वपूर्ण चीजें हैं, इसलिए मैं गिट निर्भरता या बेहतर पैकेज समाधान रणनीति जैसी चीजों का उल्लेख नहीं करूंगा)

@ Krzysztof-Cieslak याद रखें कि Microsoft MSbuild प्रोजेक्ट परिभाषाओं को आगे बढ़ाने का सबसे बड़ा कारण उन लोगों के प्रवास को आसान बनाने में मदद करना है जिन्होंने MSBuild में बहुत निवेश किया है। इस संबंध में, Paket project.json (या project.yaml या project.cs या जो भी हो) से बेहतर नहीं है।

ऐसा कहकर, मुझे अभी भी कोई कारण नहीं दिख रहा है कि आप जो भी निर्माण प्रणाली चाहते हैं उसका उपयोग क्यों नहीं कर सकते हैं। अंततः, "डॉटनेट बिल्ड" बदलने वाला नहीं है, भले ही आपकी प्रोजेक्ट परिभाषा किस प्रारूप में समाप्त हो, डॉटनेट बिल्ड अभी भी आपका आउटपुट उत्पन्न करेगा।

@neoKushan हां, लेकिन क्या "

@shederman इसमें कोई संदेह नहीं है कि " एमएसबिल्ड का उपयोग करेगा, लेकिन हम वास्तव में इनमें से कोई भी हवा में बहुत अधिक देखते हैं या नहीं। वर्तमान में, आज, आपको अपनी परियोजनाओं को ठीक से बनाने के लिए एक project.json की आवश्यकता है, यदि संदर्भ के लिए नहीं तो अन्य महत्वपूर्ण डेटा (जैसे लक्ष्य ढांचे) के लिए। आखिरकार उनमें से कुछ (या सभी) एक csproj फ़ाइल में माइग्रेट करने जा रहे हैं, इसलिए कोई यह मानता है कि डॉटनेट बिल्ड के काम करने के लिए आपको उस .csproj की आवश्यकता होगी, इससे कोई फर्क नहीं पड़ता कि यह अंततः पृष्ठभूमि में क्या उपयोग करता है। हालाँकि, यह वास्तव में आप पर कितना प्रभाव डालता है, यह देखना बाकी है।

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

लेकिन अगर यह काम करने वाला है, तो csproj को project.json जैसे RichiCoder ने सुझाव दिया है , को शामिल करना होगा।

इस तरह "कोर बिल्ड" और "एमएसबिल्ड" एक साथ काम कर सकते हैं, या कोर बिल्ड एमएसबिल्ड के बिना काम कर सकते हैं। और, जाहिर है, अगर आप project.json आयात नहीं करते हैं, तो आप csproj में भी अपने प्रोजेक्ट गुणों को परिभाषित कर सकते हैं।

वास्तव में काफी आसान बदलाव। मेरे सिर के ऊपर से हमें चाहिए:

• मौजूदा डॉटनेट-बिल्ड कोड रखें और इसे कुछ निश्चित (निर्धारित करने के लिए) परिस्थितियों में चलाएं।
• डॉटनेट कोर टीमों की योजना के अनुसार दूसरों में इसने एमएसबिल्ड चलाया है
• क्या वीएस प्रोजेक्ट गुणों के लिए प्रोजेक्ट.जेसन या एमएसबिल्ड को पढ़ने में सक्षम है
• MSBuild में project.json आयात करने की क्षमता जोड़ें

काफी कम मात्रा में काम, और यह Microsoft को अपने "MSBuild हमेशा के लिए" पथ को जारी रखने की अनुमति देता है, और यह .NET कोर समुदाय से किए गए वादों को पूरा करता है, और यह हममें से उन लोगों को अनुमति देता है जो ऐसा करने के लिए MSBuild से बाहर निकलना चाहते हैं।

यह उल्लेखनीय है कि एएसपीनेट सदस्यता से किसी ने भी यहां कुछ नहीं कहा है।

इस बीच, मैंने ASP.NET कम्युनिटी स्टैंडअप - 10 मई, 2016 के कुछ

@rhires मेरी समझ से "नया"

मुझे आपका प्रोजेक्ट.जेसन विचार पसंद है। बस RC2 परिवर्तनों के माध्यम से जा रहा था, और उन्होंने "टेस्टरनर" में डाल दिया, इसलिए ऐसा कोई कारण नहीं है जो नहीं किया जा सकता है। _BUT_, ऐसा प्रतीत होता है कि उनका दिल पूरी तरह से project.json को पूरी तरह से हटाने और MSBuild-प्रथम दुनिया में वापस जाने के लिए पूरी तरह से तैयार है।

एमएस क्यों नहीं कर सका (प्रसिद्ध अंतिम शब्द) "बस" टूलिंग के माध्यम से जेसन फाइलों में टिप्पणियों की अनुमति दें

ऐसा कोई कारण नहीं है कि वे नहीं कर सके। JSON.Net, जिस पुस्तकालय का वे उपयोग करते हैं, वह टिप्पणियों का समर्थन करता है।

वास्तव में, यदि आप चाहते हैं/उस मार्ग पर जाने की आवश्यकता है, तो project.json में केवल एक {"BuildSystem" : "MSBuild" } आइटम शामिल होना चाहिए।

मैं क्यों चाहता हूं कि मेरी परियोजना अपने स्वयं के निर्माण प्रणाली को निर्देशित करे? निश्चित रूप से बिल्ड सिस्टम प्रोजेक्ट बनाता है, न कि दूसरी तरफ?

@neoकुशन :

याद रखें कि माइक्रोसॉफ्ट एमएसबिल्ड परियोजना परिभाषाओं को आगे बढ़ाने का सबसे बड़ा कारण उन लोगों के प्रवासन को आसान बनाने में मदद करना है जिन्होंने एमएसबिल्ड में बहुत निवेश किया है। इस संबंध में, Paket project.json (या project.yaml या project.cs या जो भी हो) से बेहतर नहीं है।

Paket नई बिल्ड सिस्टम नहीं है, यह निर्भरता प्रबंधक है जो MsBuild के साथ 100% संगत है। यह सिर्फ packages.config समस्या हल करता है।

@ Krzysztof-Cieslak मैंने कभी दावा नहीं किया कि यह एक निर्माण प्रणाली थी और निर्भरता प्रबंधन वास्तव में .net कोर के साथ एक बड़ी समस्या नहीं है (जहां तक ​​​​मुझे पता है, कम से कम)। .net कोर packages.config का उपयोग नहीं करता यह project.json का उपयोग करता है।

अगर नेट कोर अभी भी project.json का उपयोग करने की योजना बना रहा था तो हमारे पास यह 100 पोस्ट चर्चा नहीं होगी। ;) मैं केवल इतना कह रहा हूं कि कई जगहों पर सुझाव दिया गया है कि निर्भरता को संभालने के लिए "nuget.json" का उपयोग करने का समाधान पहिया को फिर से शुरू करना है क्योंकि हमारे पास उत्पाद है जो बिल्कुल वैसा ही है।

@शेडरमैन

"अंतिम सर्वेक्षण परिणाम: 9 मिलियन .NET डेवलपर आबादी के लिए 100 प्रतिक्रियाएं, जो 95% विश्वास के साथ ± 10% है।"

हां और एक सम्मेलन में बिल्ली के खिलौनों के बारे में पूछना जो कि पसंदीदा पालतू कुत्ता या बिल्ली है, आपको समान परिणाम दे सकता है।

@darrelmiller

"मुझे लगता है कि एमएसबिल्ड और विजुअल स्टूडियो वर्तमान में एमएसबिल्ड का उपयोग करने के तरीके के बीच अंतर करना महत्वपूर्ण है। मैं वर्षों से एमएसबिल्ड फाइलों को संपादित कर रहा हूं और मेरी सभी परियोजनाओं के लिए उनका उपयोग कर रहा हूं। उदाहरण के लिए https://github.com/tavis- software/Tavis.home/blob/master/build/Build.proj "

क्या हम प्रोजेक्ट फाइलों के शीर्ष पर वीएस विशिष्ट बिल्ड फाइलों पर चर्चा करेंगे जहां एमएसबिल्ड कमांड लाइन से काम नहीं करता है?

@gregoryyoung हमें चाहिए। मैंने ऐसी फाइलें बनाई हैं जो पहले डेवेनव पर निर्भर करती हैं, लेकिन उन लोगों को नहीं देखा है जो कमांड लाइन से नहीं चलेंगे। कोई उदाहरण?

@gregoryyoung

हां और एक सम्मेलन में बिल्ली के खिलौनों के बारे में पूछना जो कि पसंदीदा पालतू कुत्ता या बिल्ली है, आपको समान परिणाम दे सकता है।

यह एक दिलचस्प सादृश्य है। के अलावा...

मैंने उन लोगों के ट्विटर फीड पर लिंक पोस्ट किया है जिन्होंने MSBuild में जाने का _supported_ किया है। तो, वास्तव में आपकी सादृश्यता बिल्कुल भी पसंद नहीं है।

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

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

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

सबूत के कई स्रोत एक ही बात कह रहे हैं। यदि आप अपने महत्वपूर्ण उपयोगकर्ताओं की राय को अनदेखा करना चाहते हैं, तो ऐसा कहें। उनके विरोध को दूर करने की कोशिश करना बंद करें जैसे कि आप अपनी राय रखने का अधिकार खो देते हैं यदि आप "गलत" रखते हैं।

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

मैंने सर्वेक्षण करने का कारण यह था कि यह पूरी तरह से स्पष्ट था कि माइक्रोसॉफ्ट के पास कोई सुराग नहीं था कि लोग क्या सोच रहे थे। अब जो बात एकदम साफ हो रही है, वह यह है कि लोग जो सोच रहे हैं, उसमें उनकी कोई दिलचस्पी नहीं है.

अपने आप से और अपने समुदाय के साथ बेईमानी करना बंद करें और इसे दूर करने के बजाय विपक्ष के साथ जुड़ें।

तथ्यों को बदलने की कोशिश करना बंद करें और तथ्यों के आधार पर अपना विचार बदलना शुरू करें।

@shederman मुझे यह आभास नहीं है कि Microsoft टीम ने वास्तव में इस सूत्र (आपके सर्वेक्षण सहित) का उत्तर दिया है। हां टीम के एक लड़के ने कहा कि वह इसे आपके जितना भरोसेमंद नहीं मान रहा था, लेकिन बस इतना ही। मुझे लगता है कि अभी भी उम्मीद है कि वे वर्तमान में जिस रास्ते पर जा रहे हैं, उसके भारी विरोध के बारे में बात कर रहे हैं और वे सही रास्ते पर चर्चा कर रहे हैं और जब वे और जानेंगे तो हमें जवाब देंगे।

मुझे लगता है कि हम इस टीम को कुछ श्रेय दे सकते हैं;)।

@gregoryyoung क्षमा करें, आपके द्वारा दी गई सादृश्य से, मुझे लगता है कि आप एक एमएस कर्मचारी थे, क्योंकि वे 2 दिनों के लिए एक ही अनुमानित रेखा को

@sandorfr

मुझे लगता है कि हम इस टीम को कुछ श्रेय दे सकते हैं

मैंने सोचा था कि हम कर सकते हैं, लेकिन पिछले कुछ दिनों में मेरे अनुभवों ने उस आशा को मजबूत नहीं किया है।

मुझे लगता है कि यह "टीम की" गलती नहीं है, बल्कि संगठन में कोई उच्च व्यक्ति है जिसने यह निर्णय लिया और इसे नीचे लगाया ... और फिर "टीम" को इसे चूसना और इसे सुंदर दिखाना होगा। बीटीडीटी। मज़ा नहीं।

आप सभी जानते हैं कि प्रोजेक्ट.जेसन पहले से ही गैर ASP.NET कोर अनुप्रयोगों के साथ इसे थोड़ा अधिक संगत बनाने के लिए बड़े बदलावों से

उस से "क्लासिक" csproj फ़ाइल में जाना वास्तव में मेरे लिए इतना दूर नहीं लगता है। और अगर csproj खुद भी उस अधिक लचीली दिशा में थोड़ा विकसित होता है जिसे हमने project.json से सीखा है, तो मैं वास्तव में "नया और बेहतर" csproj काम वास्तव में अच्छी तरह से देख सकता हूं। और मुझे लगता है कि हम सुरक्षित रूप से यह मान सकते हैं कि project.json में हाल के परिवर्तन _all_ प्रकार की .NET परियोजनाओं के लिए इसे प्रयोग करने योग्य बनाने के लिए अंतिम नहीं होंगे—मुझे लगता है कि यह महत्वपूर्ण है कि हम यह न भूलें कि वहाँ ASP.NET (कोर) के अलावा कई अन्य लक्ष्य हैं।

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

मुझे लगता है कि जब लोग project.json के बारे में सोचते हैं, तो वे ज्यादातर शुरुआती चरणों के बारे

तो, टीएल; डॉ: हाँ, मुझे वास्तव में project.json पसंद है और काश इसे ASP.NET कोर के लिए रखने का एक तरीका होता (उदाहरण के लिए एक विशेष MSBuild कार्य का उपयोग करना)। लेकिन साथ ही, मैं पूरी तरह से समझता हूं कि अब ऐसा क्यों हो रहा है, और मुझे लगता है कि यह वास्तव में कोई बुरी बात नहीं है जो वे करते हैं। बेशक समय थोड़ा अजीब है, लेकिन यह देखते हुए कि परिवर्तन ASP.NET कोर और .NET कोर रिलीज के समानांतर नहीं होगा, मुझे नहीं लगता कि समय एक वास्तविक मुद्दा है (यह मानते हुए कि बाद में संक्रमण सुचारू रूप से होगा) )

परियोजनाओं में स्रोत फ़ाइलों को साझा करने में सक्षम होने की आवश्यकता है

@darrelmiller यह मेरे लिए डरावना लगता है, क्योंकि ऐसा लगता है कि .csproj में लिस्टिंग फ़ाइलें वापस आ रही हैं।

@lokitoth यह मानते हुए कि csproj नए प्रोजेक्ट के रूप में फ़ाइल संदर्भों के लिए समान रूप से काम करेगा।

@shederman मैं एक एमएस कर्मचारी नहीं हूं, सिर्फ एक तर्कसंगत व्यक्ति हूं। यदि आप मुझे गूगल करते हैं तो मुझे यकीन है कि आप पा सकते हैं कि मंच में मेरी दीर्घकालिक रुचि है।

परिवर्तन से जुड़े कई पक्ष/विपक्ष हैं, लेकिन आपने जो प्रदान किया है वह किसी भी समझदार चर्चा के लिए उपयोगी नहीं है।

यह एक निराशाजनक परिवर्तन था जिसके बारे में सुनना था। project.json, स्वचालित फ़ाइल समावेशन/ग्लोबिंग, और ट्रांज़िटिव पुनर्स्थापना ASP.NET कोर के बारे में पहली चीजें थीं जिन्होंने मुझे "ओह, अच्छा!" शुरू में।

मुझे एहसास है कि यह सब दूर नहीं होगा (मुझे आशा है?) लेकिन एक्सएमएल प्रोजेक्ट फाइल पर वापस जाना बुरा लगता है, क्योंकि ऐतिहासिक रूप से इसका मतलब इंसानों के लिए सिरदर्द रहा है। मुझे किसी समस्या को ठीक करने के लिए एक csproj फ़ाइल खोलने से नफरत है क्योंकि यह मुश्किल-से-पार्स टेक्स्ट की दीवार है।

केवल मेरे दो सेंट्स।

@poke की पोस्ट में हुए बदलावों को जोंस में अनुवाद किया है, जो ईमानदारी से बहुत यक भी है।

इस तथ्य के आधार पर कि वे Compile, Embed, CopyToOutput, Exclude, Shared Files आदि विकल्पों का समर्थन करना चाहते हैं, तो वास्तव में json फॉर्मेट वैसे भी XML से बेहतर काम नहीं करने वाला था। मुझे यह भी संदेह है कि जेसन ने भारी बिल्ड स्क्रिप्ट अनुकूलन के लिए भी काम नहीं किया होगा।

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

@gregoryyoung जो आपने प्रदान किया है वह किसी भी समझदार चर्चा के लिए उपयोगी नहीं है

महान। ठीक है, देखते हैं, मैंने क्या प्रदान किया है:

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

क्या मैं पूछ सकता हूं, रुचि से, पागल हिस्सा क्या है? किसी की सोच पर सवाल उठाना आजकल तर्कसंगत नहीं है? या मैंने वहाँ कुछ छोड़ दिया?

मेरा मतलब है, मैं गुस्से में हूँ, मुझे गलत मत समझो। मैंने उस ढांचे के मूल वादे के इर्द-गिर्द बड़ी मात्रा में काम, समय और पैसा बर्बाद किया है, जिसे अंतिम समय में एक जल्दबाजी और खराब सोची समझी चाल के रूप में दूर कर दिया गया है। क्या मुझे क्रोधित होने का _अधिकार_ नहीं है?

पुनश्च. आह, तुम _that_ ग्रेग यंग हो। मान सम्मान। अपने काम से प्यार करो। मैं वास्तव में करता हूँ।

@bzbetty मैं आपसे पूरी तरह सहमत हूं। आखिरी चीज जो मैं देखना चाहता हूं वह है प्रोजेक्ट.जेसन में एमएसबिल्ड की फिर से कल्पना करना। अपने वर्तमान स्वरूप में MSBuild के साथ सबसे बड़ी समस्याओं में से एक यह है कि यह एक _project परिभाषा_ को _build प्रक्रिया_ के साथ जोड़ती है।

तो जा रहा है और एक निर्माण प्रक्रिया को project.json में जोड़ना ठीक वही गलती करेगा जो MSBuild/VS ने किया था।

परियोजना की परिभाषा निर्माण प्रक्रिया से अलग होनी चाहिए और इसे निर्माण प्रक्रिया में शामिल किया जाना चाहिए।

और फिर किसी को यह पूछना होगा: यदि आपकी परियोजना सरल है और आपको सीधे परियोजना परिभाषा के निर्माण की आवश्यकता है, तो क्या आपको वास्तव में एक साधारण निर्माण करने के लिए एक भारी, एक्स्टेंसिबल, अनुकूलन योग्य, लचीला और काउंटर सहज ज्ञान युक्त निर्माण प्रणाली की आवश्यकता है?

इसे दूसरे तरीके से लगाएं। यदि आप _had_ इतनी सरल परियोजना परिभाषा, और एक बहुत ही सरल निर्माण उपकरण है जो परियोजना की परिभाषा बनाने के अलावा और कुछ नहीं कर सकता है, तो क्या आप MSBuild या NANT या इसी तरह की स्थापना और उपयोग करना चुनेंगे?

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

लेकिन, एक बार जब आप एक परिदृश्य से टकराते हैं कि सरल "परिभाषा बनाएँ" उपकरण संभाल नहीं सकता है? ज़रूर, _तब_ आप करेंगे।

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

साबुन का डिब्बा

मैं बस एक छोटा सा शोध साझा करना चाहता हूं जो मैं कर रहा हूं। मैं Twitter, Slack, Github, Gitter, और Jabbr देख रहा हूँ।

मैंने कोर टीम से बाहर जाने के लिए बहुत कम समर्थन देखा है। मेरा मतलब है, कुछ रहा है, लेकिन ज्यादा नहीं। ज्यादातर लोग इस कदम से काफी परेशान हैं।

मैं एमएसबिल्ड समर्थक शिविर में कई लोगों की प्रवृत्ति से भी बहुत निराश हूं कि उनके विरोधियों को गलत जानकारी दी गई है, या अधिक सामान्यतः, अयोग्य। यह प्रो-प्रोजेक्ट.जेसन कैंप में खराब उद्देश्यों का अनुमान लगाने की प्रवृत्ति से मेल खाता है।

मैं निम्नलिखित पूछना चाहता हूं:

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

के लिए बहस
एमएसबिल्ड में जाने के लिए मैंने जिन मुख्य कारणों को उन्नत देखा है वे हैं:

• टूलींग सपोर्ट - विभिन्न टूल्स के बीच राउंड ट्रिपिंग की अनुमति देने के लिए, जैसे VS, VSCode, Xamarin, आदि।
• मौजूदा निवेश - बड़े ग्राहकों के पास मौजूदा बिल्ड होते हैं जिन्हें फेंका नहीं जा सकता
• "मांसपेशियों की स्मृति" - लोगों को MSBuild के लिए उपयोग किया जाता है

के खिलाफ तर्क

• मौजूदा निवेश - .NET कोर टूलिंग में किए गए निवेश: RC पोस्ट करें। आरसी _चाहिए_ का मतलब कोई बड़ा ब्रेकिंग परिवर्तन नहीं है
• CSProj/MSBuild बुरा - csproj और MSBuild से निपटने में पिछले नकारात्मक अनुभव
• पीछे की ओर कदम - प्रोजेक्ट पर ले जाएं। जेसन काम करने के एक नए तरीके से ले जाया गया था, आंशिक रूप से देवों की एक नई पीढ़ी को आकर्षित करने के लिए। इसे पूर्ववत किया जा रहा है

राय
मैंने एक पूर्ण सर्वेमोनकी सदस्यता के लिए भुगतान किया है ताकि मैं परिणामों के पूर्ण सेट (पहले सौ के बजाय) तक पहुंच सकूं। यह 321 प्रतिक्रियाएं हैं, जो आम तौर पर त्रुटि के ± 5.5% मार्जिन, 95 मिलियन आबादी के लिए 95% आत्मविश्वास का अनुवाद करती हैं।

इस सर्वेक्षण के विरुद्ध मैंने जो सामान्य तर्क सुने हैं वे हैं:

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

वे यहाँ हैं:

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

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

मैन @shederman मुझे (और कई अन्य) की याद दिलाता है जब सिल्वरलाइट ने इसे खाया , x10 और अधिक केंद्रित/अनुभवी को छोड़कर। शायद इसीलिए मैं उसका समर्थन करता हूँ :100:%! हाहा।

एमएसबिल्ड के वर्तमान स्वरूप में सबसे बड़ी समस्याओं में से एक यह है कि यह एक निर्माण प्रक्रिया के साथ एक परियोजना परिभाषा को जोड़ता है।

तो जा रहा है और एक निर्माण प्रक्रिया को project.json में जोड़ना ठीक वही गलती करेगा जो MSBuild/VS ने किया था।

परियोजना की परिभाषा निर्माण प्रक्रिया से अलग होनी चाहिए और इसे निर्माण प्रक्रिया में शामिल किया जाना चाहिए।

:+1: :+1: :+1:... समस्या तैयार करने का बेहतरीन तरीका!!! तुम्हें पता है, मेरी नाक इतने लंबे समय से है, कि यह वास्तव में मेरे साथ कभी नहीं हुआ। लेकिन आप (फिर से) 100% ऑन-पॉइंट हैं।

मुझे किसी समस्या को ठीक करने के लिए एक csproj फ़ाइल खोलने से नफरत है क्योंकि यह मुश्किल-से-पार्स टेक्स्ट की दीवार है।

इसे कहीं न कहीं फंसाने की जरूरत है, @nbarbettini! मेरी भावना को भी पूरी तरह से पकड़ लेता है।

और यह वास्तव में ज्यादा मायने नहीं रखता है कि फ़ाइल प्रारूप JSON, XML, या जो कुछ भी है।

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

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

वैसे भी, लंगड़ा रविवार की सुबह सभी के लिए पीएसए। :अटक_बाहर_जीभ:

मैं इसे इस थ्रेड में कहीं भी पोस्ट करते हुए नहीं देख सका, इसलिए यह रहा... https://youtu.be/N9MteJH-HsQ। उम्मीद है कि यह इस बारे में कुछ और बताता है कि बदलाव क्यों किया जा रहा है।

@शेडरमैन

"क्या मैं पूछ सकता हूं, रुचि से, पागल हिस्सा क्या है? किसी की सोच से पूछताछ करना आजकल तर्कसंगत नहीं है? या मैंने वहां कुछ छोड़ दिया?"

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

मेरे फोन पर गिटहब मुझे +1

टीम ने समझाया है कि बदलाव का कारण Xamarin का अधिग्रहण है, जो एक बड़ी बात है। .NET, ASP.NET और Xamarin मोबाइल/एक्स-प्लेट परियोजनाओं के बीच पुस्तकालयों को साझा करने की क्षमता बहुत अधिक है, और यदि इसका मतलब है कि परियोजना/बिल्ड फ़ाइल प्रारूप से समझौता करना, यह एक सार्थक व्यापार IMHO है।

मैं प्रतीक्षा करने जा रहा हूं और देखूंगा कि अंतिम राय बनाने से पहले टूलींग और अंतिम फ़ाइल सेटअप कैसा दिखता है।

@gregoryyoung मैं सर्वेक्षण के परिणामों की बात कर रहा था और सामान्य डेवलपर आबादी को एक्सट्रपलेशन करने की कोशिश कर रहा था ... एक बड़ा और स्पष्ट नमूना पूर्वाग्रह है।

वह कौन सा नमूना पूर्वाग्रह होगा? जहां इसे मुख्य रूप से उन लोगों के ट्विटर फीड पर पोस्ट किया गया था जो परिवर्तनों को पसंद करते हैं? वह जहां यह सुस्त चैनलों पर था जिसे देव टीम उपयोग करती है?

मुख्य नमूना पूर्वाग्रह मैं देख

322 पेशेवर .NET डेवलपर्स ने एक राय व्यक्त की है। क्या आप उनके इनपुट को पूरी तरह से अनदेखा करने जा रहे हैं क्योंकि आप मानते हैं (बिना किसी सबूत के आपका समर्थन करने के लिए) कि यह गैर-प्रतिनिधि है?

जाहिर है, अगले हफ्ते एक ब्लॉग पोस्ट आएगा, तब हमारे पास चर्चा करने के लिए और अधिक विशिष्ट चीजें होंगी।

जीज़ लोगों को बिल्ली को शांत करने की ज़रूरत है :)

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

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

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

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

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

आइए देखें कि वे क्या सुझाव दे रहे हैं और फिर विशिष्ट मुद्दों को उठाएं यदि हमें उसमें गलती मिलती है :)

@एएल3891

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

वास्तव में, यह वही है जो मैं तीन दिनों से मांग रहा था। निर्णय लेने की प्रक्रिया में अंतर्दृष्टि और इसका समर्थन करने वाले साक्ष्य। इस संबंध में अब तक जो जानकारी दी गई है, वह बहुत ही कमतर है।

अगर हम इसे प्राप्त करते हैं, तो मुझसे +10।

@ aL3891 त्वरित प्रश्न। कुछ लोग कह रहे थे कि हमें इन मुद्दों के समाधान के लिए बुधवार के स्टैंड अप में शामिल होना चाहिए। क्या आप कह रहे हैं कि हमें ब्लॉग पोस्ट की प्रतीक्षा करनी चाहिए?

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

मैंने वह youtube वीडियो देखा जिसे @khellang ने पोस्ट किया था - ASP.NET के परिवर्तन _revolutionary_ थे, लेकिन ऐसा लगता है, अंत में, यह बहुत क्रांतिकारी था, और अब मिश्रण में Xamarin के साथ, _revolutionary_ इसे काटने वाला नहीं है।

इसके अलावा, पहिया को फिर से आविष्कार करने का विचार आकर्षक नहीं लग रहा था, जब ऐसा लगता है कि यह वास्तव में सही काम था ... लेकिन फिर से विरासत।

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

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

दूसरी ओर, शायद मुझे कहीं कुछ याद आ गया?

@shederman मैं सुझाव स्टैंडअप में शामिल हों और ब्लॉग पोस्ट के लिए नजर रखें (जो लगभग निश्चित रूप से यहां जुड़ा होगा)।

स्टैंडअप से अनजान लोगों के लिए, यहां जाएं :

आप इसे अपने कैलेंडर में जोड़ सकते हैं और यह एक सार्थक घड़ी है, भले ही आपको परियोजना की परिभाषा में बदलाव की परवाह न हो।

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

ऊपर लिंक किए गए नवीनतम on.net एपिसोड ने हालांकि कुछ अच्छी अंतर्दृष्टि प्रदान की

रोसलिन प्रोजेक्ट सिस्टम रेपो भी है जो आने वाले महीनों में बहुत अधिक कार्रवाई देखने की संभावना है

क्या किसी के पास on.net एपिसोड पर TL;DR है?

मुझे लगता है कि प्रोग्रामिंग के बारे में वीडियो देखने में मैं बेहद असामान्य हूं। मुझे कभी भी टेक्स्ट दें

खूनी नरकंकाल! मैं अपने सीखने के तरीकों में भी गैर-आईडीई हूं

मुझे लगता है कि प्रोग्रामिंग के बारे में वीडियो देखने से नफरत करने में मैं बेहद असामान्य हूं। मुझे कभी भी टेक्स्ट दें :मुस्कान:

समस्या क्या है? यह आपके समय का _केवल_ एक घंटा है। मुस्कराहट:

@rhires

लड़का। यह संभवत: पिछले 3 दिनों में इस मुद्दे पर देखी गई सबसे अच्छी पोस्टों में से एक है!

खून बहने वाले किनारे आईएमओ पर बने रहने के लिए भुगतान करने के लिए छोटी कीमत, लेकिन प्रत्येक के लिए अपने स्वयं के;)

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

इसलिए इसके बजाय उन्होंने msbuild पर बिल्ड सिस्टम को आधार बनाने का विकल्प चुना, लेकिन नई प्रणाली से लोगों को पसंद आने वाले सामान में लाया। जहाँ तक समय की बात है, RC1 के बनने के समय भी xamarin के अधिग्रहण का पता नहीं था, लेकिन अब जब यह हो गया तो इसने बहुत सारी चीज़ें बदल दीं।

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

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

मैं इसे देखने की अनुशंसा करता हूं, शायद मुझे यहां कुछ बेहतर बिंदु याद आ रहे हैं।

@ aL3891 - महान सारांश के लिए धन्यवाद। यह वीडियो के माध्यम से जाने के लिए एक नारा था। मैं सहमत हूं कि उन्हें एक पाठ सारांश लिखना चाहिए। मैंने देखा कि वे "सीख रहे हैं", और अभी भी अपनी प्रक्रिया को खोलने में असहज महसूस कर रहे हैं, भले ही वे कहते हैं कि यह एक अच्छी बात है। इसलिए उम्मीद है कि यह उनके लिए सीखने का अच्छा अनुभव होगा और हम बदलाव देखेंगे और इसके लाभार्थी होंगे।

@ aL3891 सारांश के लिए धन्यवाद!

खून बहने वाले किनारे आईएमओ पर बने रहने के लिए भुगतान करने के लिए छोटी कीमत, लेकिन प्रत्येक के लिए अपने स्वयं के;)

आह, लेकिन मैं खून बहने वाले किनारे पर नहीं हूं, मैं वहां से थोड़ा पीछे रहता हूं। अभी बहुत पहले खुद को काटने के लिए पर्याप्त नहीं है, या कम से कम मैंने सोचा था कि जब मैंने .NET कोर पोस्ट-आरसी 1 को अपनाया था

@shederman यह देखते हुए कि "पोस्ट-RC1" मूल रूप से nightlies या स्रोत है, कैसे वास्तव में अपने स्टेक की तरह है न?

@neoKushan मेरा मतलब था कि हमने केवल "अपनाया* .NET Core _after_ RC1 जारी किया था। हम अभी भी वेनिला RC1 पर हैं।

तो, हम अपने स्टेक माध्यम को दुर्लभ पसंद करते हैं। लेकिन हम वास्तव में कच्चे टुकड़े में कटौती कर रहे हैं और वेटर के लिए चिल्ला रहे हैं।

लेकिन यह ठीक है, मैंने वेटर को बुलाना बंद कर दिया है, और अब मैत्रे'ड (हमारे समूह Microsoft भागीदार प्रतिनिधि) को आकर मुझसे मिलने के लिए बुलाया है और हम निर्णय लेने, सूचना के प्रसार और प्लेटफ़ॉर्म दिशा पर चर्चा कर सकते हैं।

हम कुछ नहीं जानते!

हमें इस मुद्दे में पर्याप्त जानकारी, बहुत अधिक सिद्धांत और अनुमान नहीं दिया गया है। आलसी के लिए त्वरित सारांश जो इस धागे को पढ़ना नहीं चाहते हैं:

हम क्या जानते हैं

1. xproj को csproj में बदल दिया जाएगा।
2. हमारे पास nuget.json फ़ाइल हो सकती है।
3. हम msbuild का उपयोग कर रहे हैं।
4. यह सब चरणों में होगा।
5. पुस्तकालय नहीं बदलेंगे।
6. आपको csproj में प्रत्येक फ़ाइल को निर्दिष्ट करने की आवश्यकता नहीं होगी।

जो हम अभी तक नहीं जानते

1. क्या csproj .nupkg के लिए संकलित होगा?
2. क्या csproj एक साथ x86/x64 dotnet/dotnetcore पर एकाधिक आर्किटेक्चर और लक्ष्यों को संकलित करेगा?
3. क्या एक अलग nuget.config फाइल होगी।
4. npm/gulp/bower/etc को निष्पादित करने के लिए कमांड को कैसे हैंडल किया जाएगा?
5. क्या हम dotnet build साथ-साथ msbuild का भी उपयोग कर पाएंगे? मैं पूरी तरह से उस 'वन .net' के लिए तैयार हूं जिसकी @shanselman की इच्छा है।
6. क्या प्रोजेक्ट संदर्भों के लिए इंटेलिजेंस रहेगा या चला जाएगा?
7. क्या वीएस टूलिंग या कमांड लाइन इतनी अच्छी होगी कि हमें कभी भी csproj.
8. क्या हमें dotnet add reference MyAssembly टूलिंग मिलेगी?

मुझे लगता है कि इस मुद्दे को तब तक बंद कर देना चाहिए जब तक हमारे पास अधिक जानकारी न हो।

मैं पूरी तरह से उस 'वन .net' के लिए तैयार हूं जिसकी @shanselman की इच्छा है।

यह वाला ? :मुस्कान: :+1: :+1: :+1:

मुझे लगता है कि इस मुद्दे को तब तक बंद कर देना चाहिए जब तक हमारे पास अधिक जानकारी न हो।

लेकिन लेकिन लेकिन... फिर मैं अपनी ज़िंदगी का क्या करूँ??? रोना: :मुस्कुराना:

@रेहान सईद

और क्या होगा अगर मुझे "हम क्या जानते हैं" सूची में समस्याएं हैं?

क्या मुझे अपनी चिंताओं को उठाने से पहले "क्या हम अभी तक नहीं जानते" सूची पर स्पष्टता की प्रतीक्षा करनी चाहिए?

या मुझे बस चुप रहना चाहिए और इसे चूसना चाहिए?

जैसा कि मैं अच्छी तरह से जानता हूं कि बहुत से लोग चाहेंगे कि...

मैंने जो कुछ भी देखा है, उसमें से निर्णय 100% है, अपरिवर्तनीय है:

तो मुझे "व्हाट वी डोंट स्टिल नो" से और क्या चाहिए?

@shederman आप वास्तव में ऑन.नेट वीडियो देखना चाहेंगे। यह निर्णय के पीछे तर्क का एक गुच्छा देता है।

fyi: मैं आमतौर पर इसे तेजी से देखने के लिए गति को 1.5 में बदल देता हूं। https://www.youtube.com/watch?v=N9MteJH-HsQ

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

@MelGrubb एक चीज जो हम जानते हैं, वह यह है कि नया प्रोजेक्ट लेआउट मौजूद सभी फाइलों को सूचीबद्ध नहीं करेगा, यह प्रोजेक्ट जैसा ही होगा। जेसन करता है

किसी भी चीज़ के लिए जो हाथ से प्रबंधित होने की उम्मीद है, कृपया TOML।

JSON कॉन्फ़िगरेशन के लिए कोई मतलब नहीं रखता है। यह एक्सएमएल से भी कम समझ में आता है।

रुचि रखने वाले किसी भी व्यक्ति के लिए, ऐसा लगता है कि आरसी 2 बिट्स उपलब्ध हैं (अभी तक कोई ब्लॉग पोस्ट नहीं है जिसे मैं देख सकता हूं)

https://www.microsoft.com/net/core#windows

और https://www.microsoft.com/net/download#core

मेरे दो सेंट, fwiw:

मुझे project.json की सादगी पसंद है। एमएसबिल्ड-आधारित टूलिंग में देखने के लिए मैं जो चाहता हूं (और पसंद नहीं) यहां दिया गया है:

• एमएसबिल्ड को वीएस या किसी अन्य आईडीई/संपादक से नहीं जोड़ा जाना चाहिए। यह एक स्टैंडअलोन टूल होना चाहिए जिसे अपने आप इंस्टॉल किया जा सकता है। (या डॉटनेट क्ली इंस्टॉल के हिस्से के रूप में शामिल है।) मैं यह इसलिए कहता हूं क्योंकि मुझे एमएसबिल्ड प्राप्त करने के लिए बिल्ड एजेंटों पर एक पूर्ण वीएस इंस्टेंस स्थापित करना पड़ा है। यह मुझे कभी समझ में नहीं आया।
• एमएसबिल्ड (या एमएसबिल्ड युक्त डॉटनेट क्ली) स्वयं कमांड लाइन के साथ इंस्टॉल करने योग्य होना चाहिए - चाहे एपीटी-गेट, चॉकलेटली, होमब्रू, पावरहेल या बैश/कर्ल। अगर मैं इसे किसी बिल्ड एजेंट (जैसे, Circle.yml या Dockerfile में) के पूरी तरह से स्वचालित सेटअप के हिस्से के रूप में स्थापित नहीं कर सकता, तो यह एक रोडब्लॉक और दर्द का स्रोत होगा।
• एमएसबिल्ड बहुत कमांड लाइन अनुकूल होना चाहिए। मुझे कमांड लाइन से कुछ भी करने में सक्षम होना चाहिए - और इसलिए एक निर्माण प्रक्रिया में कुछ भी स्वचालित करने में सक्षम होना चाहिए - एक Circle.yml, बैश या अन्य स्क्रिप्ट फ़ाइल में। और मैं स्टड और स्टडआउट का अच्छा उपयोग देखना चाहता हूं, इसलिए मैं एमएसबिल्ड कमांड के अंदर/बाहर पाइप कर सकता हूं।
• VS कोड (या किसी अन्य गैर-VS संपादक) में .NET कोर प्रोजेक्ट पर काम करने के लिए csproj फ़ाइल या कहीं और VS-विशिष्ट जानकारी की आवश्यकता नहीं होनी चाहिए। परियोजना की जानकारी, नगेट पैकेज निर्भरता, प्लेटफ़ॉर्म लक्ष्य, कंपाइलर निर्देश, आदि विभिन्न आईडीई/संपादकों का उपयोग करके डेवलपर्स के बीच साझा किए जाने चाहिए। वे एक परियोजना फ़ाइल में समझ में आता है। लेकिन वीएस का उपयोग नहीं करने वाले लोगों को वीएस टूलिंग सेटिंग्स नहीं देखनी चाहिए - वे एक अलग फाइल में हैं।
• प्रोजेक्ट फ़ाइल (फाइलों) को समझने में आसान और हाथ से संपादित करने में आसान होना चाहिए। उपकरण कमाल के हैं, लेकिन मुझे फ़ाइल खोलने और यह समझने में सक्षम होना चाहिए कि उपकरण मेरे लिए क्या कर रहे हैं। और आसानी से बदलाव करें।
• हालांकि मुझे पता है कि कार्यक्षमता/क्षमता में कोई अंतर नहीं है, मेरे पास एक्सएमएल पर जेसन के लिए एक मजबूत व्यक्तिगत वरीयता है। मुझे यह भी लगता है कि जेसन का उपयोग करने से अन्य ढेर से आने वाले डेवलपर्स को आकर्षित करने में मदद मिलेगी। लोगों को .NET की ओर आकर्षित करना काफी कठिन है, बिना पहली चीज़ के उन्हें एक बड़ी, समझने में मुश्किल XML फ़ाइल दिखाई देती है। (यह तार्किक से अधिक भावनात्मक है, लेकिन मुझे लगता है कि यह मायने रखता है।) कृपया कम से कम जोंस को एक विकल्प बनाएं, और उस विकल्प का उपयोग योमन जेनरेटर और अन्य नए प्रोजेक्ट टेम्प्लेट में करें। सबसे खराब स्थिति में, कृपया MSBuild रेपो में एक साधारण जोंस प्रारूप को लागू करने वाले अपरिहार्य पुल अनुरोध को तुरंत स्वीकार करें।
• एनपीएम-शैली "स्क्रिप्ट" रखना अच्छा होगा, इसलिए मैं आसानी से अपनी टीम के साथ देव, परीक्षण, डीबग, बिल्ड, रन, डॉकर बिल्ड/रन इत्यादि के लिए उपयोग की जाने वाली कमांड साझा कर सकता हूं। वे अपनी स्क्रिप्ट फाइलों में जा सकते हैं, लेकिन वे प्रोजेक्ट फ़ाइल के हिस्से के रूप में (मेरे लिए) समझ में आते हैं।

@jtbennett

"लेकिन वीएस का उपयोग नहीं करने वाले लोगों को वीएस टूलिंग सेटिंग्स नहीं देखनी चाहिए - वे एक अलग फाइल में हैं।"

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

@jtbennett

एमएसबिल्ड को वीएस या किसी अन्य आईडीई/संपादक से नहीं जोड़ा जाना चाहिए।

यह वीएस से बिल्कुल भी बंधा नहीं होगा, इसे Nuget के माध्यम से वितरित किया जाएगा, इसलिए यह किसी भी चीज़ से बंधा नहीं है।

एमएसबिल्ड (या एमएसबिल्ड युक्त डॉटनेट क्ली) स्वयं कमांड लाइन के साथ इंस्टॉल करने योग्य होना चाहिए

यह आज से नहीं बदल रहा है, आप अभी भी सामान्य पैकेज स्रोतों के माध्यम से डॉटनेट क्ली स्थापित करने में सक्षम होंगे।

एमएसबिल्ड बहुत कमांड लाइन अनुकूल होना चाहिए।

_MSBuild_ प्रभावी रूप से बिल्ड का ही हिस्सा होगा, इसलिए मुझे नहीं लगता कि आपको कमांड लाइन विकल्पों में पास करने की आवश्यकता होगी। हालांकि, डोनेट (सीएलआई) स्पष्ट रूप से कमांड-लाइन फ्रेंडली होगा और मुझे लगता है कि यह वही है जो आप चाहते/चाहते हैं।

VS कोड (या किसी अन्य गैर-VS संपादक) में .NET कोर प्रोजेक्ट पर काम करने के लिए csproj फ़ाइल या कहीं और VS-विशिष्ट जानकारी की आवश्यकता नहीं होनी चाहिए।

मैं पूरी तरह से इस बात से सहमत हूं। उम्मीद है कि "नया" परियोजना प्रारूप और अधिक सरल हो जाएगा।

प्रोजेक्ट फ़ाइल (फाइलों) को समझने में आसान और हाथ से संपादित करने में आसान होना चाहिए।

उन्होंने कहा है कि यह उनकी भी प्राथमिकता है.

हालांकि मुझे पता है कि कार्यक्षमता/क्षमता में कोई अंतर नहीं है, मेरे पास एक्सएमएल पर जेसन के लिए एक मजबूत व्यक्तिगत वरीयता है। मुझे यह भी लगता है कि जेसन का उपयोग करने से अन्य ढेर से आने वाले डेवलपर्स को आकर्षित करने में मदद मिलेगी। लोगों को .NET की ओर आकर्षित करना काफी कठिन है, बिना पहली चीज़ के उन्हें एक बड़ी, समझने में मुश्किल XML फ़ाइल दिखाई देती है।

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

अनजाने में, मुझे हाल ही में एक ऐसे प्रोजेक्ट पर काम करना पड़ा जहां किसी ने JSON को XML तत्वों में एम्बेड करने का प्रयास किया :(

RC2 ब्लॉग पोस्ट अब ऊपर: https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcing-asp-net-core-rc2/

.net कोर पोस्ट भी ऊपर है https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

धन्यवाद @neoKushan !

@michaelvolz मुझे नहीं लगता कि फ़ाइल रहने वाली है, अगर यह माना जाए: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/specs/runtime-configuration-file एमडी

System.GC.Server (पुराना: gcServer) - बूलियन इंगित करता है कि सर्वर GC का उपयोग किया जाना चाहिए (डिफ़ॉल्ट: सत्य)।

तथा

हम डीपीएस फ़ाइल के लिए एक अलग प्रारूप का उपयोग कर सकते हैं, लेकिन अगर हम पहले से ही एक JSON पार्सर को होस्ट में एकीकृत कर रहे हैं, तो इसे यहां फिर से उपयोग करना सबसे उपयुक्त लगता है।

उनके लिए _project config_ के लिए XML होना थोड़ा अजीब लगता है लेकिन _runtime config_ के लिए .json?

उनके लिए प्रोजेक्ट के लिए एक्सएमएल होना थोड़ा अजीब लगता है लेकिन रनटाइम के लिए .json?

अब करता है? :हंसना:

@ माइक-ईईई अच्छा बिंदु! मैंने उम्मीद के मुताबिक अपडेट किया है कि मेरा क्या मतलब है: चुंबन:

@neoKushan नहीं, आप पहली बार सही थे। : मुस्कान: मैं अपने कर्कश, सीमा रेखा-प्रति-उत्पादक तरीके से आपसे सहमत था। : मुस्कान_बिल्ली:

लेकिन हाँ... 100% सहमति है कि एक समाधान के भीतर विभिन्न स्वरूपों का होना चिंताजनक है। पूरे बोर्ड में एक ही प्रारूप होने से जटिलता, संदर्भ-स्विचिंग और इसलिए _confusion_ कम हो जाता है। यह एक कारण है कि मैं एमएसबिल्ड को विभिन्न प्रारूपों को सक्षम करना चाहता हूं

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

अरे धन्यवाद @sandorfr ... कृपया वहां धागे में योगदान करने के लिए स्वतंत्र महसूस करें (भले ही यह प्रतिक्रिया/: +1 :) हो। मैं वहां थोड़ा अकेला महसूस कर रहा हूं और निश्चित रूप से विवादित क्षेत्र में चल रहा हूं! मेरे दृष्टिकोण से मैं अपने उत्पाद को अपनाने/अनुकूलता/उपयोगिता/संभावना को बढ़ाने के लिए अपने उत्पाद में सुधार करने के लिए बहुत खुला रहूंगा यदि किसी भी कारण से मेरे उत्पाद का उपयोग करने के लिए कई ग्राहक मजबूर होते हैं। लेकिन मैं इसका प्रभारी नहीं हूं, इसलिए। :अटक_बाहर_जीभ:

@ माइक-ईईई मैंने कुछ सूत्र पढ़े, मैं अब बहुत उदास हूँ ... आपने विरासत दिमाग की विरासत की दुनिया में कदम रखा: डी।

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

आपने विरासत दिमाग की विरासत की दुनिया में कदम रखा: डी।

Wellllll ने कहा @sandorfr ... Wellllll- ने कहा।

स्टैंडअप से अनजान लोगों के लिए, यहां जाएं :

ठीक है, मैं कुल सुस्त हूँ और अंत में अभी-अभी इसकी जाँच की। ऐसा लगता है कि अगला स्टैंडअप अगले हफ़्ते है? क्या टीम इस सप्ताह छोड़ रही है?

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

ओके कूल @neoKushan ... बस यह सुनिश्चित करना कि मेरे सिर पर एक बार के लिए पवित्रता आ जाए। निश्चित रूप से, मैं अपने सभी सवालों और असंतोष से निपटने में इतनी जल्दी नहीं होना चाहता। :आँख मारना:

स्लैक से:

jongalloway [9:31 AM] मुझे पूरा यकीन है कि ASP.NET सामुदायिक स्टैंडअप कल रद्द कर दिया गया है - shanselman और damianedwards दोनों OSCON में हैं।
...
डेविडफॉवल [9:34 पूर्वाह्न] डेमियनडवर्ड्स: वापस आ गया है ... लेकिन शानसेलमैन ऑसकॉन में है
...
jongalloway [9:46 AM] हाँ, ASP.NET समुदाय स्टैंडअप निश्चित रूप से 5/17 के लिए रद्द कर दिया गया है। मैंने साइट को अपडेट किया।

@ माइक-ईईई हमारे सभी ... असंतोष से निपट रहा है

मैं

अगर कोई संदेह बचा था: https://twitter.com/shanselman/status/732585321775267842

छोड़ना पड़ता है। मैं #vslive और OSCON में हूँ

प्रोजेक्ट.जेसन के साथ एक चीज मुझे बहुत पसंद है: सभी फाइलें प्रोजेक्ट में डिफ़ॉल्ट रूप से शामिल हैं, इनमें से प्रत्येक को स्पष्ट रूप से शामिल करने की आवश्यकता के बिना। बड़ी परियोजनाओं के साथ (मेरा मतलब हजारों फाइलों से है), एक्सएमएल की वजह से विलय प्रक्रिया वास्तव में दर्दनाक थी, लेकिन csproj में सूचीबद्ध प्रत्येक फ़ाइल की वजह से भी।

क्‍या हम जानते हैं कि क्‍या इस दिशा में कोई सुधार होने जा रहा है ?

@pierrus यह उल्लेख किया गया था कि वे उन दिनों में वापस नहीं जाना चाहते हैं जहां सभी फाइलें csproj के अंदर सूचीबद्ध थीं।

@MaximRouiller ओके को यह नहीं पता था, बढ़िया!

@MaximRouiller पर वे दिन जहां MSBuild था एक रिंग ™, मैं उपकरण मतलब बिल्ड करने के लिए वापस जाना चाहते हो। मैं

_ऐश न्यूडरटोग वेगल दुरबतुल, ऐश न्यूडरटोग वेगल गिम्बतुल,
ऐश न्यूडरटोग वेगल थ्राकतुलिक अघ बुर्जुम-इशी क्रिम्पतुल._

@shederman मैंने समाचार पर अपनी पहली प्रतिक्रिया के बाद से अपनी बात को मॉडरेट किया है।

मेरी सोच यह है कि वे शुरू में project.json प्रारूप को शिप करना चाहते थे लेकिन csproj/Xamarin के साथ मॉडल को सामान्य करने के लिए उन्हें ढांचे को और भी लंबा धक्का देना होगा। तेज लाभ csproj में वापस विलय करना था। वे csproj के अंदर शुद्ध "केवल डेटा" रखते हुए नए तरीके को एक अलग फ़ाइल में रख सकते हैं। यह मेरे लिए RC2 के बड़े पैमाने पर किए गए कार्य की व्याख्या करता है।

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

मुझे इस बारे में अंदरूनी जानकारी नहीं है। यह मेरी ओर से शुद्ध अटकलें हैं।

वैसे भी... हम अब वार्षिक रिलीज चक्र में समाप्त नहीं हो रहे हैं। यदि वे RTM के बाद project.json से csproj में संक्रमण के लिए तैयार हैं, तो मैं यह मान रहा हूँ कि RTM के बाद भी बड़े परिवर्तन जारी किए जा सकते हैं।

ऐसे बदलाव जिनके बारे में MS टीम के अलावा कोई नहीं जानता।

@MaximRouiller मैं "संभावित" परिवर्तनों पर काम नहीं कर सकता जो _might_ लाइन से नीचे आ रहे हैं।

मैं बस घोषित परिवर्तनों से काम करता हूं, कि वे हल्के निर्माण से आगे बढ़ रहे हैं, एमएसबिल्ड और xproj का उपयोग हर चीज के लिए कर रहे हैं।

हाँ, हम राक्षस पर वापस जा रहे हैं... लेकिन हम बहुत दूर नहीं हैं।

उम, अगर हमारे पास _deprecated_ कुछ है जो 90% उपयोग मामलों के लिए काम कर रहा है _back_ को किसी ऐसी चीज़ पर ले जाने के लिए जो उन उपयोग मामलों के लिए अत्यधिक जटिल है, तो मेरे पास केवल एक ही प्रश्न है:

क्यों?

dotnet build MSBuild को कॉल क्यों कर रहा है जब msbuild पहले से ही यह काफी अच्छी तरह से करता है। सरल निर्माण को बहिष्कृत क्यों करें? अतिरिक्त काम क्यों करते हैं? एकमात्र कारण सरल है, निर्णय लिया गया है कि हम सभी को हर समय, हमेशा के लिए हर समय एमएसबिल्ड का उपयोग करना चाहिए।

कुछ ऐसा जो 90% उपयोग के मामलों के लिए काम कर रहा है

[प्रशस्ति - पत्र आवश्यक]

यहां तक ​​​​कि यह मानते हुए कि यह 90% उपयोग के मामले हैं, क्या आप ऐसी किसी भी चीज़ के साथ काम करेंगे जो 1/10 वें समय में विफल रही हो?

किसी ऐसी चीज़ पर वापस जाएँ जो अत्यधिक जटिल हो

दोबारा, [उद्धरण वांछित], केवल एक चीज जिसे हम अब तक जानते हैं वह यह है कि यह XML-csproj होगा और इसमें फ़ाइल सूची नहीं होगी । हम इस बारे में और कुछ नहीं जानते हैं कि सिस्टम कैसे काम करेगा और मुझे यकीन नहीं है कि हमें जानने की भी जरूरत है, क्योंकि यहां हर कोई सिर्फ "डॉटनेट बिल्ड" कह रहा है और इस बात की परवाह किए बिना कि बिल्ड कैसे हासिल किया जाता है, वह नहीं बदलेगा।

डॉटनेट बिल्ड एमएसबिल्ड को क्यों बुला रहा है जब एमएसबिल्ड पहले से ही यह काफी अच्छा करता है।

क्या हम यह कहने से चले गए हैं कि एमएसबिल्ड "अत्यधिक जटिल" है "एमएसबिल्ड पहले से ही यह काफी अच्छा करता है"? वर्तमान में, dotnet build केवल _लगता है_ सरल है क्योंकि पृष्ठभूमि में जो कुछ भी होता है वह आपसे छिपा होता है। एमएसबिल्ड पर स्विच करने से यह नहीं बदलता है, जहां तक ​​​​आपका संबंध है यह अभी भी dotnet build ।

किसी ऐसे व्यक्ति के लिए जो कहता रहता है कि प्रोजेक्ट सिस्टम और बिल्ड सिस्टम के बीच अंतर होना चाहिए, आप यह स्वीकार करने के इच्छुक नहीं हैं कि वास्तव में MSBuild XML फ़ाइलों को प्रोजेक्ट सिस्टम के रूप में रखने और MSBuild को बिल्ड सिस्टम के रूप में रखने के बीच अंतर है - वहाँ पहले से ही अलगाव है।

90% उपयोग के मामलों के लिए काम करना

@shederman कृपया यह मानना ​​बंद करें कि सब कुछ ASP.NET है... आप इस सूत्र में _जानबूझकर अज्ञानी_ के रूप में सामने आते हैं। मेरा सुझाव है कि जब तक हम वास्तव में नई परियोजना प्रणाली के बारे में अधिक जानकारी प्राप्त नहीं कर लेते, तब तक आप शांत हो जाएं, बजाय इसके कि सब कुछ बर्बाद हो गया है।

@shederman जब आप किसी चीज़ पर शिम बनाते हैं, तो आप उसे बदलना चाहते हैं। इसे सार करें ताकि आप कार्यान्वयन को बदल सकें। हम इसे हर दिन करते हैं। इसे रिफैक्टरिंग कहते हैं।

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

यदि यह dotnet build जैसा है तो सवाल यह है - अंडरलाइन बिल्ड प्रक्रिया को बदलना कितना कठिन होगा? क्या एमएसबिल्ड को कुछ अलग से बदलना संभव है? इसके लिए कितने डक्ट टेप की आवश्यकता होगी?

अगर हम डक्ट टेप के 1 या 2 कंकालों में ऐसा बदलाव कर सकते हैं, तो यह स्वीकार्य है।

@neoKushan क्या हम यह कहने से चले गए हैं कि MSBuild "अत्यधिक जटिल" है "MSbuild पहले से ही यह बहुत अच्छा करता है"?

उम नहीं। मुझे विश्वास है कि मैं कह रहा था कि कमांड msbuild MSBuild को काफी अच्छी तरह से चलाता है। मैं एक उपकरण के रूप में MSBuild पर कोई निर्णय नहीं ले रहा था। क्या यह स्पष्ट नहीं था?

@neoKushan यह मानते हुए भी कि यह 90% उपयोग के मामले हैं, क्या आप ऐसी किसी भी चीज़ के साथ काम करेंगे जो 1/10 वें समय में विफल रही हो?

कुछ भी विफल होने के बारे में कोई कुछ नहीं कह

@neoKushan MSbuild में स्विच करने से यह नहीं बदलता है

उम, यह निर्माण प्रक्रिया संख्या को नहीं बदलता है। हालांकि यह _does_ काम करने के लिए निर्माण प्रक्रिया (यानी csproj फ़ाइल) के लिए आवश्यक चीज़ों को बदलता है, और जिस गति से इसे किया जाता है।

@neoKushan आप यह स्वीकार करने को तैयार नहीं हैं कि वास्तव में MSBuild XML फ़ाइलों को प्रोजेक्ट सिस्टम के रूप में रखने और MSBuild को बिल्ड सिस्टम के रूप में रखने के बीच एक अंतर है - पहले से ही एक अलगाव है।

क्षमा करें, लेकिन मैं यह नहीं देखता कि एक उपकरण से दो काम कैसे होते हैं, यह एक अलगाव है।

@poke कृपया मान लें कि सब कुछ ASP.NET है

मैं नहीं। मैं कह रहा हूं कि प्रस्तावित समाधान सरल निर्माण के लिए उतना अच्छा काम नहीं करता है। जिनमें से कुछ ASP.NET बिल्ड हैं। व्यक्तिगत रूप से मुझे नहीं लगता कि मुझे एक साधारण कंसोल ऐप के लिए एमएसबिल्ड के रूप में शक्तिशाली कुछ क्यों चाहिए।

@poke आप इस सूत्र में जानबूझ कर अज्ञानी के रूप में सामने आते हैं।

मुझे आशा है, हाँ। क्योंकि एमएसबिल्ड के उपयोगकर्ताओं के लिए अर्जित होने वाले अद्भुत लाभ हैं जो मैं जानबूझकर अनजान हूं।

@poke मैं आपको अभी के लिए शांत होने का सुझाव

यार, मैं शांत हूँ मैं तुमसे वादा करता हूँ।

मैं केवल दृष्टिकोण की अनुमति नहीं दे रहा हूं मैं निर्विवाद रूप से असहमत हूं। मैं आपसे वादा करता हूं कि यह आंदोलन का संकेत नहीं है। अच्छाई की खातिर, किसी नन्ही सी चिड़िया_व्यक्ति_को अज्ञानी कहने से भी मैं उत्तेजित नहीं हुआ

कौन सा विडंबना की तरह है, जब यह वही थोड़ा पाजी _person_ मेरे लिए बुला रहा है शांत करने की।

सच में मजेदार।

@MaximRouller @shederman जब आप किसी चीज़ पर शिम बनाते हैं, तो आप उसे बदलना चाहते हैं। इसे सार करें ताकि आप कार्यान्वयन को बदल सकें

आह हाँ, और कहा कि यह करने के लिए, मैं क्या सुना है MSBuild को बदलने के लिए कोई इरादा नहीं है से सिवाय एक अच्छा कारण होगा। यह निकट भविष्य के लिए चयनित बिल्ड सिस्टम है। मुझे यह अच्छा लगेगा यदि हम परियोजनाओं को एमएसबिल्ड विशिष्ट वस्तुओं के बिना खड़े होने की अनुमति दें, और यदि dotnet build या तो मौजूदा लाइट बिल्ड करना है, या किसी चीज़ के आधार पर बिल्ड टूल का चयन करना है, उदाहरण के लिए config. यदि आप एमएसबिल्ड का उपयोग करना चाहते हैं, तो हर तरह से एक एमएसबिल्ड फ़ाइल बनाएं और msbuild चलाएं।

उम नहीं। मुझे विश्वास है कि मैं कह रहा था कि एमएसबिल्ड कमांड एमएसबिल्ड को काफी अच्छी तरह से चलाता है।

इसे संदर्भ में रखने के लिए:

डॉटनेट बिल्ड MSBuild को क्यों बुला रहा है?

dotnet build कंपाइलर को "सिर्फ" कॉल करने से कहीं अधिक करता है, वर्तमान सीएलआई के डॉटनेट बिल्ड के कार्यान्वयन पर एक नज़र डालें । एक प्रोजेक्ट बनाना dotnet build प्रक्रिया का एक हिस्सा है। अंततः उस प्रक्रिया का _part_ msbuild पर कॉल करना होगा लेकिन यह आपका काम नहीं है, यह CLI का काम है।

मैं एक उपकरण के रूप में MSBuild पर कोई निर्णय नहीं ले रहा था।

आपने इस धागे में जो कुछ किया है वह एक उपकरण के रूप में MSBuild का न्याय करना है। यह दावा करना कि आप ऐसा कुछ नहीं कर रहे हैं, स्पष्ट रूप से, हास्यास्पद है।

क्या यह स्पष्ट नहीं था?

आप जो कहते हैं उसमें से बहुत कम स्पष्ट है, या कम से कम सुविचारित है।

कोई कुछ भी फेल होने के बारे में कुछ नहीं कह रहा है। कुछ उपकरण दूसरों की तुलना में कुछ उद्देश्यों के लिए अधिक उपयुक्त हैं।

तो कुछ उपकरण उद्देश्य के लिए उपयुक्त होने में विफल हो जाते हैं।

मैं कहूंगा कि एमएसबिल्ड की शक्ति और जटिलता लगभग 10% निर्माण के उद्देश्य के लिए उपयुक्त है।

वैसे यह दिलचस्प है क्योंकि वहां मौजूद प्रत्येक विजुअल स्टूडियो .net डेवलपर को असहमत होना पड़ेगा। आप प्रभावी रूप से कह रहे हैं कि एमएसबिल्ड 90% उपयोगकर्ताओं के लिए अच्छा नहीं है (इस तथ्य को अनदेखा कर रहा है कि आप अपने गधे से आंकड़े खींच रहे हैं), जो - फिर से - हास्यास्पद है।

उम, यह निर्माण प्रक्रिया संख्या को नहीं बदलता है।

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

हालांकि यह निर्माण प्रक्रिया के काम करने के लिए आवश्यक चीज़ों को बदल देता है (यानी csproj फ़ाइल)

वस्तुतः यही एकमात्र ऐसी चीज़ है जो वास्तव में जहाँ तक लोग देखेंगे, बदल रहा है।

और जिस गति से इसे किया जाता है।

[प्रशस्ति - पत्र आवश्यक]

कृपया मुझे दिखाएं कि नई प्रक्रिया कैसे तेज या धीमी है, यह देखते हुए कि

क्षमा करें, लेकिन मैं यह नहीं देखता कि एक उपकरण से दो काम कैसे होते हैं, यह एक अलगाव है।

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

मैं नहीं। मैं कह रहा हूं कि प्रस्तावित समाधान सरल निर्माण के लिए उतना अच्छा काम नहीं करता है

dotnet new
dotnet restore
dotnet build

कृपया मुझे दिखाएं कि प्रस्तावित समाधान "सरल निर्माण" परिदृश्य के बारे में कुछ भी कैसे बदलता है

जिनमें से कुछ ASP.NET बिल्ड हैं।

yo asp-net web
dotnet restore
dotnet build

व्यक्तिगत रूप से मुझे नहीं लगता कि मुझे एक साधारण कंसोल ऐप के लिए एमएसबिल्ड के रूप में शक्तिशाली कुछ क्यों चाहिए।

तुम नहीं। आपको बस dotnet build । जो आपके पास अभी भी होगा। वहां कुछ भी नहीं बदलता है।

मैं शांत हूँ मैं तुमसे वादा करता हूँ।

थोड़ा twerp

:-1:

@neoKushan यह वास्तव में अच्छा होगा यदि आप उद्धृत उद्धरण की प्रतिक्रिया और संपूर्ण चर्चा के बारे में एक टिप्पणी के बीच अवधारणा को समझ सकें। मैं मान रहा हूँ कि आप ऐसा करने में _सक्षम_ हैं, इसलिए एकमात्र निष्कर्ष यह है कि यह जानबूझकर किया गया है। अगर ऐसा है, तो बस आपको बता दें कि यह बौद्धिक रूप से बेईमानी करने वाली युक्ति है। मुझे आशा है कि आप इसे जानते होंगे, लेकिन मैं यहां संदेह का लाभ दे रहा हूं।

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

वैसे यह दिलचस्प है क्योंकि वहां मौजूद प्रत्येक विजुअल स्टूडियो .net डेवलपर को असहमत होना पड़ेगा।

अजीब बात है, मैंने ऐसे सबूत एकत्र किए

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

हां। तो हम सहमत हैं। मैं वास्तव में, वास्तव में इसे पसंद करूंगा यदि यह तुच्छ था ।

क्या वास्तव में ऐसा अनुचित अनुरोध है? सच में?

तुम नहीं। आपको बस डॉटनेट बिल्ड की जरूरत है। जो आपके पास अभी भी होगा। वहां कुछ भी नहीं बदलता है।

और dotnet build वास्तव में क्या करेगा? msbuild तक खोल दें? यदि हम MSBuild का उपयोग करना चाहते हैं तो हम केवल msbuild उपयोग क्यों नहीं कर सकते? उस स्थिति में dotnet build का वास्तव में क्या उद्देश्य है? यह टूलींग में क्या जोड़ता है?

थोड़ा ट्वर्प

मजाकिया बनने की कोशिश, लेकिन आप शायद सही कह रहे हैं।

@poke मैं अनारक्षित रूप से क्षमा चाहता हूं।

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

वस्तुतः कोई विचार नहीं है कि आप क्या कह रहे हैं।

मुझे भी लगता है कि आपको चिल पिल जरूर लेनी चाहिए।

...

तर्क पर हमला करो, व्यक्ति पर नहीं।

:सम्मिलित करेंरॉलीआईइमोटिकॉनयहां:

अजीब बात है, मैंने ऐसे सबूत एकत्र किए हैं जो कुछ अलग कहते हैं। आपको आपका वाला कहां से मिला?

ओके कूल, तो 10%/90% का आंकड़ा कहां से आया?

हां। तो हम सहमत हैं। मैं वास्तव में, वास्तव में इसे पसंद करूंगा यदि यह तुच्छ था।

जिसका एमएसबिल्ड में बदलने से कोई लेना-देना नहीं है, आपको पहले से ही मौजूदा बिल्ड सिस्टम को dotnet build से दूर करने में परेशानी होगी।

और डॉटनेट बिल्ड वास्तव में क्या करेगा? एमएसबिल्ड करने के लिए खोलो?

dnx या रोसलिन के बजाय dotnet build msbuild को कॉल करने से क्या अलग है?

अगर हम एमएसबिल्ड का उपयोग करना चाहते हैं तो हम एमएसबिल्ड का उपयोग क्यों नहीं कर सकते?

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

उस स्थिति में डॉटनेट बिल्ड का वास्तव में क्या उद्देश्य है? यह टूलींग में क्या जोड़ता है?

क्या हम वास्तव में dotnet build की खूबियों पर चर्चा कर रहे हैं? आपको dotnet build पसंद नहीं है? आप dotnet build के उद्देश्य को नहीं समझते हैं? इसकी संभावना नहीं लगती। आप क्या पूछने की कोशिश कर रहे हैं?

@neoKushan कृपया उनका विरोध करना बंद करें। यह रचनात्मक नहीं है।

ओके कूल, तो 10%/90% का आंकड़ा कहां से आया?

यह मेरे व्यक्तिगत अनुभवों से आया है। मैंने पाया है कि लगभग 90% मेरी टीम बनाता है और मैंने पिछले कुछ वर्षों में RC1 dotnet build तुलना में अधिक जटिल कुछ भी आवश्यक नहीं है।

जिसका एमएसबिल्ड में बदलने से कोई लेना-देना नहीं है, आपको पहले से ही मौजूदा बिल्ड सिस्टम को डॉटनेट बिल्ड से दूर बदलने में परेशानी होगी।

कृपया स्पष्ट करें, मुझे यकीन नहीं है कि आपका यहाँ क्या मतलब है।

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

_आह_. मेरा प्रश्न है: क्यों dotnet build MSBuild को खोल देना चाहिए जब msbuild यह वास्तव में पहले से ही अच्छी तरह से करता है? दो आदेश एक काम क्यों करते हैं?

मैंने इसे अब तक लगभग तीन बार पूछा है, और हर बार आपने या तो इसे गलत समझा है या इसका गलत अर्थ निकाला है।

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

एक वाक्य के प्रश्न की व्याख्या करने वाले लंबे विवरण के लिए क्षमा करें, लेकिन यह स्पष्ट रूप से आवश्यक है।

InfoQ पर एक लेख :
"Microsoft इस निष्कर्ष पर पहुंचा है कि project.json प्रयोग विफल हो गया है और .csproj फ़ाइलों का उपयोग करने के लिए वापस स्थानांतरित हो जाएगा।" :निराश:

जैसा मैंने कहा, धारणा मायने रखती है।

मेरा प्रश्न है: जब एमएसबिल्ड वास्तव में पहले से ही अच्छा करता है तो डॉटनेट को एमएसबिल्ड को खोल क्यों बनाना चाहिए? दो आदेश एक काम क्यों करते हैं?

क्योंकि वे सिर्फ एक काम नहीं करते?

एमएसबिल्ड को सीएससी को क्यों खोलना चाहिए जब सीएससी पहले से ही सामान बनाने का अच्छा काम करता है? दो आदेश एक काम क्यों करते हैं?

क्यों dotnet test xUnit परीक्षण धावक को खोल देना चाहिए जब यह पहले से ही अपने आप परीक्षण चलाने में अच्छा काम करता है। दो आदेश एक काम क्यों करते हैं?

NuGet को dotnet restore क्यों खोलना चाहिए जब NuGet पहले से ही पैकेज स्थापित करने का अच्छा काम करता है। दो आदेश एक काम क्यों करते हैं?

आपको विचार मिल गया... (मुझे आशा है: पलक :)

@sandorfr

@neoKushan कृपया उनका विरोध करना बंद करें। यह रचनात्मक नहीं है।

मैं जानबूझकर किसी का विरोध नहीं कर रहा हूं, मैं बिंदु-दर-बिंदु @shederman के तर्क का हूं , जो वास्तव में वह चाहता है कि लोग करें:

तर्क पर हमला करो, व्यक्ति पर नहीं।

हालांकि इस बिंदु पर, मुझे पूरी तरह से यकीन भी नहीं है कि @shederman का तर्क भी क्या है क्योंकि ऐसा लगता है कि हम किसी भी तरह एक्सएमएल से खराब हो गए हैं, dotnet build खराब है।

चलिए जारी रखते हैं।

यह मेरे व्यक्तिगत अनुभवों से आया है।

यह आपका "सबूत" है? जो, याद रखें, आप बोल्ड में डालते हैं:

अजीब बात है, मैंने ऐसे सबूत एकत्र किए

और अब यह "व्यक्तिगत अनुभव" है। इसे ही हम _anecdotal_ सबूत कहते हैं।

मैंने पाया है कि लगभग 90% मेरी टीम बनाता है और मैंने पिछले कुछ वर्षों में RC1 डॉटनेट बिल्ड की तुलना में अधिक जटिल कुछ भी आवश्यक नहीं है।

और आप इस संबंध में RC2 dotnet build या RTM dotnet build या पोस्ट-RTM dotnet build में क्या बदलाव की उम्मीद करते हैं?

कृपया स्पष्ट करें, मुझे यकीन नहीं है कि आपका यहाँ क्या मतलब है।

आपका तर्क ऐसा लगता है (और अगर मैं गलत हूं तो मुझे सुधारें) "माइक्रोसॉफ्ट ने इसे करने के लिए प्रोग्राम किए जाने के अलावा कुछ और करने के लिए dotnet build प्राप्त करना छोटा नहीं है"। जो डीएनएक्स के दिनों में ठीक था क्योंकि हम सभी डीएनएक्स को पसंद करते थे, लेकिन अब माइक्रोसॉफ्ट हुड के तहत एमएसबिल्ड का उपयोग करना चाहता है और आपको एमएसबिल्ड पसंद नहीं है, आप एमएसबिल्ड को किसी और चीज के लिए बदलने का विकल्प चाहते हैं - मेरा मुद्दा यह था कि यह कुछ भी नया नहीं है, अगर आपको डीएनएक्स के साथ कुछ समस्या थी तो आप उसे भी नहीं बदल सकते थे, इसलिए dotnet build साथ आपकी जो भी "समस्या" है, वह कोई नई बात नहीं है और इस प्रकार मुझे नहीं लगता कि यह प्रासंगिक है यहां _actual_ चर्चा के लिए, जो project.json जाने की संरचना है। csproj

आह मेरा प्रश्न है: जब एमएसबिल्ड वास्तव में पहले से ही अच्छा करता है तो डॉटनेट को एमएसबिल्ड को खोल क्यों बनाना चाहिए? दो आदेश एक काम क्यों करते हैं?

@खेलंग ने पहले ही इसका उत्तर

dotnet build कंपाइलर को "सिर्फ" कॉल करने से कहीं अधिक करता है, वर्तमान सीएलआई के डॉटनेट बिल्ड के कार्यान्वयन पर एक नज़र डालें । एक प्रोजेक्ट बनाना dotnet build प्रक्रिया का एक हिस्सा मात्र है। अंततः उस प्रक्रिया का _part_ msbuild पर कॉल करना होगा लेकिन यह आपका काम नहीं है, यह CLI का काम है।

तो, फिर से, कम से कम तीसरी बार: dotnet build पर कॉल करना msbuild कॉल करने का पर्याय नहीं है। ऐसा नहीं है, जैसा कि आप इसे कहते हैं, "दो आदेश [आईएनजी] एक काम करते हैं" और कभी नहीं था। वह कभी भी इस पूरी चर्चा के दायरे में नहीं था फिर भी किसी तरह आप वहाँ पहुँच गए हैं।

वास्तविक चर्चा, जो वास्तव में मायने रखती है वह है project.json की संरचना और इसे कैसे .csproj में मिलाना है। अंतर्निहित बिल्ड सिस्टम काफी हद तक अप्रासंगिक है यदि आप कुछ आसान चाहते हैं क्योंकि आपके पास हमेशा dotnet build ।

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

@खेलंग मुझे आपके व्यक्त करने का तरीका पसंद है, लेकिन फिर वहां से dotnet test क्या करता है। मैं project.json में xunit की तुलना में एक अलग परीक्षण धावक डाल सकता हूं, और dotnet test उस परीक्षण धावक को आमंत्रित करेगा।

लेकिन फिर भी, आने वाले परिवर्तनों के बारे में मैंने जो सुना है, उसमें dotnet build जैसी कोई क्षमता नहीं होगी। यह अपने निर्माण करने के लिए हमेशा एमएसबिल्ड का उपयोग करेगा। क्या यह समझ सही नहीं है?

@neoKushan मैं जानबूझकर किसी का विरोध नहीं कर रहा हूं, मैं बिंदु-दर-बिंदु @shederman के तर्क को तोड़ रहा हूं

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

@neoKushan हालांकि इस बिंदु पर, मुझे पूरी तरह से यकीन भी नहीं है कि @shederman का तर्क भी क्या है क्योंकि हमें लगता है कि एक्सएमएल से खराब होने के कारण

एक्सएमएल खराब है। एमएसबिल्ड खराब है। यदि dotnet build केवल MSBuild का उपयोग करता है, तो यह भी बुरा है। कृपया, प्रयास करें और बने रहें। यह इतना जटिल नहीं है। यदि आप इतने जानबूझकर भ्रमित नहीं हो रहे थे, तो आप इसे सदियों पहले समझ गए होंगे और वास्तव में रचनात्मक इनपुट जोड़ने में सक्षम होंगे।

@neoKushan यह आपका "सबूत" है? जो, याद रखें, आप बोल्ड में डालते हैं:

उम नहीं वह मेरा व्यक्तिगत अनुभव था, सबूत नहीं। मेरा प्रमाण 383 में से 281 उत्तरदाताओं का है जो मानते थे कि .NET Core का MSBuild में वापस जाना एक बुरा विचार है। और उन उत्तरदाताओं में से 85 जो मानते थे कि एमएसबिल्ड मौलिक रूप से टूटा हुआ है। वह मेरा सबूत है। आपका वास्तव में कहाँ है?

आप जानते हैं, अपने बयान का बैक अप लेने के लिए कि "... _हर सिंगल_ विजुअल स्टूडियो .net डेवलपर को असहमत होना होगा"? [महत्व दिया]

@neoKushan वास्तविक चर्चा, जो वास्तव में मायने रखती है वह है project.json की संरचना और इसे .csproj में कैसे मिलाना है

मैं वास्तव में आप से सहमत हूँ। लेकिन पृष्ठभूमि गंभीर रूप से महत्वपूर्ण है। एमएस ने जो योजना व्यक्त की है वह यह है कि एमएसबिल्ड बिल्ड ब्रह्मांड का केंद्र होगा। मुझे वह _पसंद नहीं है, लेकिन चलिए आगे बढ़ते हैं। यह देखते हुए, एक साधारण प्रश्न है:

"क्या MSBuild हमेशा के लिए .NET Framework के

यदि ऐसा है, तो हमें केवल msbuild कमांड की आवश्यकता है, और हमें dotnet build कमांड की आवश्यकता नहीं है, यह पूरी तरह से अनावश्यक है।

हालांकि, अगर हम स्वीकार करते हैं कि किसी बिंदु पर एमएसबिल्ड _वन ट्रू बिल्ड सिस्टम_ नहीं हो सकता है, तो हम और अधिक दिलचस्प क्षेत्र में हैं। फिर, dotnet build समझ में आता है। लेकिन तब यह अत्यंत महत्वपूर्ण है कि हम csproj और project.json के विलय पर चर्चा करते समय उस भविष्य को ध्यान में रखें।

मैं जो कोशिश कर रहा हूं (शायद खराब) यह इंगित करने के लिए कि एक बेहतर (मेरे दिमाग में) विकल्प _प्रोजेक्ट परिभाषा_ फाइलों और _बिल्ड परिभाषा_ फाइलों के बीच स्पष्ट अलगाव को आजमाने और रखने का होगा। यह हमें dotnet build लिए बेहतर तरीके से स्थापित करेगा जो कई बिल्ड इंजनों का समर्थन कर सकता है। अगर, इसके बजाय, हम सब कुछ csproj में ले जाते हैं, तो हम खुद को एक MSBuild दुनिया में बंद कर रहे हैं।

और हां, मैं समझता हूं कि डीएनएएक्स में यह "केवल एक सच्ची निर्माण" स्थिति मौजूद थी। लेकिन मैंने उस समय पूछताछ नहीं की थी क्योंकि हमारे पास जो निर्माण था, वह मुझे पसंद आया। आह, हम जिन परिस्थितियों में खुद को डालते हैं जब हम अन्याय को स्वीकार करते हैं तो हम _like_ ।

इसलिए, ऐसी स्थिति पर विचार करें जहां हमारे पास कॉन्फ़िगरेशन के आधार पर dotnet build कई बिल्ड टूल में से एक का उपयोग करने में सक्षम हो। जैसे dotnet test कई परीक्षण धावकों में से एक का उपयोग कर सकता है। अब, ऐसी काल्पनिक दुनिया को देखते हुए, अब आप csproj और project.json को कैसे मर्ज करेंगे? यही वह चर्चा है जो मैं करना चाहता

@rhires एक उच्च स्तर से dotnet build :

1. परियोजना फाइलों को एकत्रित करता है
2. निर्धारित करता है कि वृद्धिशील निर्माण के लिए पूर्व शर्त पूरी होती है या नहीं
3. प्रोजेक्ट पढ़ता है।json
4. लक्ष्य ढांचे को निर्धारित करता है
5. प्रत्येक परियोजना के लिए:
   
   
   
   1. इसकी निर्भरता बनाएं
   
   
   2. यदि वृद्धिशील है, तो जांचता है कि पुनर्निर्माण की आवश्यकता है या नहीं
   
   
   3. आउटपुट निर्देशिका निर्धारित करता है
   
   
   4. स्रोत फ़ाइलें एकत्र करता है
   
   
   5. संकलन विकल्प निर्धारित करता है
   
   
   6. प्रीकंपाइल स्क्रिप्ट चलाता है
   
   
   7. स्रोत फ़ाइलों और विकल्पों के साथ संकलक चलाता है
   
   
   8. पोस्टकंपाइल स्क्रिप्ट चलाता है
   
   
   9. रिपोर्ट आउटपुट
   
   

@shederman धन्यवाद! इस बिंदु से, इस प्रक्रिया में msbuild क्या जोड़/घटाना/प्रतिस्थापित/से/प्रतिस्थापित करेगा?

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

पॉट -> केतली

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

एक्सएमएल खराब है। एमएसबिल्ड खराब है। यदि डॉटनेट बिल्ड केवल एमएसबिल्ड का उपयोग करता है, तो यह भी खराब है।

_You_ के अलावा किसी ने भी इस तरह का दावा नहीं किया है। कोई भी नहीं। इस बात का जरा सा भी संकेत नहीं है कि ऐसा कुछ भी होने वाला है। मैंने आपसे बार-बार कहा है कि dotnet build _just_ कॉल करने वाला नहीं है MSBuild , मैंने आपसे कहा है कि dotnet build और msbuild पूरी तरह से पर्यायवाची नहीं हैं एक दूसरे और वह dotnet build कंपाइलर को कॉल करने से कहीं अधिक नरक करता है । मैंने आपको फ्रिगिन स्रोत कोड से भी जोड़ा है और अन्य लोग आए हैं और वही बात कहा है, फिर भी आप अभी भी जोर दे रहे हैं कि यह किसी तरह से क्या हो रहा है?

कृपया, प्रयास करें और बने रहें।

कैसे _you_ बने रहें? कृपया, हमें दिखाएं कि आपको यह विचार कहां से मिला है कि dotnet build केवल msbuild कॉल करेगा। किसने कहा तुमसे ये? आपने इसे कहाँ पढ़ा?

मेरा प्रमाण 383 में से 281 उत्तरदाताओं का है जो मानते थे कि .NET Core का MSBuild में वापस जाना एक बुरा विचार है। और उन उत्तरदाताओं में से 85 जो मानते थे कि एमएसबिल्ड मौलिक रूप से टूटा हुआ है। वह मेरा सबूत है। आपका वास्तव में कहाँ है?

और आपने उन आंकड़ों से 10% निकाला, है ना? याद रखें, यह आपका दावा है:

मैं कहूंगा कि एमएसबिल्ड की शक्ति और जटिलता लगभग 10% निर्माण के उद्देश्य के लिए उपयुक्त है।

बाद में आपने कहा:

अजीब बात है, मैंने ऐसे सबूत एकत्र किए हैं जो कुछ अलग कहते हैं।

तो यह सबूत कहां है? मुझे यह जानना अच्छा लगेगा कि आपने अपने "सबूत" से उस आंकड़े को कैसे खींचा।

आप जानते हैं, अपने कथन का बैक अप लेने के लिए कि "... वहां मौजूद प्रत्येक विजुअल स्टूडियो .net डेवलपर को असहमत होना पड़ेगा"?

आसान: https://msdn.microsoft.com/en-us/library/ms171468.aspx

विजुअल स्टूडियो एमएसबिल्ड को प्रबंधित परियोजनाओं को लोड और बनाने के लिए होस्ट करता है।

यदि आप अपनी परियोजनाओं के निर्माण के लिए विजुअल स्टूडियो का उपयोग करते हैं, तो आप एमएसबिल्ड का उपयोग करते हैं। आज भी .net कोर के साथ काम करते समय, यहां तक ​​कि RC1 VS के साथ भी MSbuild का उपयोग हुड के नीचे किया जाता है। आपको एमएसबिल्ड पसंद नहीं हो सकता है, लेकिन जैसा कि मैंने कहा है कि लगभग हर वीएस डेवलपर इसका इस्तेमाल करता है चाहे वे इसे महसूस करें या नहीं।

एमएस ने जो योजना व्यक्त की है वह यह है कि एमएसबिल्ड बिल्ड ब्रह्मांड का केंद्र होगा।

मैं इससे सहमत नहीं हूं। उन्होंने कभी नहीं कहा कि यह केंद्र होगा, उन्होंने बस इतना कहा है कि प्रोजेक्ट के कुछ हिस्से .json वापस .csproj में चले जाएंगे - इससे आगे, उन्होंने इस बारे में एक शब्द भी नहीं कहा है कि यह किस हद तक dotnet build बदलता है

"क्या MSBuild हमेशा के लिए .NET Framework के लिए मुख्य निर्माण प्रणाली होगी?"

यदि ऐसा है, तो हमें केवल एक एमएसबिल्ड कमांड की आवश्यकता है, और हमें डॉटनेट बिल्ड कमांड की आवश्यकता नहीं है, यह पूरी तरह से अनावश्यक है।

जैसा कि अब कई बार कहा जा चुका है, dotnet build और msbuild दो पूरी तरह से अलग चीजें हैं। dotnet build सिर्फ कंपाइलर टूलचैन को कॉल करने से ज्यादा कुछ करता है। डॉटनेट बिल्ड का उद्देश्य लोगों के लिए बिल्ड प्रक्रिया को सरल रखना है। फिर देखो:

dotnet new
dotnet restore
dotnet build

भले ही एमएसबिल्ड डॉटनेट सीएलआई का मुख्य घटक बन जाता है, जो इस तथ्य को नहीं बदलता है कि डॉटनेट बिल्ड काफी जटिल प्रणाली है (और हमेशा रहेगा) के आसपास स्वच्छ, सरल रैपर है। नरक, आधा कारण डॉटनेट सीएलआई मौजूद है (और इससे पहले डीएनएक्स) विशेष रूप से कमांड लाइन तर्क नरक से दूर होने के लिए है जो अंततः एमएसबिल्ड है। आपका तर्क यह कहने जैसा है कि "हमें npm install कमांड की आवश्यकता क्यों है जब मैं सिर्फ curl पैकेज कर सकता हूं?"। ज़रूर, आप यह सब मैन्युअल रूप से कर सकते हैं यदि आप वास्तव में चाहते हैं, लेकिन आप इससे लगभग कुछ भी हासिल नहीं करते हैं। तो क्या हुआ अगर dotnet build हुड के तहत msbuild का उपयोग करता है? आप लगभग निश्चित रूप से इसे कभी नहीं देख पाएंगे, या इसके बारे में जानने की जरूरत है।

आप MSBuild के साथ अपने पुराने अनुभव की तुलना नहीं कर सकते, यह बिल्कुल अलग है। हम सभी (प्रतीत होता है) उस एक द्वारा जला दिए गए हैं क्योंकि हम वीएस खोलने, एक प्रोजेक्ट बनाने और इसे अभी बनाने के लिए उपयोग कर रहे हैं, लेकिन फिर जब आप उसी प्रोजेक्ट को बिल्ड सर्वर पर बनाने के लिए जाते हैं तो यह अचानक बकवास के बारे में शिकायत कर रहा है जो _समायोजित कार्य_ करना चाहिए। संभवत: माइक्रोसॉफ्ट ने टीएफएस 2015 के साथ सबसे अच्छी चीजों में से एक बिल्ड परिभाषा बनाई थी जो _MSBuild_ के बजाय _Visual Studio_ में संबंध रखती है क्योंकि आप इसे "बस काम कर रहे हैं" पर वापस आ गए हैं। यह बिल्ड टूलचेन ठीक यही है - dotnet build आपके पूरे बिल्ड सिस्टम को बदलने के लिए नहीं है, यह केवल आपकी परियोजनाओं के निर्माण से संबंधित है, भले ही यह हुड के तहत MSBuild उपयोग करता हो। यदि आप TeamCity या Jenkins जैसी किसी चीज़ का उपयोग करना चाहते हैं, तो dotnet build आपको उन्हें कॉल करने के लिए कहना होगा और बाकी काम डॉटनेट करता है। _How_ यह आपके लिए कोई चिंता का विषय नहीं है।

केवल एक चीज - और मेरा मतलब यह पूरी तरह से है, केवल एक चीज जो वास्तव में आपके लिए बदलती है वह है project.json/csproj फ़ाइल। इतना ही_। यही कारण है कि dotnet build वास्तव में क्या करता है और MSBuild किसके लिए अच्छा और बुरा है, इस बारे में बहस करना बिल्कुल _निरर्थक_ है।

@neoKushan बस रुक जाओ ...

@neoKushan रुकिए ...

मेरा एक हिस्सा यह कल्पना करना पसंद करता है कि ASP.NET टीम जानबूझकर स्टैंडअप को रद्द कर रही है क्योंकि वे शो का आनंद ले रहे थे, और उत्तर प्रदान करने से यह सब समाप्त हो जाएगा। :मुस्कुराओ:

मेरी (अब दृढ़ता से) अज्ञेयवादी स्थिति से, दोनों पक्ष पिछले कुछ समय से जानबूझकर एक दूसरे की बातों से रूबरू हुए हैं। आप .NET कोर समुदाय की मेरी मानसिक छवि को गैर-रचनात्मक और बदतर के रूप में स्थापित करने में सफल हो रहे हैं। धारणा के बारे में बात करें ...

अधिकांश गैर-NuGet सामान csproj में विलय हो जाएंगे। यदि कोई प्रोजेक्ट.जेसन (nuget.json?) नहीं है तो NuGet सामान का क्या होगा?

उपयोगकर्ताओं को उनकी निर्भरता को प्रबंधित करने का एक तरीका प्रदान करते हैं, और शायद डिफ़ॉल्ट रूप से dotnet nuget प्रदान करते हैं क्योंकि NuGet .net समुदाय में अच्छी तरह से स्थापित है।

लेकिन निर्भरता को प्रबंधित करने के एकमात्र तरीके से सभी डॉटनेट कोर सामान को कड़ी मेहनत न करें ( dotnet restore dotnet nuget restore बराबर नहीं होना चाहिए), कई लोगों के लिए nuget केवल एक पैकेज भंडार है लेकिन एक नहीं निर्भरता प्रबंधक, लोगों के पास अन्य विकल्प हैं जो उन्हें "निर्भरता प्रबंधक" उपयोग के मामले में अधिक उत्पादक/उपयुक्त मिल सकते हैं।

क्या हम निर्भरता प्रबंधन के लिए IntelliSense रखेंगे? यह मूल रूप से हमारे पास project.json के लिए सबसे अच्छी डेमो सुविधाओं में से एक है।

आप तर्क का पुनर्व्यवस्थित कर सकते हैं, मैं इसे एक बड़ी बात के रूप में नहीं देखता, उदाहरण के लिए, मैं nuget.org पर जाता हूं और एक पैकेज की खोज करता हूं और आईडी को यूआरएल से कॉपी करता हूं, यह कुशल है।

आप शेल पूर्णता भी प्रदान करना चाह सकते हैं, जो आपको bash या zsh का उपयोग करने वाले लोगों से बहुत प्रशंसा दिलाएगा:

dotnet nuget add S[tab] S शुरू होने वाले प्रोजेक्ट पहचानकर्ताओं के लिए पूर्णता सूची प्रदान करता है

यदि आप <NuGet> टैग बेक करना चाहते हैं तो msbuild *proj फाइलों में इंटेलिजेंस होना भी संभव होना चाहिए, लेकिन साथ ही, पूरे इको-सिस्टम के लिए हार्ड कपल नगेट न करें, यानी <Package>NuGetPackageId</Package> चाहिए' t <NuGet>NuGetPackageId</NuGet> या इसे ओवरराइड करने का एक बहुत ही सरल (और बहुत अच्छी तरह से प्रलेखित और समर्थित) तरीका होना चाहिए।

Paket विजुअल स्टूडियो प्लगइन में nuget पर स्वत: पूर्णता है, यह काम करता है लेकिन वैसे भी धीमा है क्योंकि मुझे लगता है कि nuget.org से प्रतिक्रिया वापस करने में कुछ समय लगता है।

क्या हम निर्भरता प्रबंधन के लिए JSON प्रारूप रख रहे हैं? एक्सएमएल उन प्रकार की चीजों के लिए भयानक है (मेवेन देखें)। JSON उन निर्भरताओं का प्रतिनिधित्व करने के लिए सरल है।

यदि आप प्रारूप के लिए विचारों की तलाश कर रहे हैं, तो आप paket.dependencies , अन्यथा, मुझे नहीं लगता कि यह बहुत मायने रखता है, project.json का संपादन लगभग उतना ही अच्छा था जितना कि packages.config संपादित करना

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

@rhires इस बिंदु से, इस प्रक्रिया में msbuild क्या जोड़/घटाना/प्रतिस्थापित/से/प्रतिस्थापित करेगा?

खैर, यह इस बात पर निर्भर करता है कि वे इसे कैसे एकीकृत करते हैं। यदि वे "हार्ड लॉक" करते हैं, तो एमएसबिल्ड को डॉटनेट बिल्ड में गहराई से एकीकृत करते हैं, जो सार्वजनिक जानकारी इंगित करती है कि उनका पसंदीदा दृष्टिकोण है, तो इसे एमएसबिल्ड द्वारा पूरी तरह से बदल दिया जाएगा।

हालांकि, अगर वे dotnet build विन्यास योग्य बनाते हैं, तो मुझे उम्मीद है कि यह कुछ ऐसा काम करेगा:

1. परियोजना फाइलों को एकत्रित करता है
2. प्रोजेक्ट पढ़ता है।json
3. लक्ष्य ढांचे को निर्धारित करता है
4. उपयोग करने के लिए निर्माण उपकरण निर्धारित करें
5. बिल्ड टूल के लिए शेल आउट
6. रिपोर्ट आउटपुट

@neoKushan यही कारण है कि एमएसबिल्ड किसके लिए अच्छा और बुरा है, इस बारे में बहस बिल्कुल व्यर्थ है।

मैं

मैं जो चाहता हूं _discuss_ वह है जो project.json और csproj को ऐसी दुनिया में दिखना चाहिए जहां dotnet build MSBuild को _many संभावित बिल्ड टूल्स_ में से एक के रूप में खोल सकता है। क्या ये ठीक है? क्या हम इस बारे में बात कर सकते हैं कि project.json में क्या होगा बनाम csproj में क्या होगा, यह देखते हुए?

क्योंकि अगर हम चर्चा करें कि मेरा मानना ​​है कि यह धागा वास्तव में रचनात्मक बन सकता है।

@jmm आप .NET कोर समुदाय की मेरी मानसिक छवि को गैर-रचनात्मक और बदतर के रूप में स्थापित करने में सफल हो रहे हैं

उसके लिए माफ़ करना। हालांकि, अगर आपके पास समय है, तो मैं कुछ अन्य विशाल ओपन सोर्स प्रोजेक्ट्स के चैट आर्काइव्स के माध्यम से पढ़ने का सुझाव दूंगा।

तर्क वास्तव में जीवन की तरह ही एक स्वस्थ समुदाय की निशानी हैं। जब हर कोई नेताओं के एक समूह का आँख बंद करके अनुसरण करता है, तो आमतौर पर चीजें इतनी अच्छी नहीं होती हैं। निर्णय, साक्ष्य और निर्णय लेने के लिए पूछताछ के लिए खुला होना चाहिए।

@shederman उत्पादक चर्चा जारी रखने के हित में, मैं प्रस्तावित परिवर्तनों के प्रभावों पर चर्चा करने के लिए एक रेखा भी खींचना चाहता हूं।

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

मेरे अपने _व्यक्तिगत_ दृष्टिकोण से, मुझे परवाह नहीं है कि बिल्ड सिस्टम क्या है या यह कैसे काम करता है। मेरा मतलब यह नहीं है कि ऐसा करने वालों के लिए अज्ञानी या खारिज करने के लिए, मेरा मतलब है कि एक डेवलपर परिप्रेक्ष्य से, मैं सिर्फ यह जानना चाहता हूं कि "डॉटनेट बिल्ड" मेरी असेंबली को तब तक थूकता है जब तक कि परियोजना संरचना सही है - जहां तक ​​​​जैसा कि मेरा संबंध है, dotnet build -> परियोजना ->-> विधानसभा। केवल एक चीज जो वास्तव में मेरे लिए मायने रखती है, और इस चर्चा का दायरा क्या होना चाहिए (और मुझे लगता है कि हम अंत में यहां समझौते में हैं) वह परियोजना कैसी दिखती है और मेरे दैनिक कार्यप्रवाह के लिए इसका क्या अर्थ है।

मैं मर्ज हेल से सिर्फ इसलिए डील नहीं करना चाहता क्योंकि मैंने एक .cs फ़ाइल जोड़ी है, और न ही मैं एक हज़ार लाइन लंबी XML फ़ाइल को केवल इसलिए डील करना चाहता हूँ क्योंकि कुछ सिस्टम जो _मुझे परवाह नहीं है_ उस पर निर्भर करता है - मैं नहीं करता' मुझे नहीं लगता कि हम में से कोई भी करता है और यह वर्षों से वीएस विकास का एक बड़ा हिस्सा रहा है। हमारे पास प्रोजेक्ट.जेसन प्रारूप के साथ आशा की एक किरण थी क्योंकि यह आज भी खड़ा है क्योंकि यह पहले की तुलना में _बहुत बेहतर_ था, इसलिए मैं पूरी तरह से समझता हूं और समझता हूं कि केवल संकेत पर गुस्सा इतनी जल्दी क्यों भड़क गया कि हम वापस जा रहे हैं "बुरे पुराने दिन", लेकिन साथ ही यह कहने लायक है कि हमें खुद को धोखा नहीं देना चाहिए - project.json आज किसी भी तरह से _perfect_ नहीं है, इसके अपने मुद्दों का सेट है और जबकि वे तुलना में मामूली हो सकते हैं "पुराने" csproj के मुद्दे, यह वस्तुनिष्ठ होने और इस बात पर चर्चा करने लायक है कि चीजों को कहां सुधारा जा सकता है और क्या बेहतर हो सकता है।

निश्चित रूप से दोनों दुनियाओं में _सर्वश्रेष्ठ_संभावना है।

मुझे लगता है कि यहां मुख्य चर्चा "नया" .csproj के लेआउट और प्रारूप पर होनी चाहिए और प्रोजेक्ट.जेसन (या विशिष्ट होने के लिए, "प्रोजेक्ट" संरचना पूरी तरह से) के साथ क्या होता है।

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

वैसे भी, मैंने उस रेपो को वहां क्या हो रहा है, इस पर अपडेट प्राप्त करने के लिए शुरू/देखा है। :+1:

(मैं भी आधा सोच रहा हूं कि क्या हमें इस चर्चा को एक नए मुद्दे पर ले जाना चाहिए।)

@neoKushan निश्चित रूप से, तथ्य यह है कि इसमें

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

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

एक पथ में एक एमएसबिल्ड कार्य हो सकता है जो एक विकल्प के रूप में project.json लोड करेगा। फिर, डेवलपर को प्रोजेक्ट सेटिंग्स में चुनने दें यदि वे project.json को सक्षम करना चाहते हैं जो उस कार्य को csproj में जोड़ देगा।

@ माइक-ईईई हाँ आशा है :)

मुझे पूरा यकीन है कि वर्तमान झुकाव project.json nuget.json बनना है - जो उम्मीद से निर्भरता के मुद्दे को हल करेगा और मौजूदा प्रोजेक्ट.जेसन कार्यक्षमता को व्यवहार में छोड़ देगा।

केवल एक चीज जिसे मैं समझ नहीं पा रहा हूं वह यह है कि यह बहु-लक्ष्यीकरण को कैसे प्रभावित करता है, क्या csproj और nuget.json को इसके बारे में पता होना चाहिए और समझना चाहिए कि वे प्रत्येक लक्ष्यीकरण क्या कर रहे हैं? क्या हम प्रत्येक लक्ष्य के लिए एक csproj के साथ समाप्त होते हैं (यक!), या क्या वे .csproj को इसके लिए पर्याप्त रूप से विस्तारित कर सकते हैं?

project.json बन गया nuget.json

बस यहाँ जिज्ञासु... _यह_बातचीत कहाँ हो रही है? मैं एक विशेष प्रारूप के साथ लॉक करने के लिए पहले नगेट टीम से मिला हूं। प्रोजेक्ट.जेसन के संबंध में उन्होंने कहा कि यह एक विजुअल स्टूडियो टूलिंग चिंता थी और कुछ ऐसा जो वे संबोधित नहीं कर सके। अब ऐसा लगता है कि गतिशीलता बदल गई है और एक ही तरह की समस्या की प्रतिलिपि/चिपकाया है। :अटक_बाहर_जीभ:

मेरी चिंता को स्पष्ट करने के लिए, यह है कि अब हम JSON और XML को एक साथ मिला रहे हैं जो कम से कम अक्षमता पैदा करता है।

बस यहाँ जिज्ञासु... यह बातचीत कहाँ हो रही है?

वैसे यह मूल रूप से यहाँ कहा गया था: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/

यह संभव है कि project.json फ़ाइल बनी रहे, और इसमें NuGet के सभी पैकेज संदर्भ हों और इसका नाम बदलकर nuget.json कर दिया जाए।

और मुझे लगता है कि वास्तव में यहां चर्चा इस बारे में है कि आप project.json से कितना लेते हैं और .csproj में डालते हैं? मेरी परियोजनाओं में, अधिकांश project.json पैकेज संदर्भ रहे हैं, खासकर यदि मैं एकाधिक ढांचे को लक्षित कर रहा हूं। उपरोक्त से पता चलता है कि यह सब बना रहेगा और केवल "अन्य" बिट्स निकाले जाएंगे। मेरे (फिर से: व्यक्तिगत) अनुभव में, ये "अन्य" बिट्स वास्तव में एक परियोजना के जीवन के माध्यम से ज्यादा नहीं बदलते हैं, इसलिए भले ही यह एक्सएमएल में हो, यह बहुत सारे एक्सएमएल नहीं है और यह काफी स्थिर होना चाहिए ... एक उम्मीद है .

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

वैसे यह मूल रूप से यहाँ कहा गया था ...

आह हाँ... बिल्कुल! ठीक है। बस सुनिश्चित कर रहे है। उम्मीद है कि कल वह दिन होगा जब हम अंततः इसके बारे में कुछ स्पष्टता (बेहतर या बदतर के लिए!) प्राप्त करेंगे।

मैं सहमत हूं कि अलग-अलग कॉन्फ़िगरेशन के लिए एक्सएमएल और जेएसओएन का मिश्रण और मिलान थोड़ा बदबूदार है

वास्तव में खुशी है कि मैं अकेला नहीं हूं जो इसे देखता है और इस तरह महसूस करता है। :) यह वहाँ कुछ समय के लिए अकेला लग रहा था क्योंकि मैंने पहली बार .JSON को परियोजनाओं में रेंगते हुए देखने के दुःख से जूझ रहा था। वेब-एपदेव पृष्ठभूमि से पूरी तरह से समझ में आता है, लेकिन मूल एपदेव कोई पसंद नहीं है, और इसके विपरीत जब एक्सएमएल की बात आती है।

हाहा... जिसके बारे में बात करते हुए, उपरोक्त लिखने से मुझे राजभाषा के अभिलेखागार से बाहर निकलने में मदद मिली। यहाँ मैं 2014 में वापस आ गया हूँ (हाँ, आपने इसका अनुमान लगाया है!) JSON के बजाय Xaml हाहाहा ओह देखो कि मैं कितना युवा और पूरी तरह से भोला था! इतना प्यारा और मासूम! लड़का, क्या मेरे पास सीखने के लिए दुनिया है। :stuck_out_tongue: लेकिन, मैं कहूंगा कि कुछ प्रगति हुई है। आखिरकार, हमने वेब सर्वर कॉन्फ़िगरेशन के लिए उपयोग किए जाने वाले .ini से छुटकारा पा लिया। :मुस्कुराओ:

@neoKushan निश्चित रूप से दोनों दुनिया की सबसे अच्छी संभावना है।

👯 👯 👯

@neoKushan मुझे पूरा यकीन है कि वर्तमान झुकाव प्रोजेक्ट होना है।json nuget.json बन गया है ... केवल एक चीज जिसे मैं नहीं समझ सकता कि यह मल्टीटार्गेटिंग को कैसे प्रभावित करता है, क्या csproj और nuget.json को जागरूक होना होगा और समझते हैं कि वे प्रत्येक लक्ष्यीकरण क्या कर रहे हैं?

एक प्रारंभिक बिंदु के रूप में project.json स्कीमा का उपयोग करना, मेरे दृष्टिकोण से, निम्न आइटम संभवतः _not_ बिल्ड परिभाषा फ़ाइल में होना चाहिए:

• स्रोत फ़ाइलों की सूची
• परियोजना निर्भरता
• लक्ष्य ढांचे
• प्रोजेक्ट कमांड (जैसे वेब, टेस्ट, आदि)
• वेबरूट
• मेटाडाटा
• भाषा संस्करण

निम्नलिखित मैं नहीं _believe_ बिल्ड परिभाषा फ़ाइल में होना चाहिए, लेकिन मैं इसके बारे में _meh_ होगा यदि वे थे:

• कॉन्फ़िगरेशन परिभाषाएं
• लिपियों, पूर्व और पोस्ट

निम्नलिखित शायद _ चाहिए_ बिल्ड परिभाषा फ़ाइल में होना चाहिए:

• संकलन विकल्प (भाषा संस्करण को छोड़कर)

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

@shederman क्या हमें यह स्पष्ट करने की आवश्यकता है कि "बिल्ड डेफिनिशन" से आपका क्या मतलब है? शायद मेरी शब्दावली बंद है, लेकिन मैं वर्तमान प्रोजेक्ट.जेसन को एक _बिल्ड परिभाषा_ फ़ाइल नहीं बल्कि एक _प्रोजेक्ट परिभाषा_ फ़ाइल (और वही नई csproj फ़ाइल के लिए जाना होगा) नहीं कहूंगा। संभवतः शब्दार्थ, लेकिन मेरे लिए एक निर्माण परिभाषा से पता चलता है कि यह परिभाषित करता है कि चीजें कैसे बनाई जाती हैं_, जबकि एक परियोजना परिभाषा परिभाषित करती है कि एक परियोजना क्या बनाती है और कुछ और के लिए कदम बनाती है।

_यह मेरा प्रोजेक्ट है, इसमें ये आइटम हैं और ये निर्भरताएं हैं। आप इसे कैसे बनाते हैं यह मेरा काम नहीं है।_

बहुत सी परियोजनाओं को केवल सम्मेलन के माध्यम से निर्धारित किया जा सकता है, जैसे कि शीर्ष स्तर के फ़ोल्डर से असेंबली का नाम कैसे आता है। इस सोच के साथ चलते हुए, _nuget.json_ बस nuget के साथ कुछ भी करना होगा - इसलिए पैकेज/निर्भरता वहां चली जाएगी और मुझे लगता है कि हम सभी इससे खुश हैं।

जो मैं बिल्कुल तय नहीं कर सकता वह लक्ष्य ढांचे है। यदि Nuget.json केवल निर्भरता समाधान से संबंधित है, तो हालांकि विभिन्न ढांचे को लक्षित करते समय संदर्भों के लिए इसमें कुछ अलगाव हो सकता है, मुझे पूरी तरह से यकीन नहीं है कि यह तय करना चाहिए कि कौन से ढांचे को वास्तव में लक्षित किया जाना चाहिए, जो कि _project के लिए कुछ और लगता है definition_ (जो कुछ भी समाप्त होता है)।

फिर फिर, केवल पैकेज संदर्भों की तुलना में nuget के लिए और भी कुछ है, इसमें पैकेज _definition_ और संस्करण भी शामिल है जब आपकी लाइब्रेरी _becomes_ एक nuget पैकेज। ऐसा लगता है जैसे nuget.json कम से कम दो अलग-अलग चीजें कर रहा है और वह थोड़ी सी गंध शुरू कर रहा है। शायद (बस यहां स्पिटबॉलिंग), csproj पैकेज के विवरण, लक्ष्य ढांचे आदि को परिभाषित करेगा और प्रत्येक लक्ष्य ढांचा एक .json फ़ाइल को इंगित कर सकता है, जो मूल रूप से nuget संकुल है। दूसरे शब्दों में, एक nuget.json के बजाय, आपके पास प्रत्येक फ़्रेमवर्क के लिए एक अलग .json फ़ाइल होगी। यह एक भयानक विचार हो सकता है, मैंने इसके बारे में विशेष रूप से नहीं सोचा है।

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ :

हमारे पास दो विकल्प थे। एक प्रोजेक्ट.json का उपयोग करने के लिए सभी .NET प्रोजेक्ट्स को स्थानांतरित करना था। इसके लिए हमें टूलींग कार्य करने की आवश्यकता होगी जो विजुअल स्टूडियो, ज़ामरीन और हमारे भागीदारों जैसे यूनिटी में सभी प्रकार के प्रोजेक्ट को छूता है। हमें इनमें से प्रत्येक प्रकार के प्रोजेक्ट के लिए आवश्यक सभी बिल्ड परिदृश्यों का समर्थन करने के लिए project.json का विस्तार करना होगा और एक माइग्रेशन कहानी प्रदान करनी होगी। एक अन्य विकल्प पुलों का निर्माण करना था ताकि एक .xproj प्रोजेक्ट एक .csproj प्रोजेक्ट को संदर्भित कर सके और एक .csproj प्रोजेक्ट Visual Studio और Xamarin Studio में एक .xproj प्रोजेक्ट को संदर्भित कर सके। ब्रिज में चुनौतियां भी हैं, उदाहरण के लिए जब कोई ग्राहक कोई प्रोजेक्ट बनाता है तो उन्हें अब एक .xproj या एक .csproj चुनना होगा, जो केवल अधिक विकल्प और जटिलता जोड़ता है।

और

हमारे विकल्पों को देखने के बाद, यह स्पष्ट था कि .NET कोर प्रोजेक्ट्स को .csproj/MSBuild में स्थानांतरित करना आसान होगा, इसलिए सभी .NET प्रोजेक्ट्स समान टूलिंग और बिल्ड सिस्टम का उपयोग करते हैं।

हम अनुपलब्ध कार्यक्षमता का समर्थन करने के लिए .csproj को बढ़ाने की योजना बना रहे हैं:

• परियोजना प्रणाली में फाइलों की कोई सूची नहीं
• प्रोजेक्ट फ़ाइल पर कोई भी ऑपरेशन करने के लिए CLI टूल, अधिकांश परिदृश्यों के लिए आप फ़ाइल को संपादित नहीं करेंगे
• सीधे प्रोजेक्ट से पैकेज बनाएं
• मल्टी लक्ष्य-निर्धारण

और चूंकि सभी .NET समान टूलिंग का उपयोग करते हैं, इसलिए हम MSBuild को बढ़ाने पर विचार कर सकते हैं। हम ग्राहकों और समुदाय से एक्सएमएल के बजाय जेएसओएन का समर्थन करने पर प्रतिक्रिया मांगेंगे, हमारे टूलिंग में अत्यधिक वर्बोज़ फ़ाइलें और अधिक उत्पन्न नहीं होंगे। और क्योंकि सब कुछ एक ही टूलींग का उपयोग करता है, ये एन्हांसमेंट सभी .NET प्रोजेक्ट्स पर काम कर सकते हैं।

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485:

यह मानते हुए कि .csproj का अर्थ अभी भी C# प्रोजेक्ट है, निश्चित रूप से गैर-C# प्रोजेक्ट्स के लिए अन्य लक्ष्य भी होंगे, है ना? [बेन]

हां। [स्कॉट एच]

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

मुझे अक्सर एमएसबिल्ड फाइलों को संपादित करने की आवश्यकता नहीं होती है, लेकिन जब मुझे इसकी आवश्यकता होती है तो यह बहुत मुश्किल होता है, घोषणात्मक दृष्टिकोण आपको प्रवाह में खो देता है, मैं अपना उदाहरण लाता हूं, कोई भी इस तरह की सरल समस्या को हल करने में सक्षम नहीं लगता है https://github .com/madskristensen/BundlerMinifier/issues/89
यदि 6 महीने के बाद कोई भी एक के बाद एक कार्य (दो अलग-अलग कार्य जो एक दूसरे के बारे में नहीं जानते हैं) को बिना गंदी हैकिंग के या योगात्मक तरीके से नहीं चला सकता है, तो शायद वहां कुछ ठीक करना है।

धन्यवाद

प्रोजेक्ट फ़ाइल पर कोई भी ऑपरेशन करने के लिए CLI टूल, अधिकांश परिदृश्यों के लिए आप फ़ाइल को संपादित नहीं करेंगे

:-1:

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

क्ली टूल्स ऑटोमेशन के लिए बहुत अच्छे हैं लेकिन npm install या dotnet restore जैसे बुनियादी कार्यों को छोड़कर कार्यों को करने का एक खराब तरीका है। अगर हमें dotnet buildoptions define add --framework net451 SOME_DEFINE जैसी चीजें सीखनी हैं तो यह निश्चित रूप से कठिन है। यह एक बहुत बड़ा नुकसान है।

एक अच्छी विकास कहानी है:

• आसानी से संपादन योग्य प्रोजेक्ट और फ़ाइलें बनाएं
• विन्यास योग्य निर्माण प्रणाली
• सरल, अच्छी तरह से डिज़ाइन किया गया और संपूर्ण क्ली टूल्स
• ग्रेट गुई, आईडीई टूल्स

उन गरीबों में से एक को (जो पहले वास्तव में महान था) एक दूसरे को स्वीकार्य बनाना बेवकूफी है।

एकता और xamarin तर्क वास्तव में काफी खराब है। मुझे नहीं लगता कि वे जल्द ही .net कोर में चले जाएंगे, और उनकी सुविधा के लिए पीछे जाना .net के भविष्य के लिए डिजाइन करते समय सिर्फ लंगड़ा है।

और चूंकि सभी .NET एक ही टूलिंग का उपयोग करते हैं, इसलिए हम MSBuild को बढ़ाने पर विचार कर सकते हैं

इससे पहले कि हम इसमें मजबूर हों, कोई MSBuild नहीं बढ़ाया जाए ...

यह लेख वास्तव में वह ब्लॉग पोस्ट नहीं है जिसका हम इंतजार कर रहे हैं और यह पुष्टि करता है कि .net कोर को वहां गुमराह किया जा रहा है।

क्ली टूल्स ऑटोमेशन के लिए बहुत अच्छे हैं लेकिन एनपीएम इंस्टाल या डॉटनेट रिस्टोर जैसे बुनियादी कार्यों को छोड़कर कार्यों को करने का एक खराब तरीका है।

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

मेरे लिए ऐसा लगता है कि एपीआई बनाने के लिए एक तरह के ढांचे की जरूरत है और फिर सीएलआई और जीयूआई संस्करण आपके लिए स्वचालित रूप से बनाए जाते हैं।

हम इसे कॉल कर सकते हैं... CLIGIUAPI! :+1: :+1: :+1: #समस्या का समाधान

यह मुद्दा संस्कृतियों/वरीयता/दर्शन का टकराव है

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

हो सकता है कि मैं इस पर अल्पसंख्यक हूं और शायद नहीं, लेकिन जब मुझे प्रोजेक्ट.जेसन पसंद है, तो यहां बताए गए कारण https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project -जेसन/ मेरे लिए बहुत मायने रखता है। मुझे पूरा विश्वास है कि हम एक अच्छे अनुभव के साथ समाप्त होंगे, इसलिए मैं वास्तव में इसके बारे में चिंतित नहीं हूं और यह किसी भी तरह से इन नए ढांचे के लिए मेरे उत्साह को कम नहीं करता है। लोग पिच के कांटे से बाहर निकलने के लिए बहुत जल्दी लगते हैं और ऐसा कार्य करते हैं जैसे कि यह दुनिया का अंत है, यह देखने से पहले कि अंतिम अनुभव क्या होगा

मैंने कुछ समय पहले पढ़ना बंद कर दिया है, लेकिन जैसे ही हमारे पास project.json बारे में एक निश्चित उत्तर होगा, मैं इस मुद्दे को बंद कर दूंगा।

Project.json और .csproj दोनों को कैसे रखा जाए, जहां .csproj कमांड dotnet restore द्वारा उत्पन्न होता है और डिफ़ॉल्ट रूप से संस्करण नियंत्रण में समन्वयित नहीं होता है? अंतर यह होगा कि dotnet restore "project.lock.json" उत्पन्न करने (और अन्य काम करने) के बजाय, यह ".csproj" फ़ाइल को जनरेट (या अपडेट) करेगा। यहां तक ​​कि दोनों "project.lock.json" और ".csproj" भी रह सकते हैं क्योंकि दोनों स्वतः उत्पन्न हो रहे हैं। .csproj जेनरेट करने के लिए झंडे का उपयोग dotnet restore में किया जा सकता है। घोषणा में, माइक्रोसॉफ्ट पहले से ही कह रहा है- "परियोजना फ़ाइल पर कोई भी संचालन करने के लिए सीएलआई उपकरण, अधिकांश परिदृश्य के लिए आप फ़ाइल को संपादित नहीं करेंगे"। IMHO, dotnet restore THAT CLI टूल होने के लिए सबसे उपयुक्त है, जो एक इनपुट के रूप में project.json लेगा। उल्टा होगा-

• project.json और .csproj दोनों प्रारूप अपरिवर्तित रह सकते हैं। इसका मतलब है कि नया जेनरेट किया गया .csproj विजुअल स्टूडियो के पुराने संस्करणों और अन्य टूल्स के साथ संगत होगा। dotnet restore .csproj फ़ाइल में प्रोजेक्ट फ़ाइलों की स्पष्ट "शामिल" सूची सम्मिलित कर सकता है।
• चूंकि .csproj स्वतः उत्पन्न हो रहा है और संस्करण नियंत्रण में नहीं है, इसलिए डेवलपर्स को .csproj को हाथ से संपादित करने और विलय करने की आवश्यकता नहीं है।

हाँ... नहीं।

समापन। जो कुछ कहा जा सकता था, वह सब कह दिया गया है।

यदि आप इस पर काम करना चाहते हैं कि इसे कैसे बनाया जाना चाहिए और इसके बारे में बात करने वाली डिज़ाइन टीम में होना चाहिए ... कृपया करें ।

अन्यथा, यह व्यर्थ स्थान है और विशेष रूप से... यह इनबॉक्स भर रहा है।

@MaximRouller आशा है कि आप उन टिप्पणियों को एकत्र करेंगे जो शोर की मात्रा के बावजूद आपके प्रारंभिक प्रश्नों के उत्तर देने पर ध्यान केंद्रित करती हैं।

कल पोस्ट किया गया:

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

@neoKushan क्या हमें "बिल्ड डेफिनिशन" से आपका क्या मतलब है, यह स्पष्ट करने की आवश्यकता है? शायद मेरी शब्दावली बंद है, लेकिन मैं वर्तमान प्रोजेक्ट.जेसन को एक बिल्ड डेफिनिशन फ़ाइल नहीं बल्कि एक प्रोजेक्ट डेफिनिशन फ़ाइल (और वही नई csproj फ़ाइल के लिए जाना होगा) नहीं कहूंगा। संभवतः शब्दार्थ, लेकिन मेरे लिए एक निर्माण परिभाषा से पता चलता है कि यह परिभाषित करता है कि चीजें कैसे बनाई जाती हैं, जबकि एक परियोजना परिभाषा परिभाषित करती है कि एक परियोजना क्या बनाती है और कुछ और चरणों का निर्माण करती है।

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

लेकिन, यह सब मूक लगता है: @MaximRouiller और MS ने सब कुछ बंद कर दिया है। आपके फ़ीडबैक को नज़रअंदाज़ कर दिया गया है और उसे समाप्त कर दिया गया है, कॉल करने के लिए धन्यवाद।

कुल मिलाकर, संपूर्ण csproj -> project.json -> csproj चीज़ खराब निर्णयों का एक समूह था जो .NET अपनाने वाले IMHO में MS को परेशान करने के लिए वापस आ जाएगा। हरित चरागाहों के लिए .NET छोड़ने वाले देवों की प्रवृत्ति बेरोकटोक जारी रहेगी।

बहुत दुख की बात है।

@shederman C# के लिए घटते Tiobe इंडेक्स और csproj पर वापस जाने के निर्णय के बीच कोई संबंध नहीं है। साथ ही घटते Tiobe सूचकांक C# पारिस्थितिकी तंत्र के गिरते स्वास्थ्य का संकेत नहीं है। बाजार में प्रवेश करने वाली अधिक भाषाएं किसी एक भाषा के लिए बड़ी बाजार हिस्सेदारी बनाए रखना कठिन बना देती हैं।

मैं समग्र रूप से प्रभाव पर स्पष्ट नहीं हूं, लेकिन मैं यह बताना चाहूंगा कि यहां चिंताओं का मूल्यांकन अलग होना चाहिए। अगर csproj का मतलब सिर्फ इसलिए है क्योंकि मैं एक फाइल जोड़ रहा हूं, मेरी टीम के साथी निर्माण प्रक्रिया से संबंधित अन्य प्रभावों के बारे में चिंतित हैं, तो हम नाव को याद कर रहे हैं।

csproj कुछ ऐसा है जिसे मैं सहन करता हूं, पसंद नहीं करता।

@jerometerry मैं यह नहीं कह रहा था कि इससे गिरावट आएगी। लेकिन .NET कोर में कई नवीन परिवर्तनों का उद्देश्य गिरावट को रोकना और AWS को हुए नुकसान को रोकना था। इन परिवर्तनों को धीरे-धीरे एक-एक करके दूर किया जा रहा है, और इस प्रकार .NET कोर डेवलपर्स को प्लेटफॉर्म पर लुभाने की अधिक से अधिक संभावना नहीं है।

इसके अलावा, खराब निर्णय लेने - जो कि आज से लेकर आज तक project.json शुरू करने के निर्णय के ठीक पीछे का पता लगाया जा सकता है, अच्छा नहीं है।

यदि एमएस अतीत पर ध्यान केंद्रित करने के लिए दृढ़ हैं, तो उन्हें भविष्य में हारने पर आश्चर्यचकित नहीं होना चाहिए। जिस सोच ने आपको समस्या में डाल दिया है, वह आपको इससे बाहर निकालने की संभावना नहीं है।

बाजार में प्रवेश करने वाली अधिक भाषाएं किसी एक भाषा के लिए बड़ी बाजार हिस्सेदारी बनाए रखना कठिन बना देती हैं।

सच है, लेकिन मेरे अनुभव में .NET में आवश्यकता से अधिक क्षति मैत्रीपूर्ण आग के कारण होती है।

BTW... क्या कल भी स्टैंडअप था? मैंने live.asp.net में साइन इन किया है लेकिन उलटी गिनती बस रीसेट हो गई है, बिना किसी वीडियो/फीड या कुछ भी ...

@ माइक-ईईई उन्होंने सुना कि आप आ रहे हैं: स्टक_आउट_टॉन्ग_विंकिंग_आई:

निराश होकर उन्होंने ऐसा किया। मैंने इसके बारे में ब्लॉग किया: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

आज के स्टैंडअप से: https://youtu.be/YJsQ3tnS7Ew?t=38m45s

वह यहां विशेष रूप से project.json को संबोधित करते हैं: https://youtu.be/YJsQ3tnS7Ew?t=26m12s

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

इसलिए जब प्रोजेक्ट प्रारूप dotnet कमांड लाइन टूल को हटाया जा रहा है, तो .NET Core RC1/2 को रिलीज़ उम्मीदवार कहना थोड़ा अजीब है। मेरे लिए यह अभी भी बीटा या अल्फा सॉफ्टवेयर है क्योंकि यह प्रायोगिक है।

वीनेक्स्ट में जाने के लिए मेरी मुख्य प्रेरणा सस्ते लिनक्स होस्टिंग और डॉकर का उपयोग करना है। एक प्रोजेक्ट माइग्रेशन टूल ASAP बुद्धिमान होगा क्योंकि अधिकांश लोग अपने पुस्तकालयों द्वारा पूरी तरह से विकलांग हो जाएंगे, नगेट संदर्भों के माध्यम से गायब .NET कोर संस्करण।

@yetanotherchris dnx

project.json अभी भी यहाँ है और rc2 के लिए आवश्यक है, RTM . के बाद भविष्य में इसके समाप्त होने के बारे में चर्चा

json.net उर्फ ​​newtonsoft.json काम करता है और ढांचे द्वारा ही उपयोग किया जाता है, मैं इसे अपनी परियोजनाओं में भी उपयोग करता हूं
nunit संगत नहीं है, हर कोई xunit afaik . का उपयोग करता है
स्ट्रक्चरमैप में और आरसी 2 संगत पुस्तकालय है

अभी भी बहुत सी तृतीय पक्ष चीजें हैं जिन्हें अभी तक आरसी 2 में पोर्ट नहीं किया गया है, लेकिन माइक्रोसॉफ्ट अन्य परियोजनाओं के समय को नियंत्रित नहीं करता है और जब वे संगत पुस्तकालय बनायेंगे

@yetanotherchris यदि आप अपने project.json में आयात का उपयोग करते हैं, तो आप पुराने, गैर-नेटस्टैंडर्ड मॉनीकर्स निर्दिष्ट कर सकते हैं और यह उनका उपयोग करेगा:

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

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

@joeaudette मैं शाखा के नाम (DNX) के बारे में बात कर रहा था न कि कमांड लाइन टूल dotnet । बहुत से लोग एनयूनीट का उपयोग करते हैं, यह एमएसटेस्ट के बाहर वास्तविक परीक्षण सूट है। मुझे यकीन नहीं है कि आप JSON.NET या स्ट्रक्चरमैप पैकेज कहां से ढूंढ रहे हैं, यहां डीएनएक्स नामक स्ट्रक्चरमैप का एक अनौपचारिक संस्करण है और यहां एक न्यूटनसॉफ्ट शाखा

@neoKushan धन्यवाद, मैं

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

@yetanotherchris

(.net मानक अब बेमानी है जहाँ तक मुझे पता है)।

क्या सोच कर तुम यह कह रहे हो? नेटस्टैंडर्ड परियोजना परिवर्तन से दूर नहीं जा रहा है, यह यहां रहने के लिए है। आप अपनी भविष्य की csproj फ़ाइलों में netstandards को लक्षित करने में सक्षम होंगे। नेटस्टैंडर्ड बिल्कुल जरूरी है। प्रोजेक्ट.जेसन को छोड़ने का एक मुख्य कारण पूरे .net पारिस्थितिकी तंत्र को एकीकृत करना है और यही कारण है कि नेटस्टैंडर्ड भी टेबल पर ला रहा है।

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

मैं इससे काफी हद तक सहमत हूं, हालांकि मुझे नहीं लगता कि यह उतना बदल रहा है जितना लोग सोचते हैं। एक शुरुआत के लिए, project.json अभी भी RTM के लिए यहाँ होने जा रहा है, उसके बाद सभी परिवर्तन होंगे। फिर आप पूछ सकते हैं कि अगर यह बदलने जा रहा है तो इसे "अंतिम" क्यों कहते हैं और शायद वहां एक बिंदु है, लेकिन आखिरकार आपके सभी कोड और पुस्तकालय और जो नहीं बदल रहे हैं, यह सिर्फ प्रोजेक्ट _definition_ है। यह उतना बड़ा बदलाव नहीं है जितना शुरू में कोई सोच सकता है, हालांकि निश्चित रूप से कुछ प्रवास का मज़ा होने वाला है।

@yetanotherchris आपको याद रखना होगा कि आरसी 2 पूर्वावलोकन है और इसलिए आपको तीसरे पक्ष से पूर्वावलोकन पैकेज भी देखना होगा
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

मैं NUnit के बारे में नहीं जानता कि क्या इसे बाद में समर्थित किया जाएगा लेकिन अभी के लिए .NET Core और ASP.NET Core प्रोजेक्ट्स पर लोग xunit का उपयोग कर रहे हैं
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris मुझे लगता है कि हम सभी सहमत हो सकते हैं कि आरसी 1 को बीटा 9 लेबल किया जाना चाहिए था, आरसी 2 पहली वास्तविक आरसी गुणवत्ता रिलीज है
project.json और इस तरह की टूलिंग प्रति से ढांचे का हिस्सा नहीं है, टूलिंग पूर्वावलोकन रहेगा और कुछ समय के लिए परिवर्तन के अधीन रहेगा, भले ही ढांचा आरटीएम हो

अगर हम वापस भी लाते हैं तो मुझे आश्चर्य भी नहीं होगा- हो सकता है कि हम एक प्रोजेक्ट.जेसन रखें, और यह केवल सीमित परिदृश्यों में ही काम करता है। अगर लोग यही चाहते हैं, तो हम उस विचार का मनोरंजन करेंगे।

स्कॉट हंटर, dotnetConf 2016 दिन 1 मुख्य वक्ता के रूप में 12m24s

क्या किसी को पता है कि मिस्टर हंटर GitHub पर है? और उत्पाद मंचों में बकबक की निगरानी? इसकी आवाज़ से, वह यहाँ प्रतिक्रिया को याद कर रहा है।

.NET और विजुअल स्टूडियो के प्रोग्राम मैनेजर के रूप में, मुझे संदेह है कि @coolcsh के पास ईमानदारी से खाली समय है।

अगर वह उस प्रतिक्रिया से अनजान है जो मुझे दी गई है तो मैं बहुत भयभीत हो जाऊंगा। शायद सभी विवरण नहीं, लेकिन निश्चित रूप से महत्वपूर्ण पुशबैक रहा है।

यहां आपके लिए हर कोई मौका है:
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

मैंने टिप जार में एक डॉलर रखा, इसलिए बोलने के लिए। :अटक_बाहर_जीभ:

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

जैसा कि मैंने कई बार कहा है, मैं एक प्रमुख बैंक में एक उद्यम डेवलपर हूं, एक उद्यम ग्राहक हूं। इन परिवर्तनों के बारे में हमसे सलाह नहीं ली गई थी। तो वास्तव में "डार्क मैटर एंटरप्राइज डेवलपर्स" कौन थे? वह जानकारी स्पष्ट रूप से शीर्ष, शीर्ष गुप्त है। 007 स्तर का सामान।

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

@shederman क्या आप एक उद्यम मोबाइल देव हैं, या उद्यम UWP देव हैं? या एंटरप्राइज यूनिटी देव?

इनमे से कोई भी नहीं। हम परिसंपत्ति प्रबंधन और बैंक एकीकरण के लिए कोर सिस्टम लिखते हैं। कुछ ऑनलाइन सामान भी।

@shederman मुझे संदेह है कि हो सकता है कि आपसे क्यों नहीं पूछा गया?

कृपया स्पष्ट करें?

क्या आप वास्तव में कह रहे हैं कि केवल कॉर्पोरेट देव जो एमएस अब समर्थन करते हैं, वे बाजार के 1% के लिए मोबाइल काम कर रहे हैं, उम के लिए यूडब्ल्यूपी ऐप्स, देखभाल करने वाले 5% उपयोगकर्ता और गेम विकास? विकास के पूरे स्पेक्ट्रम में से, एमएस हर चीज से मुंह मोड़ रहा है लेकिन वह ?

उम्म। नहीं।

मैं कह रहा हूं कि परिवर्तन उन _समूहों से बात करने के बाद आए, इसलिए आपसे नहीं पूछा गया। माइक्रोसॉफ्ट को सिर्फ एएसपी डेवलपर्स ही नहीं, बल्कि अपने सभी डेवलपर्स का समर्थन करना है।

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

तो, एक बड़े बैंक की राय सुनने के लिए, हमें अपने सभी विकास को यूडब्ल्यूपी/यूनिटी/मोबाइल पर स्विच करना होगा?

क्या बकवास है।

शायद उन्हें सभी डेवलपर्स से बात करनी चाहिए।

क्या वे पिछले 2+ वर्षों से यही नहीं कर रहे हैं?

@shederman तो सिर्फ इसलिए कि _आप व्यक्तिगत रूप से नहीं पूछे गए थे, आप यह कह रहे हैं कि आपकी विकास सीमा को कवर करने वाला कोई और शामिल नहीं था?

साथ ही, उन नंबरों को बनाना बंद करें - _that_ हास्यास्पद है।

@poke मैं पूछ रहा हूं कि कौन शामिल था? मैं कह रहा हूं कि मैंने सुना है कि एंटरप्राइज़ डार्क मैटर डेवलपर्स से परामर्श किया गया था, और बताया कि मैं बैंक में हूं, और हम नहीं थे, तो वास्तव में कौन था?

मैंने वास्तव में सोचा था कि संख्याएं काफी उदार थीं, लेकिन ठीक है।

@shederman मुझे लगता है कि आप इस पूरी चीज़ में बहुत अधिक देख रहे हैं। पिछले 2 वर्षों से पूरी तरह से asp.net चीजों पर ध्यान केंद्रित किया गया है, लेकिन जैसे-जैसे .net core का प्रसार शुरू हुआ, बहुत से लोगों ने पूछना शुरू कर दिया कि "मैं इसका उपयोग कैसे कर सकता हूं?"। यह कोई बैक रूम डील नहीं थी, यह लोग सचमुच वर्षों के लिए पूछ रहे देखने के लिए चारों ओर देखना होगा कि बहुत से लोग .net core से अधिक चाहते हैं।

बड़े संगठनों से वास्तविक उद्यम समर्थन अनुरोधों की बात भी है, जो यह जानना चाहते हैं कि क्रॉस-प्लेट होने के लिए अपने मौजूदा सामान को कैसे पोर्ट किया जाए - शायद आपसे "पूछा" नहीं गया क्योंकि आपको Microsoft से किसी को यह बताने की आवश्यकता नहीं थी कि क्या आप जो करने की कोशिश कर रहे हैं वह परियोजना के दायरे से बाहर है।

इसे देखने का एक और तरीका - और जिस तरह से मैं इसे व्यक्तिगत रूप से देखता हूं - क्या आपसे पूछा गया है, आपसे दूसरी घोषणा की गई थी जो महीनों पहले की गई थी। लोगों के सभी रोने के लिए यह कहते हुए कि निर्णय किसी से परामर्श किए बिना किए गए थे, Microsoft ने बार-बार कहा है कि वे अभी भी विवरणों पर काम कर रहे हैं, कि उनके पास अभी भी अंतिम टुकड़े एक साथ नहीं रखे गए हैं और अब आपकी राय व्यक्त करने का समय है । स्कॉट हंटर ने यहां तक ​​कहा कि अगर लोग _really_ project.json को एक विकल्प के रूप में चाहते हैं, तो वे इसे रखने पर विचार करेंगे। यदि आप मुझ पर विश्वास नहीं करते हैं तो dotnetconf मुख्य वक्ता के रूप में देखें।

@neoKushan मैं सराहना करता हूं कि स्कॉट ने यह कहते हुए थोड़ा पीछे हट गए कि वे इसे रखने पर विचार करेंगे, लेकिन लोगों को यह व्यक्त करने के लिए वास्तव में एक एकल, केंद्रीकृत बिंदु होने की आवश्यकता है कि वे यही चाहते हैं अन्यथा project.json मुद्दा पॉप अप करता रहेगा हर जगह चर्चा। इसका मतलब यह भी है कि जब इसे लाया जाता है तो हर कोई उसी के साथ जवाब दे सकता है "अरे, अगर डेवलपर्स वास्तव में इसे चाहते हैं तो वे इसे रखने पर विचार करेंगे, यहां आप उन्हें बताने के लिए जाते हैं"।

project.json एक अच्छा कदम था। लेकिन मेरी राय में यह भोला था। यह संज्ञान में नहीं आता है कि लोग सी ++ या एफ # में लिखी गई हाइब्रिड परियोजनाएं चाहते हैं। उनके कुछ शुरुआती डिजाइन निर्णय जैसे dnx और नगेट को असेंबली की इकाई के रूप में उपयोग करना समग्र रूप से डॉटनेट पारिस्थितिकी तंत्र के लिए संभव नहीं था। आप जो देख रहे हैं, वह यह है कि डॉटनेट में तालमेल बिठाने की प्रक्रिया में, उन्हें ये कठिन चुनाव करने पड़ते हैं।

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

मुझे पूरा एक्सएमएल बनाम जेएसओएन तर्क मूर्खतापूर्ण लगता है क्योंकि एक और 5 वर्षों में, यह जेएसओएन बनाम वाईएएमएल और उसके बाद वाईएएमएल बनाम ग्रोवी (उदाहरण के लिए ग्रेडल) होगा। एक्सएमएल उतना बुरा नहीं है जितना आप सब इसे समझते हैं। MSBuild बहुत परिपक्व है और इसमें बहुत अधिक निवेश है जिससे सभी को लाभ होगा।

उस ने कहा, एमएसबिल्ड के साथ

मेरे लिए, मैं project.json को याद करूंगा, लेकिन उन कारणों से नहीं जो आपको लगता है .. C# प्रोजेक्ट ठीक रहेगा। मैं इसे F# की वजह से याद करूंगा क्योंकि मैंने msbuild को संपादित करने के बजाय संकलन आदेश के लिए project.json को संपादित करना पसंद किया। फिर से इसलिए नहीं कि xml बुरा है, बल्कि इसलिए कि fsproj फाइलों में msbuild द्वारा बहुत अधिक ब्लोट लाया गया है

इस निर्णय के साथ मेरी समस्या मुख्य रूप से जिस तरह से csproj फ़ाइल xml/json के बारे में कम थी और csproj फ़ाइल में शामिल करने के लिए उन्होंने जो चुना था, उससे कहीं अधिक था। इसमें प्रोजेक्ट परिभाषा शामिल है, इसमें आईडीई सेटिंग्स शामिल हैं, इसमें बिल्ड चरण शामिल हैं, इसमें संदर्भ शामिल हैं ...

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

मैं इससे सहमत हु। दिन के अंत में, csproj के साथ मुख्य मुद्दा यह है कि
यह सब कुछ करता है।

मुझे मध्य मैदान पसंद है पैट्रियट बॉब सुझाव दे रहा है ...

मंगल, जून 21, 2016 को 1:28 pm पर PatriotBob [email protected] लिखा है:

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

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911, या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

पूरा एक्सएमएल खराब है, जेएसओएन बहुत अच्छा है हुपला अत्यधिक प्रचारित था। पैट्रियटबोबो जो कह रहा है वह मुझे पसंद है।

npm के package.json से पूरी तरह से /w प्रोजेक्ट के रूप में प्रबंधन ने कभी भी इतना सरल और संक्षिप्त रूप से मेरी परियोजना की घोषणा नहीं की, मेरी परियोजना का निर्माण किया, मेरे प्रोजेक्ट को अपग्रेड किया (उदाहरण के लिए ग्रीनकीपर), डेटा पढ़ना/लिखना/पार्स करना मेरी परियोजना के बारे में, और मेरी परियोजना को प्रकाशित करना इतना आसान है। _इतना आसान। हम में से कई, मेरा इतिहास सी ++/जावा/पायथन/नोड में है, दूसरों में खेलने के साथ। मैं अब अपनी सभी परियोजनाओं में npm अनुभव के लिए तरस रहा हूं।

project.json ने इन्हीं विशेषताओं को प्राप्त करने का वादा किया था। मुझे लगता है कि यह अनुकरण करने लायक मॉडल है, न कि सादगी और शक्ति का त्याग।

अगर टीम .net कोर टीम को लगता है कि दूसरा समाधान उन्हें ये गुण, उत्कृष्ट और शक्ति प्रदान कर सकता है! हालाँकि, जैसे-जैसे आप आगे बढ़ते हैं, कृपया सादगी में सुंदरता को कम न करें।

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