मुझे Visual Studio समाधान फ़ाइलों के बजाय MSBuild का उपयोग क्यों करना चाहिए?

Question

हम लगातार एकीकरण के लिए TeamCity का उपयोग कर रहे हैं और यह समाधान फ़ाइल (.sln) के माध्यम से हमारी रिलीज़ का निर्माण कर रहा है। मैंने विभिन्न प्रणालियों के लिए अतीत में मेकफाइल्स का उपयोग किया है, लेकिन कभी भी msbuild (जो मैंने सुना है वह मेकफाइल्स + एक्सएमएल मैशअप की तरह है)। मैं कैसे समाधान फ़ाइलों के बजाय सीधे MSBuild का उपयोग करने पर कई पदों को देखा है, लेकिन मैं पर एक बहुत ही स्पष्ट उत्तर नहीं दिख रहा है यही कारण है कि यह करने के लिए।

तो, क्यों हम समाधान फ़ाइलों से एक MSBuild 'मेकफाइल' के लिए पलायन परेशान करना चाहिए? हमारे पास रिलीज की एक जोड़ी है जो एक #define (अलग-अलग बिल्ड) द्वारा भिन्न है लेकिन अधिकांश भाग के लिए सब कुछ काम करता है।

इससे भी बड़ी चिंता यह है कि अब हमें परियोजनाओं / स्रोत कोड को जोड़ते समय दो प्रणालियों को बनाए रखना होगा ।

अपडेट करें:

क्या लोग निम्नलिखित तीन घटकों के जीवनचक्र और परस्पर क्रिया पर प्रकाश डाल सकते हैं?

1. Visual Studio .sln फ़ाइल
2. कई परियोजना स्तर .csproj फाइलें (जिन्हें मैं "उप" msbuild स्क्रिप्ट समझता हूं)
3. कस्टम msbuild स्क्रिप्ट

क्या यह कहना सुरक्षित है कि .sln और .csproj का उपभोग / रखरखाव विज़ुअल स्टूडियो IDE GUI के भीतर से सामान्य रूप से किया जाता है, जबकि कस्टम msbuild स्क्रिप्ट हाथ से लिखी जाती है और आमतौर पर पहले से मौजूद व्यक्तिगत .csproj "as-is" का उपभोग करती है? यही एक तरीका है कि मैं रखरखाव में ओवरलैप / डुप्लिकेट को कम कर सकता हूं ...

अन्य लोगों के परिचालन अनुभव से इस पर कुछ प्रकाश की सराहना करेंगे

Comments

So, why should we bother migrating from solution files to an MSBuild 'makefile'?पहले आपको यह बताना होगा कि आप इस पर विचार क्यों कर रहे हैं? क्या समाधान फ़ाइल पर्याप्त नहीं है?

— जिगौफिन

क्योंकि यह बेहतर अभ्यास होने के लिए प्रतिष्ठित है। आपके अंतिम प्रश्न के लिए; शायद यह है, शायद यह नहीं है। इसलिए यह प्रश्न स्पष्ट उत्तर के लिए इसका पता लगाने के लिए है।

— डीपस्पेस101101

Because it's reputed to be better practiceकहाँ पे?

— jgauffin

आईडीई (एसएलएन फाइल) का निर्माण से अलग होना निश्चित रूप से एक अच्छा एसई डिजाइन है। यदि आप विवरण चाहते हैं तो जेफ़ ने इसके बारे में कोडिंगहोरर . com / blog / 2007 / 10 / … पर लिखा है । इसके अलावा यह अच्छा है कि परीक्षण और यहां तक ​​कि सॉफ्टवेयर पैकेजिंग (setup.exe या msi) रिलीज के हिस्से के रूप में बिल्ड कंपाइलिंग के बजाय रिलीज बिल्ड स्क्रिप्ट।

— डीपस्पेस101101

@jgauffin: sedodream.com/2010/03/19/…

— जोश

Answer 1

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

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

Comments

तो आप Visual Studio में sln + csproj का उपयोग करते हैं और फिर csproj के + कस्टम msbuild स्क्रिप्ट को बिल्ड सर्वर पर समान है? मैंने प्रश्न को थोड़ा स्पष्ट किया है। धन्यवाद!

— डीपस्पेस101101

हां, वे कार्यात्मक रूप से समान हैं।

— व्याट बार्नेट

Answer 2

MSBuild के लिए makefile है .sln फ़ाइल (या vcproj फ़ाइल)।

एक विशिष्ट msbuild कमांड लाइन कुछ इस तरह होगी:

msbuild /p:Configuration=Release BigProject.sln

Msbuild का उपयोग करने की बात यह है कि आप निर्माण प्रक्रिया को स्क्रिप्ट और स्वचालित कर सकते हैं। आप इसके बारे में जानते थे या नहीं, TeamCity सभी के साथ msbuild का उपयोग कर रहा है।

Comments

