पीवीएस-स्टूडियो में विजुअल स्टूडियो 2019 का समर्थन

पीवीएस-स्टूडियो में विज़ुअल स्टूडियो 2019 के समर्थन ने कई घटकों को प्रभावित किया: प्लगइन ही, कमांड-लाइन विश्लेषक, C ++ और C # analyzers की कोर, और कुछ उपयोगिताओं। इस लेख में, मैं संक्षेप में बताऊंगा कि आईडीई के समर्थन को लागू करते समय हमें किन समस्याओं का सामना करना पड़ा और हमने उन्हें कैसे संबोधित किया।

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

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

विजुअल स्टूडियो 2017 जारी होने पर चीजें बदल गईं। IDE के कई API एक्सटेंशन में भारी बदलाव के अलावा, हमें कुछ समय पहले ही जोड़े गए नए C # विश्लेषक की पिछड़ी अनुकूलता बनाए रखने में भी समस्या का सामना करना पड़ा (साथ ही साथ MSBuild परियोजनाओं के साथ काम करने के लिए C ++ के लिए नए विश्लेषक परत के साथ MSBuild \ Visual Studio के नए संस्करण।

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

उन समस्याओं से निपटने के अंत में विश्लेषक के लिए महत्वपूर्ण परिवर्तन हुए, और हम उम्मीद कर रहे थे कि लागू किए गए नए दृष्टिकोण हमें विज़ुअल स्टूडियो \ MSBuild के भविष्य के संस्करणों का समर्थन करने में बहुत आसान और तेज़ी से मदद करेंगे। यह आशा पहले से ही वास्तविक साबित होने लगी थी क्योंकि विजुअल स्टूडियो 2017 के कई अपडेट जारी किए गए थे। क्या नए दृष्टिकोण ने विजुअल स्टूडियो 2019 के समर्थन में हमारी मदद की? जानने के लिए आगे पढ़ें।

विजुअल स्टूडियो 2019 के लिए पीवीएस-स्टूडियो प्लगइन

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

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

दूसरी समस्या निम्नलिखित संदेश थी जो विज़ुअल स्टूडियो को प्लगइन सक्षम करने के दौरान लोड करते समय हमें मिलती रही: विजुअल स्टूडियो ने एक या एक से अधिक एक्सटेंशन का पता लगाया है जो कि जोखिम या फीचर वीएस अपडेट में काम नहीं कर रहे हैं।

विजुअल स्टूडियो लॉन्च (एक्टिविटीलॉग फ़ाइल) के लॉग ने इसे साफ़ करने में मदद की:

चेतावनी: एक्सटेंशन 'पीवीएस-स्टूडियो' विज़ुअल स्टूडियो की 'सिंक्रोनस ऑटो-लोड' सुविधा का उपयोग करता है। यह सुविधा अब भविष्य के Visual Studio 2019 अद्यतन में समर्थित नहीं होगी, जिस बिंदु पर यह एक्सटेंशन काम नहीं करेगा। अपडेट पाने के लिए कृपया विस्तार विक्रेता से संपर्क करें।

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

Microsoft द्वारा अतुल्यकालिक रूप से प्लग-इन लोड करने के बारे में Microsoft द्वारा एक लेख है: " कैसे करें: पृष्ठभूमि में VSPackages को लोड करने के लिए AsyncPackage का उपयोग करें "। हालाँकि, यह पहले से ही स्पष्ट था कि इसमें और बदलाव आने थे।

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

अमूर्त वर्ग AsyncPackage की प्रारंभिक विधि, जिसमें से अतुल्यकालिक रूप से लोड हो रहे प्लग इन को सील कर दिया जाता है , इसलिए आरंभिक तरीके से ओवरराइड पद्धति में किया जाना है InitializeAsync , जो कि हमने ठीक किया है। 'ज़ोंबी' चेक लॉजिक को भी बदलना पड़ा क्योंकि स्टेटस की जानकारी अब हमारे प्लगइन के लिए उपलब्ध नहीं थी। इसके अलावा, हमें अभी भी उन कार्यों को करना था जो कि प्लगइन इनिशियलाइज़ेशन के बाद किए जाने थे। हमने IVsPackageLoadEvents इंटरफ़ेस के OnPackageLoaded पद्धति का उपयोग करके हल किया, जो कि उन विलंबित क्रियाओं को निष्पादित किया गया था।

