कौन सी सी # परियोजना फाइलों को संस्करण नियंत्रण करना चाहिए?

Question

मेरे पास एक प्रोजेक्ट है जिसे मैं मैन्युअल रूप से perforce संस्करण नियंत्रण के माध्यम से प्रबंधित करना चाहता हूं क्योंकि मेरे पास केवल एक्सप्रेस संस्करण है। मैं जो खोज रहा हूं वह है कि कौन सी फाइलें संस्करण नियंत्रण में बहिष्कृत की जानी चाहिए क्योंकि कई फाइलों को लॉक करने से विजुअल स्टूडियो संकलन और डिबगिंग के लिए समस्या हो सकती है।

मैं क्या है, अब तक, शामिल थे।
.cs फ़ाइलें (गुण फ़ोल्डर को छोड़कर)
.resx फ़ाइलों
.csproj फ़ाइलों

अपवर्जित
बिन फ़ोल्डर
obj फ़ोल्डर
गुण फ़ोल्डर
.user फ़ाइल

Let मुझे पता है कि क्या कुछ और है जिसमें शामिल किया जाना चाहिए जिसे मैंने बाहर रखा है या यदि टी करने का बेहतर तरीका है उनके।

Answer 1

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

आपको किसी भी .sln फ़ाइल को भी शामिल करना चाहिए, यदि कोई हो।

Answer 2

इसके अलावा को बाहर:

.suo 
app.config (you should commit something like app-dev.config instead) 

पुन: app.config:

app.config आमतौर पर मशीन विशिष्ट जानकारी (डेटाबेस कनेक्शन तार, डिफ़ॉल्ट सेटिंग्स, या संसाधनों के रास्तों की तरह) है और आप डॉन ' जब भी आप स्रोत नियंत्रण से बाहर निकलते हैं तो यह क्लॉग्ल्ड किया जाता है। इन फ़ाइलों को तैनात स्क्रिप्ट के साथ बनाया/कॉपी किया जाना चाहिए।

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

Answer 3

कोई भी छवियां, आइकन इत्यादि जोड़ने के लिए मत भूलना, आप अपने आवेदन में उपयोग कर सकते हैं। इन्हें भूलना आसान है।

इसके अलावा अगर आप किसी भी प्रलेखन परियोजना के साथ जुड़े है - विनिर्देशों, डिजाइन, मदद फ़ाइलों आदि परियोजना के तहत अलग फ़ोल्डर में इन रखो और फिर उन्हें भी शामिल हैं।

Answer 4

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