विभिन्न घटकों के संभावित ओवरलैप पर आप बाद वाले हिस्से पर क्या विचार कर रहे हैं? मैंने (उम्मीद है!) सवाल को थोड़ा और स्पष्ट किया ... thx

— DeepSpace101

Answer 3

मुझे इस प्रश्न पर अपना प्रस्ताव देने दें।

हालाँकि आप निश्चित रूप से अपनी .SLN फाइल को अपनी 'बिल्ड प्रोसेस' के रूप में इस्तेमाल कर सकते हैं, फाइल ही वास्तव में बिल्ड प्रोसेस का गठन नहीं करती है। समाधान फ़ाइल वास्तव में केवल विजुअल स्टूडियो का एक हिस्सा है और इसका उपयोग विकास के लिए किया जाता है। लेकिन Visual Studio बिल्ड और रिलीज़ प्रक्रिया का केवल एक हिस्सा है। आप अपने निर्माण का प्रबंधन करने के लिए समाधानों पर भरोसा नहीं कर सकते हैं, और समाधान निश्चित रूप से एक स्केलेबल बिल्ड स्थिति की पेशकश नहीं करते हैं।

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

बिल्ड प्रक्रिया स्थापित करने के लिए एक निवेश की आवश्यकता होती है, लेकिन कुछ मामलों में, निवेश की आवश्यकता होती है। यहाँ कुछ कारक हैं जो एक msbuild प्रक्रिया का पक्ष लेते हैं:

• आपके उत्पाद में कई टीम (क्रॉस-फ़ंक्शनल या अन्यथा) हैं जो एक ही टीम प्रोजेक्ट में काम कर रहे हैं
• आपके संगठन में केवल एक टीम प्रोजेक्ट है (पारंपरिक दुकानों के 99% के लिए मामला होना चाहिए, यहां तक ​​कि 200+ डेवलपर्स के साथ भी)
• आपके पास 20 से अधिक परियोजनाएं हैं जिन्हें बनाने की आवश्यकता है, जिनमें से कुछ की दूसरों पर निर्भरता है और विभिन्न टीमों द्वारा बनाए रखा जाता है
• आपके उत्पाद में कई .NET टेक्नोलॉजीज (C #, C ++, VB, F #, ASP.NET, आदि), या यहां तक ​​कि गैर- .NET टेक्नोलॉजीज (ग्रंट, नोड, एनपीएम, जावा, आदि) शामिल हैं।
• आपके उत्पाद में हेवीवेट निर्भरता है या हेवीवेट प्लेटफॉर्म के शीर्ष पर बनाया गया है। उदाहरण के तौर पर SharePoint

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

एक संदर्भ के रूप में, मैं सैयद इब्राहिम हाशिमी की इस पुस्तक की जाँच करने की सलाह दूंगा: http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_fkmr0_1?ie=UTF8&qid=1412014650&sr= 8-1-fkmr0 और कीवर्ड = MSBuild + विश्वसनीय + निर्माण

Comments

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

— जुलैलेगॉन

+1 "आपके संगठन के पास केवल एक टीम प्रोजेक्ट है" की व्याख्या के लिए। यह मुझे ऐसी छोटी दुकानों में 'उत्पादों' या 'परियोजनाओं' जैसी चीजों के लिए कई टीम प्रोजेक्ट्स की सीमाओं के रूप में उपयोग करने वाले लोगों को देखने के लिए परेशान करता है। मैंने एकल टीम प्रोजेक्ट का तरीका अपनाया और उम्मीद है कि मुझे कभी पीछे नहीं हटना पड़ेगा।

— जॉनजज

Answer 4

यह वही सवाल है जो मैंने खुद से कुछ महीने पहले पूछा था! हमारे पास सब कुछ ठीक-ठाक था:

• सॉल्यूशन फाइल को रिपॉजिटरी की रूट में अच्छी तरह से
• Teamcity में कॉन्फ़िगर किए गए चरणों का निर्माण करें, जैसे
  • NuGet पैकेज पुनर्स्थापित करें
  • समाधान बनाएँ
  • यूनिट टेस्ट चलाएं
  • सेट-अप एकीकरण परीक्षण वातावरण
  • एकीकरण परीक्षण चलाएं
  • एकीकरण परीक्षण पर्यावरण को फाड़ दें
  • एक परिनियोजन पैकेज बनाएँ
  • माइग्रेशन स्क्रिप्ट बनाएँ

और फिर, जब यह प्रतिलिपि प्रस्तुत करने योग्यता की बात आती है, तो यह स्पष्ट हो गया कि यह कम स्कोर था। जब आप TeamCity को अपनी बिल्ड स्क्रिप्ट बनाते हैं, तो अपने स्वयं के विकास मशीन पर विश्वसनीय, समान परिणामों को पुन: पेश करना मुश्किल हो जाता है।

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

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

Comments

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

— रबरडक