एसिंक्रोनस लोड के परिणामस्वरूप एक और समस्या यह थी कि प्लगइन के कमांड का उपयोग तब तक नहीं किया जा सकता था जब तक कि विजुअल स्टूडियो लोड न हो। फाइल मैनेजर में डबल क्लिक करके एनालाइजर लॉग खोलना (यदि आपको विजुअल स्टूडियो से इसे खोलने की जरूरत है) जिसके परिणामस्वरूप लॉग को खोलने के लिए कमांड के साथ devenv.exe का संबंधित संस्करण लॉन्च किया गया। लॉन्च कमांड कुछ इस तरह दिखी:

"C:\Program Files (x86)\Microsoft Visual Studio\ 2017\Community\Common7\IDE\devenv.exe" /command "PVSStudio.OpenAnalysisReport C:\Users\vasiliev\source\repos\ConsoleApp\ConsoleApp.plog" 

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

काहे, लगता है जैसे हमने इसे आखिरी में बनाया था; प्लगइन बिना किसी चेतावनी के लोड और खुलता है।

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

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

थोड़ी देर के लिए VSIXInstaller के साथ छेड़छाड़ करने के बाद, हम यह पता लगाने में कामयाब रहे कि समस्या को पैकेज कैश के साथ क्या करना था। इस सिद्धांत को इस तथ्य का भी समर्थन किया गया था कि लॉग में एक त्रुटि संदेश आउटपुट करने के लिए VSIXInstaller के कारण कैश्ड पैकेज (C: \ ProgramData \ Microsoft \ VisualStudio \ Package) तक पहुंच को प्रतिबंधित किया गया था। उत्सुकता से पर्याप्त, जब त्रुटि नहीं हुई, तो कैश्ड पैकेजों को स्थापित करने के बारे में जानकारी दिखाई नहीं दी।

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

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

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

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

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

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

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

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

सी # 8.0 का समर्थन

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

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

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

अशक्त संदर्भ प्रकारों और संबंधित वाक्यविन्यास का उपयोग करना आपको बहुत दिलचस्प कोड लिखने में सक्षम बनाता है। हमने इसे "भावनात्मक वाक्यविन्यास" नाम दिया है। यह स्निपेट पूरी तरह से संकलित है:

 obj.Calculate(); obj?.Calculate(); obj.Calculate(); obj!?.Calculate(); obj!!!.Calculate(); 

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

 object temp = null! 

लेकिन यह भी इस तरह:

 object temp = null!!!; 

और, इसे और भी आगे बढ़ाते हुए, आप इस तरह से पागल बातें लिख सकते हैं:

 object temp = null!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!; 

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

विफलता रिपोर्ट को इवेंट व्यूअर से निकाला जा सकता है:

 Faulting application name: devenv.exe, version: 16.0.28803.352, time stamp: 0x5cc37012 Faulting module name: WindowsBase.ni.dll, version: 4.8.3745.0, time stamp: 0x5c5bab63 Exception code: 0xc00000fd Fault offset: 0x000c9af4 Faulting process id: 0x3274 Faulting application start time: 0x01d5095e7259362e Faulting application path: C:\Program Files (x86)\ Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe Faulting module path: C:\WINDOWS\assembly\NativeImages_v4.0.30319_32\ WindowsBase\4480dfedf0d7b4329838f4bbf953027d\WindowsBase.ni.dll Report Id: 66d41eb2-c658-486d-b417-02961d9c3e4f Faulting package full name: Faulting package-relative application ID: 

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

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

टूलसेट

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

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

