2009-05-29 22 views
11

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

MyFramework एक आंतरिक उत्पाद है और औपचारिक रिलीज शेड्यूल नहीं है, और यह समाधान के लिए भी जाता है।

मैं सभी 12 परियोजनाओं में डीएलएल बनाने और कॉपी करने की इच्छा नहीं रखूंगा, यानी नए डेवलपर्स को केवल svn-checkout करने में सक्षम होना चाहिए, और काम पर जाना चाहिए।

इन सभी समाधानों में MyFramework साझा करने का सबसे अच्छा तरीका क्या है?

उत्तर

7

जब से तुम SVN का उल्लेख है, आप प्रत्येक समाधान यह का उपयोग करता है के काम कॉपी में externals को "आयात" ढांचा परियोजना इस्तेमाल कर सकते हैं।यह इस तरह एक लेआउट के लिए नेतृत्व करेंगे: इस समाधान के साथ

C:\Projects 
    MyFramework 
    MyFramework.csproj 
    <MyFramework files> 

    SolutionA 
    SolutionA.sln 
    ProjectA1 
     <ProjectA1 files> 
    MyFramework <-- this is a svn:externals definition to "import" MyFramework 
     MyFramework.csproj 
     <MyFramework files> 

, आप प्रत्येक समाधान यह का उपयोग करता है में उपलब्ध MyFramework के स्रोत कोड है। लाभ यह है कि आप इन समाधानों में से प्रत्येक के भीतर से MyFramework के स्रोत कोड को बदल सकते हैं (बिना किसी अलग परियोजना पर स्विच किए)।

लेकिन: साथ ही यह भी एक बड़ा नुकसान है, क्योंकि यह किसी अन्य के लिए संशोधित करते समय कुछ समाधानों के लिए MyFramwork को तोड़ना बहुत आसान बनाता है।

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

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

+0

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

4

कि एक आपदा की तरह लगता है ... कैसे आप डेवलपर्स नाश/दूसरों के कार्य को तोड़ने के ...

अगर मैं तुम्हें थे, मैं एक पूरी तरह से अलग समाधान में MyFrameWork डाल चाहते हैं के साथ सामना करते हैं। जब कोई डेवलपर 12 परियोजनाओं में से एक विकसित करना चाहता है, तो वह एक आईडीई & में प्रोजेक्ट समाधान खोलता है, एक अलग आईडीई में MyFrameWork खोलता है।

यदि आप मजबूत नाम अपने MyFramework assemby & यह GAC, और अपने अन्य परियोजनाओं में इसे संदर्भ, फिर "प्रतिलिपि बनाई जा रही DLLs" नहीं एक मुद्दा होगा।

आप बस MyFrameWork बनाएं (और एक पोस्टबिल्ड इवेंट इसे गधे के रूप में रख सकता है ताकि उसे गधे के कैश में रखा जा सके) और फिर अपनी अन्य परियोजना बनाएं।

+0

जो निश्चित रूप से एक विचार है, लेकिन हमारे पास सभी परियोजनाओं पर सीआई है इसलिए कम से कम हम इसे जल्द ही पाएंगे। जहां तक ​​जीएसी है, मैं संभवतः जीएसी से बचना चाहता हूं। –

1

मैं एक और पोस्टर से सहमत हूं - जो मुसीबत की तरह लगता है। लेकिन अगर आप इसे "सही रास्ता" नहीं करना चाहते हैं तो मैं इसे करने के दो अन्य तरीकों के बारे में सोच सकता हूं। हमने नीचे नंबर 1 के समान कुछ इस्तेमाल किया। (देशी सी ++ अनुप्रयोग के लिए)

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

  2. रेपो में बाइनरी रखें (एक अच्छा विचार नहीं)। यहां तक ​​कि इस मामले में आश्रित परियोजनाओं को प्राप्त करना होता है और उन्हें पता होना चाहिए कि किस संस्करण को प्राप्त करना है।

आखिरकार हमने अपनी परियोजनाओं के लिए क्या करने की कोशिश की थी, यह नकल था कि हम तीसरे पक्ष के पुस्तकालयों का उपयोग कैसे करते हैं और इसका उल्लेख करते हैं।

आप क्या कर सकते हैं निर्भरता के लिए एक रिलीज पैकेज बनाते हैं जो स्वयं को पथ env चर सेट करता है। मैं मशीन पर कई संस्करणों को मौजूद करने की अनुमति दूंगा और फिर निर्भर परियोजनाओं लिंक/संदर्भ विशिष्ट संस्करणों को अनुमति दूंगा।

कुछ

तरह
$(PROJ_A_ROOT) = c:\mystuff\libraryA 

$(PROJ_A_VER_X) = %PROJ_A_ROOT%\VER_X 

और फिर संस्करण आप चाहते हैं संदर्भ निर्भर समाधान में या तो विशिष्ट नाम, या संस्करण env var का उपयोग करके।

सुंदर नहीं है, लेकिन यह काम करता है।

2

