क्या मुझे स्रोत नियंत्रण में विज़ुअल स्टूडियो .suo और .user फ़ाइलों को जोड़ना चाहिए?

Question

Visual Studio समाधान में दो प्रकार की छिपी हुई उपयोगकर्ता फ़ाइलें होती हैं। एक समाधान .suoफ़ाइल है जो एक बाइनरी फ़ाइल है। दूसरी परियोजना .userफ़ाइल है जो एक पाठ फ़ाइल है। वास्तव में इन फ़ाइलों में क्या डेटा है?

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

Comments

.suo फ़ाइलों को स्वचालित रूप से पुनः निर्मित किया जाता है। यदि चीजें टूटती हैं तो आप डिफ़ॉल्ट रूप से 'रिफ्रेश' करने का एक शानदार तरीका है।

— कोडिंगबेरफील्ड

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

— अत्तिला क्षिपक

* .su के लिए, कृपया यहां देखें: msdn.microsoft.com/en-us/library/bb165909.aspx

— smwikipedia

किस विजुअल C ++ फ़ाइल प्रकार को संस्करण नियंत्रण के लिए प्रतिबद्ध होना चाहिए?

— फुलकव

Answer 1

इन फ़ाइलों में उपयोगकर्ता वरीयता कॉन्फ़िगरेशन हैं जो सामान्य रूप से आपकी मशीन के लिए विशिष्ट हैं, इसलिए इसे SCM में नहीं रखना बेहतर है। इसके अलावा, वीएस इसे आपके द्वारा निष्पादित किए जाने के लगभग हर समय बदल देगा, इसलिए इसे हमेशा एससीएम द्वारा 'परिवर्तित' के रूप में चिह्नित किया जाएगा। मैं या तो शामिल नहीं है, मैं 2 साल के लिए वी.एस. का उपयोग कर एक परियोजना में हूँ और ऐसा करने में कोई समस्या नहीं थी। केवल मामूली झुंझलाहट यह है कि डिबग पैरामीटर (निष्पादन पथ, परिनियोजन लक्ष्य, आदि) उन फ़ाइलों में से एक में संग्रहीत हैं (जो नहीं जानते हैं), इसलिए यदि आपके पास उनके लिए कोई मानक है तो आप 'करने में सक्षम नहीं होंगे' पूरे विकास के माहौल को 'उपयोग करने के लिए तैयार' करने के लिए इसे अन्य डेवलपर्स के लिए SCM के माध्यम से प्रकाशित करें।

Comments

सावधान रहें, सू फाइल की जानकारी संग्रहीत करता है कि क्या परियोजना को समाधान के भीतर लोड / अनलोड किया गया है।

— कुगेल

मेरा मानना ​​है कि यह .user फ़ाइल (कम से कम SQL सर्वर डेटा टूल्स के लिए) डिबग जानकारी संग्रहीत करता है। इसके अलावा, जब आप डिबग टैब में सेटिंग्स बदलते हैं, तो यह हमेशा सीधे .user से दूर नहीं रहता है (समाधान काम करने लगता है, थोड़ा कष्टप्रद होता है ... या .sqlproj फ़ाइल में संग्रहीत अन्य सेटिंग बदलना)।

— जेमीबारो 8

आप किसी भी टेक्स्ट एडिटर में .user और .csproj दोनों फाइलों को खोल सकते हैं। मैंने अभी .user से .csproj में संबंधित डिबग सेटिंग की कॉपी-पेस्ट की, फिर .user फ़ाइल को डिलीट किया। डिबगिंग ने काम करना जारी रखा, खुशी से अपने नए स्थान से .csproj फ़ाइल में सही सेटिंग्स को पढ़ना। यह .user फ़ाइल किए बिना डिबग सेटिंग करने का एक तरीका प्रदान करना चाहिए। सुनिश्चित करें कि आपने उन्हें सही कॉन्फ़िगरेशन (डिबग, रिलीज़, आदि) में रखा है। मेरी मशीन पर काम करता है! =)

— क्रिस नीलसन

Answer 2

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

Comments

यदि आप कई अलग-अलग मशीनों पर खुद काम कर रहे हैं, तो क्या उन्हें जोड़ना उचित होगा?

