विभिन्न फ़ोल्डरों के संकलन के लिए विजुअल स्टूडियो 2008/2010 में डीबग/रिलीज कॉन्फ़िगरेशन का उद्देश्य क्या है?

Question

फ़ोल्डरों को अलग करने के लिए असेंबली संकलित करने का क्या मतलब है? मेरे काम पर हमारे पास 50+ परियोजनाएं हैं जो कुछ अलग-अलग समाधानों में रहती हैं। जब परियोजनाएं एक ही समाधान में होती हैं तो आप एक परियोजना संदर्भ सेट कर सकते हैं और यह तदनुसार \ debug या \ release फ़ोल्डर में असेंबली उठाता है। लेकिन जब बाहरी संदर्भ (ब्राउज़ के माध्यम से) सेट करते हैं और आप स्पष्ट रूप से \ debug \ assebmly.dll या \ release \ assembly.dll को इंगित करते हैं तो रेफरेंसिंग प्रोजेक्ट रिलीज़ मोड में संकलित होने पर "रिलीज़" असेंबली नहीं लेगा।

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

I also have a blog post on this topic here.

Answer 1

खैर, यह, सरल है क्योंकि नहीं अलग फ़ोल्डर का उपयोग कर इतना बुरा है। आप रिलीज का निर्माण करेंगे, कुछ अजीब पता लगाएंगे, डीबग पर वापस स्विच करें और असेंबली के वास्तविक डीबग संस्करण प्राप्त करें। जब तक आप स्पष्ट रूप से Build + Clean का उपयोग नहीं करते हैं। अब आप तलवार से लड़ेंगे या एसओ जायेंगे, भूल जाएंगे कि आपने वापस क्यों स्विच किया।

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

Answer 2

यह न केवल बाइनरी, यह मध्यवर्ती फाइल भी है है। यही कारण है कि विभिन्न निर्देशिकाओं को संकलित करना आवश्यक है।

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

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

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

HTH

Answer 3

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

बिल्ड को अलग फ़ोल्डरों में रखकर, आप यह सुनिश्चित कर सकते हैं कि सभी असेंबली एक ही कॉन्फ़िगरेशन से बनाई गई हैं।