2012-11-21 15 views
73

वर्तमान में, मैं nuget.org पर आधिकारिक बिल्ड के लिए नाइटेट के साथ रिहाई का निर्माण करता हूं, लेकिन मैं प्रतीक स्रोत के लिए Nuget के साथ डीबग बिल्ड करता हूं symbolsource.org पर धक्का देता है।Nuget के साथ सर्वोत्तम अभ्यास: डीबग या रिलीज?

संपादित करें: (जॉन स्कीट, Noda समय विकास से कुछ पूर्वाग्रह के साथ)

NuGet अब दोनों NuGet गैलरी और symbolsource.org (या इसी तरह सर्वर), as documented को आगे बढ़ाने का समर्थन करता है।

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

यह ठीक होगा, लेकिन NuGet (जहां तक ​​मैं कह सकता हूं) रिलीज और डीबग दोनों को उसी पैकेज में एक उपयोगी तरीके से प्रकाशित करने की अनुमति देता है।

तो, विकल्प हैं:

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

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

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

तो, क्या ऐसे अन्य विकल्प हैं जिन्हें हमने नहीं माना था? क्या अन्य विचार हैं जो संतुलन को इंगित करते हैं? NuGet संकुल को सिंबलसोर्स को पर्याप्त रूप से नया धक्का दे रहा है कि "सर्वोत्तम अभ्यास" वास्तव में स्थापित नहीं किया गया है?

+2

मैं एक ही प्रश्न पूछने वाला था - हालांकि वर्तमान में मैं रिलीज कॉन्फ़िगरेशन को प्रतीकों को भी दबा रहा हूं, बशर्ते कि मैं केवल 'न्यूज पैक ... -सिंबोल' का उपयोग कर रहा हूं और जेनरेट किए गए पैकेज को दबा रहा हूं .. –

+6

अगर मैं अपने प्रश्न में अपने संदर्भ के बारे में अधिक जानकारी संपादित करता हूं तो मन? मुझे लगता है कि यह पूछने के कुछ कारणों को स्पष्ट करेगा। –

+0

आगे बढ़ें। मैं बाद में इन सभी नई पोस्टों के साथ मिल जाऊंगा। – gzak

उत्तर

25

SymbolSource के लिए बात हो रही है, मेरा मानना ​​है कि सबसे अच्छा अभ्यास करने के लिए है कि:

  1. पुश रिहाई द्विआधारी + सामग्री संकुल केवल nuget.org करने के लिए (या किसी अन्य उत्पादन फ़ीड)
  2. पुश डिबग द्विआधारी + सामग्री संकुल एक विकास फ़ीड की:
    • ऑन-प्रिमाइसेस nuget.org पर myget.org
    • पर
    • रिलीज संकुल के रूप में।
  3. दोनों रिलीज और डिबग बाइनरी + प्रतीक पैकेज को symbolsource.org या किसी अन्य प्रतीक स्टोर में दबाएं।

जबकि हम इसमें हैं, यह एक आम गलत धारणा है कि .NET में रिलीज और डिबग बिल्ड वास्तव में बहुत भिन्न है, लेकिन मुझे लगता है कि भिन्नता यहां विभिन्न कोडों के कारण है जो शायद शामिल हो या न हो या तो निर्माण में, Debug.Asserts की तरह।

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

संस्करण के बारे में विचार करने के लिए अभी भी एक बात है: क्या 2 अलग-अलग पैकेज (डीबग और रिलीज में निर्मित) 1 संस्करण संख्या साझा करना सही है? सिंबलसोर्स इसे स्वीकार करेगा, क्योंकि यह अलग-अलग बिल्ड मोड शाखाओं में पैकेजों को स्टोर करता है और बाइनरी स्टोर करता है, अगर केवल नुगेट को तदनुसार पैकेज टैग करने की अनुमति है। यह निर्धारित करने के लिए वर्तमान में कोई तरीका नहीं है कि कोई पैकेज डीबग या रिलीज़-मोड है या नहीं।

+0

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

+0

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

+1

दाएं। मेरा संभावित समाधान * केवल * रिलीज बाइनरी को रिलीज़ करना है, लेकिन मैं इस बारे में चिंतित हूं कि डिबगिंग के मामले में यह कितना दुख पहुंचा रहा है। उदाहरण के लिए, क्या एनओपी की कमी का मतलब है कि आप ब्रेकपॉइंट्स नहीं जोड़ सकते हैं? –

0

डीएसएल और पीडीबी फाइलों के स्रोत के रूप में डीबग निर्देशिकाओं में Creating and Publishing A Symbol Package संदर्भ फ़ाइलों में उदाहरण।

निर्दिष्ट प्रतीक पैकेज सामग्री

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

<files> 
    <file src="Full\bin\Debug\*.dll" target="lib\net40" /> 
    <file src="Full\bin\Debug\*.pdb" target="lib\net40" /> 
    <file src="Silverlight\bin\Debug\*.dll" target="lib\sl40" /> 
    <file src="Silverlight\bin\Debug\*.pdb" target="lib\sl40" /> 
    <file src="**\*.cs" target="src" /> 
</files> 