डायग्नोस्टिक्स का परीक्षण करते समय एक अंतर को तुरंत देखा गया: मौजूदा नोड पर सिंटैक्स ट्री की संरचना बदल गई। बड़ी बात नहीं; हमने तय किया कि जल्दी से।

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

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

आप में से जिन्होंने विज़ुअल स्टूडियो 2017 के समर्थन के बारे में लेख को ध्यान से पढ़ा है, उन्हें याद है कि हमारा वितरण डमी के साथ आता है - 0 बाइट्स की MSBuild.exe फ़ाइल।

अब हमें इस अभ्यास को और भी आगे बढ़ाना था और संकलक csc.exe, vbc.exe, और VBCSCompiler.exe के लिए खाली डमीज़ शामिल करना था। क्यों? हम अपने परीक्षण आधार में से एक परियोजना का विश्लेषण करने और अलग-अलग रिपोर्ट प्राप्त करने के बाद इस समाधान के साथ आए: विश्लेषक का नया संस्करण अपेक्षित चेतावनियों में से कुछ का उत्पादन नहीं करेगा।

हमने पाया कि इसे सशर्त संकलन प्रतीकों के साथ करना था, जिनमें से कुछ को विश्लेषक के नए संस्करण का उपयोग करते समय ठीक से नहीं निकाला गया था। समस्या की जड़ में जाने के लिए, हमें रोजलिन के पुस्तकालयों के कोड में गहराई से खुदाई करनी पड़ी।

सशर्त संकलन प्रतीकों को पुस्तकालय Microsoft से वर्ग Csc के GetDefineConstantsSwitch विधि का उपयोग करके पार्स किया जाता है। पार्सिंग को कई विभाजकों पर String.Split विधि का उपयोग करके किया जाता है:

 string[] allIdentifiers = originalDefineConstants.Split(new char[] { ',', ';', ' ' }); 

यह पार्सिंग तंत्र पूरी तरह से काम करता है; सभी सशर्त संकलन प्रतीकों को सही ढंग से निकाला जाता है। ठीक है, चलो खुदाई करते रहो।

अगला मुख्य बिंदु क्लास टूलटैस्क के ComputePathToTool विधि का कॉल था। यह विधि निष्पादन योग्य फ़ाइल ( csc.exe ) के लिए पथ की गणना करती है और जांचती है कि क्या यह है। यदि हां, तो विधि इसे वापस करने के लिए या अन्यथा अशक्त है।

