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

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

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

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

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

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

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

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

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

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

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

विज़ुअल स्टूडियो स्टार्टअप लॉग्स (एक्टिविटीलॉग फाइल) को देखना आखिरकार 'i':

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

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

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

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

AsyncPackage अमूर्त वर्ग में, जिसमें से अतुल्यकालिक रूप से लोड किए गए प्लग इनहेरिट किए जाते हैं, आरंभिक विधि में एक सील संशोधक होता है, इसलिए आरंभिक ओवरराइज्ड आरंभिक विधि में किया जाना चाहिए, जो किया गया था। हमें विजुअल स्टूडियो की 'जॉम्बी' स्थिति को ट्रैक करने के साथ तर्क को भी बदलना पड़ा, क्योंकि हमने प्लगइन में यह जानकारी प्राप्त करना बंद कर दिया था। हालाँकि, प्लगइन शुरू होने के बाद किए जाने वाले कई कार्यों को करने की आवश्यकता नहीं थी। समाधान 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" 

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

फू, ऐसा लगता है कि हल किया गया है और सब कुछ काम करता है - सब कुछ लोड होता है और सही ढंग से खुलता है, कोई चेतावनी नहीं है - अंत में।

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

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

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

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

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

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

इस समस्या को हल करने और भविष्य में इसी तरह की स्थितियों से बचने के लिए, विज़ुअल स्टूडियो 2017 और विज़ुअल स्टूडियो 2019 पैकेजों को अलग करने के लिए नए पैकेज के लिए एक GUID बनाने का निर्णय लिया गया था (पुराने पैकेजों के साथ ऐसी कोई समस्या नहीं है, और उन्होंने हमेशा एक सामान्य GUID का उपयोग किया है)।

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

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

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

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

समर्थन सी # 8.0

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

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

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

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

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

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

 object temp = null! 

लेकिन यह भी:

 object temp = null!!!; 

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

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

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

आप ईवेंट व्यूअर से समस्या के बारे में जानकारी प्राप्त कर सकते हैं:

 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 परियोजनाओं के बारे में बातचीत के संदर्भ में 'मूल्यांकन' शब्द के अनुवाद की समस्या का सामना करना पड़ रहा है। अनुवाद, जो अर्थ में निकटतम था और एक ही समय में सामान्य लग रहा था, "एक परियोजना मॉडल का निर्माण कर रहा था"। यदि आपके पास वैकल्पिक अनुवाद विकल्प हैं - तो आप मुझे लिख सकते हैं, यह पढ़ना दिलचस्प होगा।

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

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

नैदानिक ​​नियमों के परीक्षणों द्वारा मतभेदों में से एक को तुरंत पहचान लिया गया था - पहले से मौजूद नोड के लिए वाक्यविन्यास के पेड़ की संरचना बदल गई है। यह ठीक है, जल्दी ठीक हो गया।

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

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

Visual Studio 2017 समर्थन के बारे में लेख के चौकस पाठकों को याद है कि हमारे वितरण किट में एक स्टब है - MSBuild.exe फ़ाइल 0 बाइट्स आकार में है।

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

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

सशर्त संकलन पात्रों को पार्स करने के लिए, Csc वर्ग की GetDefineConstantsSwitch विधि का उपयोग Microsoft.Build.Tasks.CodeAnalysis लाइब्रेरी से करें। कई सीमांकक पर 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 गुण सत्य है (तार्किक रूप से, हम वास्तव में संकलन नहीं कर रहे हैं)। नतीजतन, कॉलिंग विधि (पहले से ही वर्णित टूलटैस्क। एक्स्यूट्यूट ) यह जांचती है कि एक्सक्यूट्यूटूल विधि का रिटर्न कोड 0 है, और, यदि ऐसा है, तो इसका निष्पादन सही मूल्य के साथ पूरा करता है । आपके पास csc.exe के पीछे क्या था - वास्तविक संकलक या लियो टॉल्स्टॉय का 'वॉर एंड पीस' टेक्स्टुअल रूप में मायने नहीं रखता है।

नतीजतन, मुख्य समस्या इस तथ्य से उपजी है कि चरणों का अनुक्रम निम्नलिखित क्रम में परिभाषित किया गया है:

• संकलक के अस्तित्व की जांच करें;
• जाँच करें कि संकलक को शुरू करने की आवश्यकता है;

दूसरे तरीके से नहीं। कंपाइलर स्टब्स इस समस्या को सफलतापूर्वक हल करते हैं।

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

इस मामले के लिए एक विधि है - Microsoft.CodeAnalysis.CSharp लाइब्रेरी से CSharpCommandLineParser.ParseConditionalCompilationSymbols । पार्सिंग भी स्ट्रिंग द्वारा किया जाता है। कई सीमांकक के साथ विधि।

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

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

यह स्थिति समस्याग्रस्त परियोजनाओं पर उठी - सशर्त संकलन पात्रों को उनके साथ एक स्थान के साथ लिखा गया था, और GetDefineConstantsSwitch का उपयोग करके सफलतापूर्वक पार्स किया गया था , लेकिन ParseConditionalCompilationSymbols नहीं।

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

मैं नीचे इन समस्याओं में से एक के बारे में बात करना चाहता हूं - यह मुझे काफी दिलचस्प लगा।

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

खैर - विजुअल स्टूडियो में इसे पुन: पेश करना संभव था (प्रयोग विजुअल स्टूडियो 16.0.3 पर आयोजित किया गया था)। ऐसा करने के लिए, हमें निम्न फ़ॉर्म की एक वर्ग परिभाषा चाहिए:

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

हमें सिंटेक्स विज़ुअलाइज़र (.NET कंपाइलर प्लेटफ़ॉर्म एसडीके का हिस्सा) की भी आवश्यकता होगी। TypeSymbol (मेनू आइटम "TypeSymbol (यदि हो तो देखें)" का अनुरोध करने के लिए आवश्यक है प्रकार ConstantPatternSyntax ( नल ) के वाक्यविन्यास पेड़ के नोड से। उसके बाद, 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.CodeAnalysis डीबग लाइब्रेरी का उपयोग करते हैं, तो आप वाक्यविन्यास ट्री में वांछित नोड से टाइपस्माइल का अनुरोध करके डीबगिंग द्वारा सटीक स्थान पर आ सकते हैं।

परिणामस्वरूप, हम 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 ++ प्रोजेक्ट के मॉडल के निर्माण में परिवर्तन

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

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

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

समाधान काफी सरल था - टूलसेट की प्राथमिकता का परिचय (एक अलग प्राथमिकता इकाई का आवंटन)।

दृश्य स्टूडियो 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 कोर परियोजनाओं के एक मॉडल के निर्माण में परिवर्तन

इस कार्य के ढांचे के भीतर, 2 समस्याएं एक ही बार में हल हो गई थीं, क्योंकि वे संबंधित थीं:

• 'करंट' टूलसेट जोड़ने के बाद, Visual Studio 2017 के लिए .NET कोर प्रोजेक्ट्स के विश्लेषण ने काम करना बंद कर दिया;
• .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 कोर मॉडल के निर्माण के लिए आवश्यक पर्यावरण परियोजनाओं को स्थापित करने के लिए कुछ तर्क भी जोड़ना था, लेकिन ऐसा लगता है कि यह इसके लायक था।

पहले, .NET कोर परियोजनाओं के मॉडल का निर्माण करते समय काम का सिद्धांत इस प्रकार था: हमने बस इस निर्माण का अनुरोध किया था, और फिर सब कुछ MSBuild की कीमत पर काम किया।

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

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

ऊपर वर्णित चरणों से, यह स्पष्ट है कि आवश्यक वातावरण स्थापित करने के दो मुख्य उद्देश्य हैं:

• अपने स्वयं के टूलसेट से।
• बाह्य .targets / .props फ़ाइलों के लिए आगे के संचालन को पुनर्निर्देशित करें।

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

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

उसके बाद, आवश्यक आयातों को पूरा करने और कई गुणों को स्थापित करने के बाद, हम वास्तविक .NET कोर SDK के लिए मॉडल बिल्डिंग के आगे नियंत्रण को स्थानांतरित करते हैं, जहां बाकी आवश्यक क्रियाएं होती हैं।

निष्कर्ष

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

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

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