— thepocketwade

मैं नहीं करूंगा, क्योंकि यह अप्रत्याशित प्रणाली मतभेदों के लिए नाजुक हो सकता है; उदाहरण के लिए, यदि आप घर पर x64 और x86 पर काम करते हैं, तो यह "c: \ program files (x86)" और "c: \ program files" पर झूम सकता है। मुझे नहीं पता, लेकिन मैं इसे जोखिम में नहीं डालूंगा।

— स्टीव कूपर

हालाँकि उनमें उपयोगकर्ता विशिष्ट जानकारी होती है, लेकिन उन फ़ाइलों की जानकारी जो (प्रोजेक्ट में शामिल) विकल्प के माध्यम से नई जोड़ी जाती है, .csproj फ़ाइल मुझे लगता है, जिसमें अन्य उपयोगकर्ताओं को मैन्युअल रूप से सभी नए जोड़े गए प्रोजेक्ट संसाधनों को जोड़ने की आवश्यकता होती है। अगर किसी को वर्कअराउंड पता है, तो कृपया यहां उल्लेख करें।

— ज़ेपेलिन

Answer 3

दूसरों ने समझाया है कि स्रोत नियंत्रण के तहत फाइलें *.suoऔर *.userफाइलें होना एक अच्छा विचार क्यों नहीं है।

मैं आपको सुझाव देना चाहता हूं कि आप इन पैटर्नों को svn:ignore2 कारणों से संपत्ति में जोड़ दें :

1. इसलिए अन्य डेवलपर्स एक डेवलपर की सेटिंग्स के साथ हवा नहीं करेंगे।
2. इसलिए जब आप स्थिति देखते हैं, या फ़ाइलें देखते हैं, तो वे फ़ाइलें कोड आधार को अव्यवस्थित नहीं करेंगी और आपको जोड़ने के लिए आवश्यक नई फ़ाइलों को अस्पष्ट करना होगा।

Comments

svn:ignoreसंपत्ति कहां और कैसे सेट की गई है?

— पीटर मोर्टेंसन

@PeterMortensen, इस प्रश्न को देखें: stackoverflow.com/questions/86049/…

— JXG

लेकिन जोड़ने के लिए एक मामला है ( इस उत्तर को देखें ) .user, तो कोई केवल उपेक्षा नहीं .suoकर सकता है - या कोई भी अनदेखी कर सकता है .user, ताकि उन्हें जोड़ने के लिए एक सचेत निर्णय लिया जाए? ऐसा मत सोचो, के बिंदु उन svn:ignoreचीजों को चिह्नित कर रहा है जहां कोई सचेत निर्णय की आवश्यकता नहीं है।

— PJTraill

Answer 4

हम बाइनरी फ़ाइल (* .suo) नहीं करते हैं, लेकिन हम .user फ़ाइल करते हैं। .User फ़ाइल में उदाहरण के लिए प्रोजेक्ट डीबग करना प्रारंभ विकल्प हैं। आप टैब "डीबग" में प्रोजेक्ट के गुणों में शुरुआती विकल्प पा सकते हैं। हमने कुछ परियोजनाओं में NUnit का उपयोग किया और परियोजना के लिए nunit-gui.exe को स्टार्ट विकल्प के रूप में कॉन्फ़िगर किया। .User फ़ाइल के बिना, प्रत्येक टीम के सदस्य को इसे अलग से कॉन्फ़िगर करना होगा।

उम्मीद है की यह मदद करेगा।

Comments

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

— जेमीबारो

दूसरों ने ऐसा करने के खिलाफ सुझाव दिया है, लेकिन मुझे यकीन नहीं है कि खतरे क्या हो सकते हैं। शायद इसलिए कि कम सटीक सेटिंग्स वाली रेपो फ़ाइल उपयोगकर्ता (बेहतर) स्थानीय प्रतिलिपि को उड़ा देगी? (हमारी टीम मर्क्यूरियल, बीटीडब्ल्यू का उपयोग कर रही है।)

— जॉन कोम्ब्स

Microsoft .user फ़ाइल को स्रोत नियंत्रण में जोड़ने के विरुद्ध सलाह देता है ।

