विजुअल स्टूडियो (2005)

Question

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

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

उदाहरण के तौर पर, हमारे पास एक परियोजना है जिसे 3 अलग-अलग प्लेटफ़ॉर्म के लिए निर्माण करने की आवश्यकता है। प्रत्येक प्लेटफ़ॉर्म में कई कॉन्फ़िगरेशन हो सकते हैं (उदाहरण के लिए डीबग, रिलीज, और कई अन्य)। नवगठित परियोजना पर मेरे लक्ष्यों में से एक ऐसा समाधान है जिसमें सभी प्लेटफॉर्म एक साथ रहने का निर्माण कर सकें, जिससे बिल्डिंग और परीक्षण कोड में परिवर्तन आसान हो जाता है क्योंकि आपको अपने कोड का परीक्षण करने के लिए 3 अलग-अलग समाधान खोलने की ज़रूरत नहीं है। लेकिन दृश्य स्टूडियो को 3 * (बेस कॉन्फ़िगरेशन की संख्या) विन्यास की आवश्यकता होगी। यानी पीसी डीबग, एक्स 360 डीबग, पीएस 3 डीबग, आदि

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

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

धन्यवाद।

Answer 1

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

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

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

तत्काल कमियां जो मन में वसंत:

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

संक्षेप में, आप अपने प्रोजेक्ट कॉन्फ़िगरेशन का प्रबंधन करने में कम समय व्यतीत करेंगे, लेकिन विजुअल स्टूडियो को इसके साथ ठीक से काम करने के लिए अधिक समय लगेगा।

Answer 2

दृश्य स्टूडियो MSBuild विन्यास फ़ाइलों की चोटी पर बनाया जा रहा है (पोस्ट है कि इन सी ++ हैं बनाता है उल्लेख करने के लिए संपादित)। आप मेकफ़ाइल के रूप में * proj और * sln फ़ाइलों पर विचार कर सकते हैं। वे आपको पूरी तरह से निर्माण प्रक्रिया को अनुकूलित करने की अनुमति देते हैं।

Answer 3

आप समाधान को प्रतिस्थापित करने के लिए व्यक्तिगत रूप से परियोजनाओं का निर्माण करने के लिए नेंट का उपयोग कर सकते हैं और 1 कोडिंग समाधान और कोई निर्माण समाधान नहीं कर सकते हैं।

ध्यान में रखने के लिए 1 बात यह है कि 2005 और ऊपर बनाम समाधान और csproj फ़ाइलें msbuild स्क्रिप्ट हैं। इसलिए यदि आप msbuild से परिचित हो जाते हैं तो आप मौजूदा फ़ाइलों को प्रबंधित करने, बनाम आसान बनाने और अपनी तैनाती को आसान बनाने में सक्षम हो सकते हैं।

Answer 4

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

मुझे सलाह है कि आप NAnt पर एक नज़र डालें। यह एक बहुत ही मजबूत निर्माण प्रणाली है जहां आप मूल रूप से कुछ भी कर सकते हैं जिसकी आपको आवश्यकता है।

हमारे NAnt स्क्रिप्ट हर निर्माण पर इस करता है:

1. नवीनतम संस्करण
2. डेटाबेस
3. संकलित हमारे "मास्टर" समाधान में हर परियोजना के बंद सी # संस्थाओं उत्पन्न करने के लिए डेटाबेस माइग्रेट
4. सभी यूनिट परीक्षण चलाएं
5. सभी एकीकरण परीक्षण चलाएं

इसके अतिरिक्त, हमारा बिल्ड सर्वर इसका लाभ उठाता है और 1 और कार्य जोड़ता है, जो Sandcastle दस्तावेज़ उत्पन्न कर रहा है।

आप XML पसंद नहीं है, तो आप भी Rake (रूबी), Bake/BooBuildSystem (बू), या Psake पर एक नज़र ले सकता है (PowerShell)

Answer 5

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