कॉलिंग कोड:

 .... string pathToTool = ComputePathToTool(); if (pathToTool == null) { // An appropriate error should have been logged already. return false; } .... 

चूंकि कोई csc.exe फ़ाइल नहीं है (हमें इसकी आवश्यकता क्यों है?), PathToTool को इस बिंदु पर मान नल दिया गया है, और वर्तमान विधि ( ToolTask.Execute ) गलत है । निकाले गए सशर्त संकलन प्रतीकों सहित कार्य को निष्पादित करने के परिणामों को अनदेखा किया जाता है।

ठीक है, चलो देखते हैं कि अगर हम csc.exe फ़ाइल डालते हैं तो क्या होता है।

अब pathToTool वास्तविक पथ को अब-वर्तमान फ़ाइल में संग्रहीत करता है, और ToolTask.Execute निष्पादित करता रहता है। अगला मुख्य बिंदु ManagedCompiler की कॉल है। ExecuteTool विधि:

 protected override int ExecuteTool(string pathToTool, string responseFileCommands, string commandLineCommands) { if (ProvideCommandLineArgs) { CommandLineArgs = GetArguments(commandLineCommands, responseFileCommands) .Select(arg => new TaskItem(arg)).ToArray(); } if (SkipCompilerExecution) { return 0; } .... } 

SkipCompilerExecution गुण सत्य है (तार्किक रूप से पर्याप्त है क्योंकि हम वास्तविक के लिए संकलन नहीं कर रहे हैं)। कॉलिंग विधि (पहले से उल्लिखित ToolTask.Execute ) जाँचता है कि क्या ExecuteTool का रिटर्न मान 0 है और यदि ऐसा है, तो सही है । चाहे आपका csc.exe एक वास्तविक संकलक था या लियो टॉल्स्टॉय द्वारा "युद्ध और शांति" कोई फर्क नहीं पड़ता।

इसलिए, समस्या को उस क्रम से करना होगा जिसमें कदम परिभाषित किए गए थे:

• संकलक के लिए जांच;
• जाँच करें कि क्या कंपाइलर लॉन्च किया जाना चाहिए;

और हम एक रिवर्स ऑर्डर की उम्मीद करेंगे। इसे ठीक करना है कि संकलक के लिए डमी जोड़े गए।

ठीक है, लेकिन हमने csc.exe फ़ाइल अनुपस्थित (और कार्य परिणामों पर ध्यान नहीं दिया) के साथ संकलन प्रतीकों को कैसे प्राप्त किया?

ठीक है, इस मामले के लिए एक विधि भी है: CSharpCommandLineParser.ParseConditionalCompilationSymbols लाइब्रेरी से Microsoft.CodeAnalysis.CSharp । यह, भी, कई अलग-अलग विभाजकों पर String.Split विधि को कॉल करके पार्सिंग करता है:

 string[] values = value.Split(new char[] { ';', ',' } /*, StringSplitOptions.RemoveEmptyEntries*/); 

देखें कि कैसे विभाजकों का यह सेट Csc.GetDefineConstantsSwitch विधि द्वारा संभाला गया है? यहाँ, एक स्पेस विभाजक नहीं है। इसका मतलब है कि रिक्त स्थान द्वारा अलग किए गए सशर्त संकलन प्रतीकों को इस विधि द्वारा ठीक से पार्स नहीं किया जाएगा।

ऐसा तब हुआ जब हम समस्या परियोजनाओं की जाँच कर रहे थे: उन्होंने अंतरिक्ष-पृथक सशर्त संकलन प्रतीकों का उपयोग किया और इसलिए, GetDefineConstantsSwitch विधि द्वारा सफलतापूर्वक पार्स किया गया, लेकिन ParseConditionalCompilationSolbols विधि नहीं।

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

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

रोसलिन परियोजना के नए संस्करण की जाँच करते समय हमने इसका सामना किया: पुस्तकालयों में से एक NullReferenceException को फेंक रहा था। इसके स्रोत के बारे में विस्तृत जानकारी के लिए धन्यवाद, हमने जल्दी से समस्या स्रोत कोड पाया और - बस जिज्ञासा के लिए - यह देखने का फैसला किया कि क्या दृश्य स्टूडियो में काम करते समय त्रुटि बनी रहेगी।

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

 class C1<T1, T2> { void foo() { T1 val = default; if (val is null) { } } } 

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

 Application: devenv.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.NullReferenceException at Microsoft.CodeAnalysis.CSharp.ConversionsBase. ClassifyImplicitBuiltInConversionSlow( Microsoft.CodeAnalysis.CSharp.Symbols.TypeSymbol, Microsoft.CodeAnalysis.CSharp.Symbols.TypeSymbol, System.Collections.Generic.HashSet'1 <Microsoft.CodeAnalysis.DiagnosticInfo> ByRef) at Microsoft.CodeAnalysis.CSharp.ConversionsBase.ClassifyBuiltInConversion( Microsoft.CodeAnalysis.CSharp.Symbols.TypeSymbol, Microsoft.CodeAnalysis.CSharp.Symbols.TypeSymbol, System.Collections.Generic.HashSet'1 <Microsoft.CodeAnalysis.DiagnosticInfo> ByRef) at Microsoft.CodeAnalysis.CSharp.CSharpSemanticModel.GetTypeInfoForNode( Microsoft.CodeAnalysis.CSharp.BoundNode, Microsoft.CodeAnalysis.CSharp.BoundNode, Microsoft.CodeAnalysis.CSharp.BoundNode) at Microsoft.CodeAnalysis.CSharp.MemberSemanticModel.GetTypeInfoWorker( Microsoft.CodeAnalysis.CSharp.CSharpSyntaxNode, System.Threading.CancellationToken) at Microsoft.CodeAnalysis.CSharp.SyntaxTreeSemanticModel.GetTypeInfoWorker( Microsoft.CodeAnalysis.CSharp.CSharpSyntaxNode, System.Threading.CancellationToken) at Microsoft.CodeAnalysis.CSharp.CSharpSemanticModel.GetTypeInfo( Microsoft.CodeAnalysis.CSharp.Syntax.PatternSyntax, System.Threading.CancellationToken) at Microsoft.CodeAnalysis.CSharp.CSharpSemanticModel.GetTypeInfoFromNode( Microsoft.CodeAnalysis.SyntaxNode, System.Threading.CancellationToken) at Microsoft.CodeAnalysis.CSharp.CSharpSemanticModel.GetTypeInfoCore( Microsoft.CodeAnalysis.SyntaxNode, System.Threading.CancellationToken) .... 

जैसा कि आप देख सकते हैं, समस्या अशक्त संदर्भ के कारण होती है।

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

यह अंततः हमें ClassifyImplicitBuiltInConversionSlow विधि में ले जाएगा जो स्टैक के ऊपर उल्लिखित है:

 private Conversion ClassifyImplicitBuiltInConversionSlow( TypeSymbol source, TypeSymbol destination, ref HashSet<DiagnosticInfo> useSiteDiagnostics) { Debug.Assert((object)source != null); Debug.Assert((object)destination != null); if (source.SpecialType == SpecialType.System_Void || destination.SpecialType == SpecialType.System_Void) { return Conversion.NoConversion; } Conversion conversion = ClassifyStandardImplicitConversion(source, destination, ref useSiteDiagnostics); if (conversion.Exists) { return conversion; } return Conversion.NoConversion; } 

यहां, गंतव्य पैरामीटर अशक्त है , इसलिए गंतव्य को कॉल कर रहा है । विशेष प्रकार का परिणाम NullReferenceException को फेंकने में परिणाम है। हां, डीरेफेरेंस ऑपरेशन डीबग.एसटर द्वारा पहले से किया गया है, लेकिन यह मदद नहीं करता है क्योंकि वास्तव में यह किसी भी चीज से रक्षा नहीं करता है - यह आपको पुस्तकालयों के डिबग संस्करणों में समस्या को हल करने की अनुमति देता है। या यह नहीं है।

C ++ परियोजनाओं के मूल्यांकन के तंत्र में परिवर्तन

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

पहला यह था कि हमें उन एल्गोरिदम को संशोधित करना था जो कि टूलवार्ड के संख्यात्मक मान पर निर्भर थे। विवरण में जाने के बिना, कुछ मामले हैं जब आपको टूलसेट की तुलना करने और सबसे हाल के संस्करण का चयन करने की आवश्यकता होती है। नए संस्करण, स्वाभाविक रूप से, एक बड़ा मूल्य है। हमें उम्मीद थी कि नए MSBuild / Visual Studio के लिए ToolVersion का मूल्य 16.0 होगा। हाँ, ज़रूर! नीचे दी गई तालिका में दिखाया गया है कि विज़ुअल स्टूडियो के विकास के इतिहास में विभिन्न गुणों के मूल्य कैसे बदल गए:

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

हमने टूलसेट के लिए प्राथमिकता जोड़कर (अर्थात एक अलग इकाई के रूप में प्राथमिकता से एकलिंग) को आसानी से हल किया।

दूसरे समस्या में Visual Studio 2017 या संबंधित वातावरण (उदाहरण के लिए, जब VisualStudioVersion पर्यावरण चर सेट है) में काम करने के साथ समस्याएं शामिल थीं। ऐसा इसलिए होता है क्योंकि C ++ प्रोजेक्ट का मूल्यांकन करने के लिए आवश्यक कंप्यूटिंग पैरामीटर एक .NET प्रोजेक्ट का मूल्यांकन करने की तुलना में बहुत अधिक कठिन कार्य है। .NET के लिए, हम अपने स्वयं के टूलसेट और टूलव्यू के संबंधित मान का उपयोग करते हैं। C ++ के लिए, हम अपने स्वयं के टूलसेट और सिस्टम द्वारा प्रदान किए गए दोनों का उपयोग कर सकते हैं। Visual Studio 2017 के लिए बिल्ड टूल के साथ शुरू, टूलसेट को रजिस्ट्री के बजाय MSBuild.exe.config फ़ाइल में परिभाषित किया गया है। इसलिए हम उन्हें टूलसेट की वैश्विक सूची ( Microsoft.Build.Evaluation.ProjectCollection.GlobalProjectCollection.Toolsets का उपयोग करके, उदाहरण के लिए) रजिस्ट्री में परिभाषित उन लोगों के विपरीत नहीं कर सकते हैं (जैसे कि Visual Studio 2015 और पूर्व में)।

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

C # .NET कोर परियोजनाओं के मूल्यांकन के तंत्र में परिवर्तन

इस कार्य में दो परस्पर संबंधित मुद्दे शामिल थे:

• विजुअल स्टूडियो 2017 में .NET कोर प्रोजेक्ट्स के 'करंट' टूलसेट को तोड़कर विश्लेषण जोड़ा गया;
• विश्लेषण Visual Studio की कम से कम एक प्रति स्थापित किए बिना सिस्टम पर .NET कोर परियोजनाओं के लिए काम नहीं करेगा।

दोनों समस्याएं एक ही स्रोत से आ रही थीं: कुछ बेस .targets / .props फ़ाइलों को गलत रास्तों पर देखा गया था। इसने हमें अपने टूलसेट का उपयोग करके किसी परियोजना का मूल्यांकन करने से रोका।

यदि आपके पास कोई विजुअल स्टूडियो इंस्टॉलेशन स्थापित नहीं था, तो आपको निम्न त्रुटि मिलेगी (पिछले टूलसेट संस्करण के साथ, 15.0 ) -

 The imported project "C:\Windows\Microsoft.NET\Framework64\ 15.0\Microsoft.Common.props" was not found. 

विजुअल स्टूडियो 2017 में C # .NET कोर प्रोजेक्ट का मूल्यांकन करते समय, आपको निम्न त्रुटि मिलेगी (वर्तमान टूलसेट संस्करण, वर्तमान के साथ ):

 The imported project "C:\Program Files (x86)\Microsoft Visual Studio\ 2017\Community\MSBuild\Current\Microsoft.Common.props" was not found. .... 

चूंकि ये समस्याएं समान हैं (जो वे प्रतीत होते हैं), हम एक पत्थर से दो पक्षियों को मारने की कोशिश कर सकते थे।

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

अब, हमने उस समस्या को कैसे हल किया? हमने अपने अपने टूलसेट को .NET कोर SDK ( Sdk.props , Sdk.targets ) से बेस .targets / .props फ़ाइलों के साथ विस्तारित किया। इसने हमें स्थिति पर अधिक नियंत्रण दिया और आयात प्रबंधन में अधिक लचीलापन के साथ-साथ सामान्य रूप से .NET कोर परियोजनाओं का मूल्यांकन किया। हां, हमारा टूलसेट फिर से थोड़ा बड़ा हो गया, और हमें .NET कोर परियोजनाओं के मूल्यांकन के लिए आवश्यक वातावरण स्थापित करने के लिए तर्क भी जोड़ना था, लेकिन यह इसके लायक लगता है।

तब तक, हमने मूल्यांकन करने का अनुरोध करके और काम करने के लिए MSBuild पर भरोसा करके .NET कोर परियोजनाओं का मूल्यांकन किया था।

अब जब हमारा स्थिति पर अधिक नियंत्रण था, तंत्र थोड़ा बदल गया:

• .NET कोर परियोजनाओं के मूल्यांकन के लिए आवश्यक वातावरण स्थापित करना;
• मूल्यांकन:
  • हमारे टूलसेट से .targets / .props फ़ाइलों का उपयोग करके मूल्यांकन शुरू करें;
  • बाहरी फ़ाइलों का उपयोग करके मूल्यांकन जारी रखें।

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

• हमारे टूलसेट से .targets / .props फ़ाइलों का उपयोग करके मूल्यांकन आरंभ करें;
• बाह्य .targets / .props फ़ाइलों के लिए सभी बाद के ऑपरेशनों को पुनर्निर्देशित करें।

एक विशेष पुस्तकालय Microsoft.DotNet.MSBuildSdkResolver आवश्यक .targets / .props फ़ाइलों को देखने के लिए उपयोग किया जाता है। अपने टूलसेट से फ़ाइलों का उपयोग करके पर्यावरण की स्थापना शुरू करने के लिए, हमने उस लाइब्रेरी द्वारा उपयोग किए जाने वाले एक विशेष पर्यावरण चर का उपयोग किया ताकि हम उस स्रोत पर इंगित कर सकें जहां से आवश्यक फाइलों को आयात किया जा सके (यानी हमारे टूलसेट)। चूंकि लाइब्रेरी को हमारे वितरण में शामिल किया गया है, इसलिए अचानक तर्क विफलता का कोई जोखिम नहीं है।

अब हमारे पास पहले आयातित हमारे टूलसेट से Sdk फाइलें हैं, और चूंकि हम उन्हें आसानी से बदल सकते हैं, इसलिए हम बाकी मूल्यांकन तर्क को पूरी तरह से नियंत्रित करते हैं। इसका मतलब है कि अब हम यह तय कर सकते हैं कि कौन सी फाइलें और किस स्थान से आयात की जाए। यह Microsoft.Common.props के ऊपर लागू होता है। हम अपने टूलसेट से इस और अन्य बेस फ़ाइलों को आयात करते हैं ताकि हमें उनके अस्तित्व या सामग्री के बारे में चिंता न करनी पड़े।

एक बार जब सभी आवश्यक आयात किए जाते हैं और गुण सेट हो जाते हैं, तो हम मूल्यांकन प्रक्रिया पर वास्तविक .NET कोर SDK पर नियंत्रण पारित करते हैं, जहां सभी आवश्यक आवश्यक संचालन किए जाते हैं।

निष्कर्ष

विज़ुअल स्टूडियो 2019 का समर्थन आमतौर पर कई कारणों से विज़ुअल स्टूडियो 2017 का समर्थन करने से आसान था। सबसे पहले, Microsoft ने Visual Studio 2015 से Visual Studio 2017 में अपडेट करते समय जितनी चीज़ें देखीं, उतनी नहीं बदलीं। हाँ, उन्होंने आधार टूलसेट को बदल दिया और Visual Studio प्लगइन्स को अतुल्यकालिक लोड मोड पर स्विच करने के लिए मजबूर किया, लेकिन यह परिवर्तन नहीं था। वह कठोर। दूसरा, हमारे पास पहले से ही तैयार समाधान था जिसमें हमारे अपने टूलसेट और परियोजना मूल्यांकन तंत्र शामिल थे और हमें बस इसे खरोंच से काम नहीं करना था - केवल हमारे पास पहले से ही जो था उस पर निर्माण करें। हमारी परियोजना मूल्यांकन प्रणाली का विस्तार करके नई स्थितियों के तहत .NET कोर परियोजनाओं के समर्थन की अपेक्षाकृत दर्द रहित प्रक्रिया (और बिना विजुअल स्टूडियो कॉपियों वाले कंप्यूटरों पर) हमें यह भी उम्मीद दिलाती है कि हमने कुछ नियंत्रण में ले कर सही विकल्प बनाया है। हमारे हाथ।

लेकिन मैं पिछले लेख में बताए गए विचार को दोहराना चाहूंगा: कभी-कभी तैयार किए गए समाधानों का उपयोग करना उतना आसान नहीं है जितना यह लग सकता है।