— डेविड आरआर

आप डिबग सेटिंग को .csproj पर ले जा सकते हैं, यह टिप्पणी

— टिम्बो

Answer 5

चूंकि मुझे 2011 में Google के माध्यम से यह प्रश्न / उत्तर मिला, मैंने सोचा कि मैं एक दूसरा ले लूंगा और विजुअल स्टूडियो 2010 द्वारा बनाई गई * .SDF फाइलों की सूची में लिंक जोड़ दूंगा जो संभवत: संस्करण नियंत्रण में नहीं जोड़ा जाना चाहिए ( आईडीई उन्हें फिर से बनाएगा)। चूँकि मुझे यकीन नहीं था कि * .sdf फ़ाइल का कहीं और वैध उपयोग हो सकता है, इसलिए मैंने SVN से केवल विशिष्ट [प्रोजेक्टनेम] .sdf फ़ाइल को अनदेखा किया।

विज़ुअल स्टूडियो रूपांतरण विज़ार्ड 2010 एक बड़े पैमाने पर एसडीएफ डेटाबेस फ़ाइल क्यों बनाता है?

Comments

एसडीएफ फ़ाइल शायद एक SQL सर्वर कॉम्पैक्ट संस्करण डेटाबेस है ।

— कार्ल जी।

Answer 6

नहीं, आपको उन्हें स्रोत नियंत्रण से नहीं जोड़ना चाहिए - जैसा कि आपने कहा - वे विशिष्ट उपयोगकर्ता हैं।

SUO (सॉल्यूशन यूजर ऑप्शंस): उन सभी विकल्पों को रिकॉर्ड करता है, जिन्हें आप अपने समाधान के साथ जोड़ सकते हैं ताकि हर बार जब आप इसे खोलें, तो इसमें वे अनुकूलन शामिल हों जो आपने किए हैं।

.User फ़ाइल में प्रोजेक्ट के लिए उपयोगकर्ता विकल्प होते हैं (जबकि SUO समाधान के लिए) और प्रोजेक्ट फ़ाइल नाम का विस्तार करता है (उदाहरण के लिए कुछ.csproj.user में कुछ भी शामिल हैं। परियोजना प्रॉजेक्ट के लिए उपयोगकर्ता सेटिंग्स)।

Answer 7

यह मामले पर Microsoft की राय प्रतीत होती है:

स्रोत नियंत्रण के लिए .suo फ़ाइलों को जोड़ना (और संपादित करना)

मुझे नहीं पता कि आपके प्रोजेक्ट ने सूबो फाइल में DebuggingWorkingDirectory को क्यों स्टोर किया है। यदि वह एक उपयोगकर्ता विशिष्ट सेटिंग है, तो आपको उस स्टोरिंग पर विचार करना चाहिए। * .proj.user फ़ाइल नाम में। यदि यह सेटिंग प्रोजेक्ट पर काम करने वाले सभी उपयोगकर्ताओं के बीच साझा करने योग्य है, तो आपको इसे प्रोजेक्ट फ़ाइल में संग्रहीत करने पर विचार करना चाहिए।

स्रोत नियंत्रण के लिए सू फ़ाइल को जोड़ने के बारे में भी मत सोचो!SUO (soluton उपयोगकर्ता विकल्प) फ़ाइल का अर्थ उपयोगकर्ता-विशिष्ट सेटिंग्स है, और इसे उसी समाधान पर काम करने वाले उपयोगकर्ताओं के बीच साझा नहीं किया जाना चाहिए। यदि आप scc डेटाबेस में suo फाइल जोड़ रहे हैं, तो मुझे नहीं पता कि IDE में और कौन सी चीजें हैं जिन्हें आप तोड़ेंगे, लेकिन स्रोत नियंत्रण बिंदु से आप वेब प्रोजेक्ट scc इंटीग्रेशन को तोड़ देंगे, जिसका इस्तेमाल लैन बनाम इंटरनेट प्लग इन VSS एक्सेस के लिए अलग-अलग उपयोगकर्ताओं द्वारा, और आप पूरी तरह से टूटने का कारण भी बन सकते हैं (वीएसएस डेटाबेस पथ सू फ़ाइल में संग्रहीत है जो आपके लिए मान्य हो सकता है अन्य उपयोगकर्ता के लिए मान्य नहीं हो सकता)।