प्रतीकों को प्रकाशित करने के उद्देश्य को कब से डीबगिंग, ऐसा लगता है दूसरों को अपने कोड से निकलने के लिए अनुमति देने के लिए है अनुकूलन के बिना डीबगिंग के लिए कोड के एक संस्करण को प्रकाशित करने के लिए सबसे समझदार है जो कोड चरण को प्रभावित कर सकता है।

+0

हां, यही है * उदाहरण * करता है - लेकिन मैं अधिकांश डेवलपर्स के रिलीज संस्करण को चलाने के लिए इच्छा को ओवरराइड करने की क्षमता के साथ समाप्त नहीं करना चाहता हूं। समस्या यह है कि जहां तक ​​मैं बता सकता हूं, NuGet में रिलीज और डिबग बिल्ड दोनों को प्रकाशित करने का कोई तरीका नहीं है। (यह मेरे लिए दोनों को प्रकाशित करने के लिए थोड़ा सा दर्द भी होगा, क्योंकि इसका मतलब है कि हस्ताक्षरित डिबग बिल्ड के लिए कॉन्फ़िगरेशन का एक और सेट बनाना है ...) –

+0

यहां हम थोड़ी सी अधीनता प्राप्त करते हैं। आम तौर पर, "सर्वोत्तम अभ्यास" के लिए मेरी पसंद यह होगी कि लेखक स्पष्ट रूप से या स्पष्ट रूप से अनुशंसा करता है, क्योंकि मुझे लगता है कि उनके पास व्यक्तिगत रूप से बोलते हुए, उदाहरणों में समाप्त होने वाली धारणाओं के मामले में अधिक अंतर्दृष्टि (या निरीक्षण, निरीक्षण है) मुझे लगता है कि प्रतीकों का उपयोग उस संस्करण से मेल खाना चाहिए जो मैं उपयोग कर रहा हूं। मैं आम तौर पर एक पैकेज का उपयोग नहीं करता था जिसे मैंने सोचा था कि मुझे डीबग करने की संभावना होगी, जब तक कि स्रोत सार्वजनिक न हो और मैं आवश्यक होने पर स्क्रैच से संकलित कर सकूं, इसलिए पैक किए गए, डीबग बिल्ड की कमी विशेष रूप से महत्वपूर्ण नहीं है। – tvanfosson

+0

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

4

मैं पूरी तरह से आपके निष्कर्ष से सहमत हूं। डीबग के साथ रिलीज और सिंबलसोर्स के साथ NuGet पैकेज। पैकेज में सीधे कदम उठाने के लिए यह बहुत दुर्लभ लगता है और अनुकूलन के साथ कभी-कभी डीबग गलत तरीके स्वीकार्य हो सकता है।

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

आदर्श रूप से, यह होगा कि nuget pack SomePackage -Symbols रिलीज़ संस्करण के विरुद्ध एक रिलीज nuget पैकेज, लेकिन एक डीबग प्रतीक पैकेज बना देगा। और वीएस प्लगइन को डीबगर में चलते समय डीबग असेंबली में एसोसिएशन देखने और खींचने के लिए पर्याप्त स्मार्ट होने के लिए अद्यतन किया जाएगा और इसके बजाय लोड करें। पागल की तरह, लेकिन दिलचस्प होगा।

हालांकि, मुझे बस इस बारे में शिकायत करने वाले पर्याप्त लोगों को नहीं दिख रहा है कि इस समय यह इसके लायक होगा।

NuGet टीम पुल अनुरोध स्वीकार करता है।:)

+0

मुझे यकीन नहीं है कि मैं आपकी दूसरी वाक्य को समझता हूं - मुझे संदेह है कि ओपी (संपादित करने से पहले) मैन्युअल रूप से डीबग बिल्ड के लिए सिंबलसोर्स पर मैन्युअल रूप से धक्का दे रहा था। क्या आप महत्वपूर्ण मुद्दों पर विचार करते हैं यदि * रिलीज * संस्करण का पीडीबी डीबग संस्करण के बजाय सिंबलसोर्स में समाप्त होता है? या यह है कि आप वकालत कर रहे थे, और मैं बस गलत समझा? –

+3

"हालांकि, मुझे बस इस बारे में शिकायत करने वाले पर्याप्त लोगों को नहीं दिख रहा है कि इस समय यह इसके लायक होगा।" शायद वे शिकायत नहीं कर रहे हैं, लेकिन यदि आपने उपयोगकर्ताओं के नमूने से पूछा कि उन्होंने इस बारे में क्या सोचा है, तो मुझे यकीन है कि आप पाएंगे कि अधिकतर लोग इस विशेष चरण में कुछ भ्रम स्वीकार करेंगे (NuGet.org पर क्या प्रकाशित करना है और SymbolSource.org)। यदि आपने पूछा कि वे क्या उठा रहे हैं, तो आप शायद पाएंगे कि कोई भी सहमति नहीं है, हर कोई सिर्फ अपनी ही चीज करता है। – gzak

+6

मैं इस बारे में शिकायत करना चाहता हूं, मैं साइन अप कहां से करूँ? – Alex

संबंधित मुद्दे