"सर्वोत्तम तरीका" आपके पर्यावरण पर निर्भर करेगा। मैंने एक टीएफएस-आधारित, सतत एकीकरण वातावरण में काम किया, जहां रात के निर्माण ने बाइनरी को एक हिस्से में तैनात किया। शेयर पर संदर्भित सभी निर्भर परियोजनाएं। जब यह धीमा हो गया, तो मैंने डेवलपर्स को परियोजना फाइलों को बदले बिना साझा बाइनरी की स्थानीय प्रतिलिपि बनाने की अनुमति देने के लिए कुछ टूल बनाए।

2

क्या 12 समाधानों में से किसी एक में काम करने के लिए नियमित रूप से "ढांचे" कोड में परिवर्तन की आवश्यकता होती है?

यदि ऐसा है तो आपका ढांचा शायद नया है और बस बनाया जा रहा है, इसलिए मैं सभी समाधानों में ढांचा परियोजना शामिल करूंगा। आखिरकार, अगर काम निर्देश देता है कि आपको फ्रेमवर्क कोड बदलना है, तो ऐसा करना आसान होना चाहिए।

चूंकि एक समाधान से बने ढांचे में परिवर्तन अन्य सभी समाधानों को प्रभावित करेंगे, तो ब्रेक होगा, और आपको उनसे निपटना होगा।

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

2

svn:externals यदि आप कुछ नियमों का पालन करते हैं तो यह अच्छी तरह से ख्याल रखेगा।

सबसे पहले, यदि आप एसवीएन के लिए रिश्तेदार यूआरआई (^^चरित्र से शुरू) का उपयोग करते हैं तो यह सुरक्षित है: बाह्य परिभाषाएं और यदि संभव हो तो परियोजनाओं को उसी भंडार में डाल दें। इस प्रकार परिभाषा मान्य रहेगी भले ही उपवर्तन सर्वर को एक नए यूआरएल में ले जाया गया हो।

दूसरा, सुनिश्चित करें कि आप एसवीएन पुस्तक से निम्नलिखित संकेतों का पालन करें। यादृच्छिक टूटना और अस्थिर टैग से बचने के लिए बाहरी परिभाषाएँ: अपने SVN में प्रयोग करें पेग-revs

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

+0

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

1

एक स्केलेबल समाधान समाधान निर्देशिका इतने पर svn-external करने के लिए अपने अन्य परियोजना के लिए कि आपके आयातित परियोजनाओं समानांतर दिखाई है रों। इसके लिए कारण नीचे दिए गए हैं।

"आयातित" परियोजनाओं के लिए एक अलग उप-निर्देशिका का उपयोग करना, उदा। externals, एसवीएन-बाहरी के माध्यम से एक अच्छा विचार प्रतीत होता है जब तक कि आपके पास परियोजनाओं के बीच गैर-तुच्छ निर्भरता न हो। उदाहरण के लिए, मान लें कि परियोजना एक परियोजना बी, और परियोजना सी पर परियोजना बी पर परियोजना पर निर्भर करता है आप तो परियोजना एक के साथ एक समाधान एस है, तो आप निम्न निर्देशिका संरचना के साथ खत्म हो जाएगा:

# BAD SOLUTION # 
S 
+---S.sln 
+---A 
| \---A.csproj 
\---externals 
    +---B  <--- A's dependency 
    | \---B.csproj 
    \---externals 
     \---C  <--- B's dependency 
      \---C.csproj 

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

इसके अलावा, यदि आपकी परियोजनाएं NuGet निर्भरताओं का उपयोग करती हैं, तो वे आमतौर पर packages शीर्ष-स्तरीय निर्देशिका के भीतर लोड हो जाते हैं। इसका मतलब है कि externals उप-निर्देशिका के भीतर परियोजनाओं के NuGet संदर्भ टूटा जाएगा।

इसके अलावा, अगर आप SVN के अलावा Git उपयोग करते हैं, पर नज़र रखने के परिवर्तन का एक सुझाया गया तरीका प्रत्येक परियोजना के लिए एक अलग Git भंडार के लिए समाधान के भीतर परियोजनाओं के लिए git submodule का उपयोग करता है के लिए एक अलग Git भंडार है, और उसके बाद। यदि कोई गिट सबमिशन पैरेंट मॉड्यूल की तत्काल उप-निर्देशिका नहीं है, तो गिट सबमिशन कमांड एक क्लोन बना देगा जो तत्काल उप-निर्देशिका है।

एक ही परत पर सभी परियोजनाओं का एक अन्य लाभ यह है कि आप एक "सुपर-सॉल्यूशन" बना सकते हैं, जिसमें आपके सभी समाधानों (गिट या एसवीएन-बाहरी के माध्यम से ट्रैक किया गया) से परियोजनाएं होती हैं, जो बदले में आपको अनुमति देती है एक एकल समाधान-पुनर्निर्माण के साथ जांच करें कि किसी भी प्रोजेक्ट में किए गए किसी भी बदलाव से अन्य सभी परियोजनाओं के अनुरूप है।

# GOOD SOLUTION # 
S 
+---S.sln 
+---A 
| \---A.csproj 
+---B  <--- A's dependency 
| \---B.csproj 
\---C  <--- B's dependency 
    \---C.csproj 
संबंधित मुद्दे