एलिन कॉन्स्टेंटिन (MSFT)

Comments

इसके अलावा, MSDN से: समाधान उपयोगकर्ता विकल्प (.Suo) फ़ाइल । पहला वाक्य Microsoft के इरादे को स्पष्ट करता है: "समाधान उपयोगकर्ता विकल्प (.suo) फ़ाइल में प्रति-उपयोगकर्ता समाधान विकल्प हैं। इस फ़ाइल को स्रोत कोड नियंत्रण में नहीं जांचना चाहिए।"

— डेविड आरआर

Answer 8

डिफ़ॉल्ट रूप से Microsoft का Visual SourceSafe इन फ़ाइलों को स्रोत नियंत्रण में शामिल नहीं करता है क्योंकि वे उपयोगकर्ता-विशिष्ट सेटिंग्स फ़ाइलें हैं। यदि आप स्रोत नियंत्रण के रूप में एसवीएन का उपयोग कर रहे हैं तो मैं उस मॉडल का पालन करूंगा।

Answer 9

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

Comments

मेरे पास .sou फ़ाइल बची हुई थी और यह संकुल को पुनः लोड करने में समस्या दे रही थी। .Sou फ़ाइल को हटाने से समस्या ठीक हो गई। धन्यवाद।

— मर्सिडीज

Answer 10

पर MSDN वेबसाइट , यह स्पष्ट रूप से कहा गया है कि

समाधान उपयोगकर्ता विकल्प (.suo) फ़ाइल में प्रति-उपयोगकर्ता समाधान विकल्प होते हैं। इस फाइल को सोर्स कोड कंट्रोल में चेक नहीं करना चाहिए ।

इसलिए मैं कहूंगा कि अपने स्रोत नियंत्रण में सामान की जाँच करते समय इन फ़ाइलों को अनदेखा करना बहुत सुरक्षित है।

Answer 11

मैं नहीं होता कुछ भी जो "उपयोगकर्ता" में बदल सकता है, आमतौर पर स्रोत नियंत्रण में अच्छा नहीं होता है। .suo, .user, obj / bin डायरेक्टरीज़

Answer 12

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

Answer 13

आप .user फ़ाइलों को स्रोत-नियंत्रण नहीं कर सकते, क्योंकि यह उपयोगकर्ता विशिष्ट है। इसमें रिमोट मशीन और अन्य उपयोगकर्ता-निर्भर चीजों का नाम शामिल है। यह एक vcproj संबंधित फाइल है।

.Suo फ़ाइल एक sln संबंधित फ़ाइल है और इसमें "समाधान उपयोगकर्ता विकल्प" (स्टार्टअप प्रोजेक्ट (s), विंडोज़ स्थिति (क्या डॉक किया गया है और कहां, क्या चल रहा है), आदि)

यह एक बाइनरी फ़ाइल है, और मुझे नहीं पता कि इसमें कुछ "उपयोगकर्ता संबंधी" है।

हमारी कंपनी में हम उन फ़ाइलों को स्रोत नियंत्रण में नहीं लेते हैं।

Answer 14

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

इसलिए बेहतर है कि उन्हें वर्जन कंट्रोल से न जोड़ा जाए, ताकि वीएस उन्हें दोबारा बना सके ताकि प्रत्येक डेवलपर को अपनी इच्छित विशिष्ट सेटिंग्स मिल सकें।

Answer 15

.user उपयोगकर्ता सेटिंग्स है, और मुझे लगता है .suo समाधान उपयोगकर्ता विकल्प है। आप इन फ़ाइलों को स्रोत नियंत्रण के तहत नहीं चाहते हैं; वे प्रत्येक उपयोगकर्ता के लिए फिर से बनाए जाएंगे।

Answer 16

नहीं।

मैं सिर्फ एक वास्तविक संक्षिप्त जवाब चाहता था, और कोई भी नहीं था।

Answer 17

तर्कसंगत समाशोधन का उपयोग करना उत्तर नहीं है। केवल .sln & * प्रोज को स्रोत कोड नियंत्रण में पंजीकृत किया जाना चाहिए।

मैं अन्य विक्रेताओं के लिए जवाब नहीं दे सकता। यदि मैं सही ढंग से याद करता हूं, तो ये फाइलें "उपयोगकर्ता" विशिष्ट विकल्प हैं, आपका पर्यावरण।

Comments

only the .sln & .*proj should be registered- क्या आप यहां बहुत सारी फाइलें नहीं भूलते?

— वुल्फ

@ स्पष्ट के अलावा भेड़िया

— पोलुक्स

Answer 18

संस्करण नियंत्रण में उन फ़ाइलों में से किसी को भी न जोड़ें। ये फाइलें कार्य स्टेशन की विशिष्ट जानकारी के साथ स्वतः उत्पन्न होती हैं, अगर चेक-इन संस्करण नियंत्रण है जो अन्य कार्य स्टेशनों में परेशानी का कारण होगा।

Answer 19

नहीं, वे स्रोत नियंत्रण के लिए प्रतिबद्ध नहीं होना चाहिए क्योंकि वे डेवलपर / मशीन-विशिष्ट स्थानीय सेटिंग्स हैं।

GitHub विज़ुअल स्टूडियो उपयोगकर्ताओं की अनदेखी करने के लिए सुझाए गए फ़ाइल प्रकारों की एक सूची बनाए रखें https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

Svn के लिए, मेरे पास निम्नलिखित global-ignoreसंपत्ति सेट है:

* .DotSettings.User
* .onetoc2
* .suo
.vs
PrecompiledWeb
thumbs.db
obj
बिन
डिबग
* .user
* .vshost। *
* .Tss
* .dbml.layout

Answer 20

यदि आप ProjectProperties> डिबगिंग> पर्यावरण में अपनी निष्पादन योग्य डीआईआर निर्भरता सेट करते हैं , तो पथ '.user' फ़ाइलों में संग्रहीत किए जाते हैं।

मान लीजिए कि मैंने इस स्ट्रिंग को उपर्युक्त फ़ील्ड में सेट किया है: "PATH = C: \ xyz \ bin" यह इसी तरह से '.user' फ़ाइल में संग्रहीत किया जाएगा:

<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>

OpenCV में काम करने के दौरान इससे हमें बहुत मदद मिली। हम विभिन्न परियोजनाओं के लिए OpenCV के विभिन्न संस्करणों का उपयोग कर सकते हैं। एक और फायदा यह है कि, हमारी परियोजनाओं को एक नई मशीन पर स्थापित करना बहुत आसान था। हमें बस इसी निर्भरता की मात्रा की नकल करनी थी। इसलिए कुछ परियोजनाओं के लिए, मैं '.user' को स्रोत नियंत्रण में जोड़ना पसंद करता हूं।

हालांकि, यह पूरी तरह से परियोजनाओं पर निर्भर है। आप अपनी जरूरतों के आधार पर कॉल ले सकते हैं।

Comments

प्रतीकात्मक लिंक भी इस उद्देश्य के लिए बहुत अच्छा काम करते हैं।

— s --unıɐ ɐ qɐp

Answer 21

के रूप में अन्य उत्तर में बताया गया है, दोनों .suoऔर .userनहीं, स्रोत नियंत्रण में जोड़ा जाना चाहिए, क्योंकि वे उपयोगकर्ता / मशीन विशिष्ट (btw हैं .suoवी.एस. के नवीनतम संस्करण के लिए समर्पित अस्थायी निर्देशिका में ले जाया गया .vsहै, जो पूरी तरह से स्रोत नियंत्रण से बाहर रखा जाना चाहिए)।

हालाँकि, यदि आपके एप्लिकेशन को VS में डिबगिंग के लिए पर्यावरण के कुछ सेटअप की आवश्यकता होती है (ऐसी सेटिंग्स आमतौर पर .userफ़ाइल में रखी जाती हैं), तो एक नमूना फ़ाइल तैयार करना आसान हो सकता है (नामकरण इसे पसंद करें .user.SAMPLE) और इसे संदर्भों के लिए स्रोत नियंत्रण में जोड़ें।

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