विजुअल स्टूडियो (2008) में बड़े समाधानों के लिए सर्वोत्तम अभ्यास [बंद]

Question

हमारे पास लगभग 100+ परियोजनाओं के साथ एक समाधान है, जिनमें से अधिकांश C # हैं। स्वाभाविक रूप से, इसे खोलने और बनाने दोनों में लंबा समय लगता है, इसलिए मैं ऐसे जानवरों के लिए सर्वोत्तम प्रथाओं की तलाश कर रहा हूं। जिन सवालों के जवाब के साथ मैं उम्मीद कर रहा हूं, वे हैं:

• आप परियोजनाओं के बीच संदर्भों को सबसे अच्छी तरह से कैसे संभालते हैं
  • "स्थानीय कॉपी करना" चालू या बंद होना चाहिए?

• क्या प्रत्येक परियोजना को अपने स्वयं के फ़ोल्डर में निर्माण करना चाहिए, या क्या उन्हें सभी एक ही आउटपुट फ़ोल्डर में बनाना चाहिए (वे सभी एक ही एप्लिकेशन का हिस्सा हैं)

• क्या समाधान के फ़ोल्डर सामान को व्यवस्थित करने का एक अच्छा तरीका है?

मुझे पता है कि समाधान को कई छोटे समाधानों में विभाजित करना एक विकल्प है, लेकिन यह अपने स्वयं के रिफैक्टरिंग और सिरदर्द के निर्माण के साथ आता है, इसलिए शायद हम इसे एक अलग धागे के लिए बचा सकते हैं :-)

Comments

क्या मैं पूछ सकता हूं कि एकल समाधान के लिए 100+ परियोजनाओं की आवश्यकता क्यों है? क्या वे प्रत्येक अपनी विधानसभा बना रहे हैं?

— नील एन

हां, वे हैं, और उनमें से प्रत्येक एक तार्किक रूप से अलग कार्यशीलता का प्रतिनिधित्व करता है।

— आईविंड

@ ईविंद - यह नहीं है कि वर्ग और नाम स्थान किस लिए हैं? अलग-अलग विधानसभाओं से आपको क्या फायदा होता है? मैं कुछ के बारे में सोच सकता हूं, जैसे कि संभावित रूप से छोटे उन्नयन और मेमोरी का उपयोग (यदि कुछ लोड नहीं किया गया है), लेकिन संकलन और प्रबंधन के लिए निश्चित रूप से 100+ असेंबली होने की लागत है।

— si618

@ मर्क मैं आपका दर्द महसूस करता हूं। हम यहां 94 परियोजनाओं तक हैं। अभी इसके बारे में बहुत कुछ नहीं किया जा सकता है, क्योंकि हमें कई टीमों के विकास को पुनर्गठन के लिए रोकना होगा। हमें 3 EXE प्रोजेक्ट मिले हैं जो अन्य 91 का संदर्भ देते हैं। मैं एक सामान्य आउटपुट फ़ोल्डर के साथ प्रयोग कर रहा हूं, अब तक लाभ बहुत प्रभावशाली हैं।

— केविन

यार, 100+? जो हमारे पास है उसके लिए यह कुछ भी नहीं है ... अब लगभग 600 को यहां धकेलना ...

— सी जॉनसन

Answer 1

आपको इन दो MSBuild लेखों में रुचि हो सकती है जो मैंने लिखे हैं।

MSBuild: विश्वसनीय बिल्ड बनाने के लिए सर्वश्रेष्ठ अभ्यास, भाग 1

MSBuild: विश्वसनीय बिल्ड बनाने के लिए सर्वश्रेष्ठ अभ्यास, भाग 2

विशेष रूप से भाग 2 में एक खंड है बड़े स्रोत के पेड़ जो आप देखना चाहते हैं।

हालांकि यहाँ अपने सवालों के संक्षिप्त जवाब देने के लिए:

• CopyLocal? यकीन के लिए इसे बंद करें
• एक या कई आउटपुट फ़ोल्डर में बनाएँ? एक आउटपुट फ़ोल्डर में बनाएँ
• समाधान फ़ोल्डर? यह स्वाद का मामला है।

सईद इब्राहिम हाशिमी

मेरी पुस्तक: Microsoft बिल्ड इंजन के अंदर: MSBuild और टीम फाउंडेशन बिल्ड का उपयोग करना

Comments

धन्यवाद आदमी, मैं उन लोगों की जाँच करने के लिए सुनिश्चित हो जाएगा!

— पलक

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

— irperez

टिप्पणियों के लिए धन्यवाद इरेज़र

— सैयद इब्राहिम हाशिमी

CopyLocal अक्षम करने के लिए UNCONDITIONAL अनुशंसा के लिए -1। CopyLocal सेट करें = गलत परिनियोजन समय के दौरान भिन्न समस्याएँ पैदा कर सकता है। अपने ब्लॉग पोस्ट "ऐसा नहीं बदलें" कॉपी स्थानीय "परियोजना के संदर्भ गलत पर, जब तक subsequences को समझते हैं।" (देखें geekswithblogs.net/mnf/archive/2012/12/09/... )

— माइकल Freidgeim

एकाधिक थ्रेड्स के साथ संकलन करने पर "एक आउटपुट फ़ोल्डर में निर्माण कर सकता है" समस्याएँ पैदा कर सकता है?

— ब्रूनोएलएम

Answer 2

बख्शने के लिए +1सामान को व्यवस्थित करने में मदद करने के लिए समाधान फ़ोल्डरों के ।

अपने स्वयं के फ़ोल्डर में प्रोजेक्ट निर्माण के लिए +1। हमने शुरुआत में एक सामान्य आउटपुट फ़ोल्डर की कोशिश की थी और इससे सूक्ष्म और दर्दनाक हो सकते हैं ताकि पता चल सके।

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

Comments

+1 मुझे आम आउटपुट फ़ोल्डर समाधान के साथ भी समस्या है। मुझे समझ नहीं आया कि "समाधान के लिए परियोजना संदर्भ" का क्या मतलब है, कृपया थोड़ा और समझाएं ...

— मारीशियो शेफ़र

जैसे कि हम VS-> Add Reference-> प्रोजेक्ट्स का उपयोग करते हैं, VS-> Add Reference-> ब्राउज के बजाय। छोटा बिंदु मुझे पता है लेकिन कुछ लोग इसे अलग तरीके से करते हैं (और मुझे लगता है कि यह अधिक सिरदर्द का कारण बनता है)। यदि आप MSBuild csproj पाठ को देखते हैं, तो आप संदर्भ के बजाय ProjectReference गुण देखेंगे।

— si618

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

— थॉमस ब्रैट

ऐ, आम आउटपुट डायरेक्टरी में बहुत दर्द होता है, खासकर जब रीशर का उपयोग किया जाता है। वास्तव में दिनांक संदर्भों में से।

— फ्लोरियन डॉयोन

@ केविन, अब कई साल हो गए हैं, लेकिन स्मृति से एक उदाहरण एक ही विधानसभा को संदर्भित करने वाली दो परियोजनाएं हैं, एक बाहरी पुस्तकालय का कहना है जिसे संदर्भित नहीं किया गया है। ठीक है जब वे एक ही संस्करण पर होते हैं, लेकिन फिर इस लाइब्रेरी की एक नई रिलीज़ सामने आती है, लेकिन केवल एक परियोजना उनके संदर्भ को अपडेट करती है, जो संस्करण आम आउटपुट फ़ोल्डर में उपयोग किया जाता है?

— si618

Answer 3

उन परियोजनाओं को अनलोड करें जिनका आप अक्सर उपयोग नहीं करते हैं, और एक एसएसडी खरीदते हैं। एक SSD संकलन समय में सुधार नहीं करता है, लेकिन Visual Studio खोलने / बंद करने / बनाने के लिए दो बार तेज़ हो जाता है।

Comments

यह ध्यान देने योग्य है कि एक परियोजना को अनलोड करना एक प्रति-उपयोगकर्ता सेटिंग है, इसलिए आपकी टीम के डेवलपर्स केवल उन परियोजनाओं को लोड कर सकते हैं जिनकी वे देखभाल करते हैं। इससे हमारी टीम को वास्तव में मदद मिली है।

— पेज

आप डिफ़ॉल्ट रूप से लोड नहीं करने के लिए क्या परिभाषित करने के लिए समाधान लोड प्रबंधक एक्सटेंशन Visualstudiogallery.msdn.microsoft.com/… का उपयोग कर सकते हैं

— माइकल फ्रीजिम

Answer 4

हमारे पास एक समान समस्या है क्योंकि हमारे पास निपटने के लिए 109 अलग-अलग परियोजनाएं हैं। हमारे अनुभवों के आधार पर मूल सवालों के जवाब देने के लिए:

1. आप परियोजनाओं के बीच संदर्भों को सबसे अच्छी तरह से कैसे संभालते हैं

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

2. क्या मुझे स्थानीय "कॉपी या ऑन" होना चाहिए?

हमारे अनुभव में बंद। अतिरिक्त प्रतिलिपि केवल बिल्ड समय में जोड़ता है।

3. क्या प्रत्येक परियोजना को अपने स्वयं के फ़ोल्डर में निर्माण करना चाहिए, या क्या उन्हें सभी एक ही आउटपुट फ़ोल्डर में बनाना चाहिए (वे सभी एक ही एप्लिकेशन का हिस्सा हैं)

हमारे सभी आउटपुट को 'बिन' नामक एक फ़ोल्डर में रखा जाता है। यह विचार किया जा रहा है कि यह फ़ोल्डर वैसा ही है, जब सॉफ्टवेयर तैनात किया जाता है। यह उन समस्याओं को रोकने में मदद करता है जब डेवलपर सेटअप परिनियोजन सेटअप से भिन्न होता है।

4. क्या समाधान फ़ोल्डर सामान को व्यवस्थित करने का एक अच्छा तरीका है?

हमारे अनुभव में नहीं। एक व्यक्ति की फ़ोल्डर संरचना दूसरे की दुःस्वप्न है। दीप नेस्टेड फ़ोल्डर्स बस कुछ भी खोजने के लिए समय बढ़ाते हैं। हमारे पास पूरी तरह से सपाट संरचना है, लेकिन हमारी परियोजना फाइलों, विधानसभाओं और नामस्थानों को एक ही नाम दें।

---

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

हमारे समाधान लेआउट का एक आंशिक उदाहरण:

\bin

OurStuff.SLN

OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]

Comments

एकाधिक थ्रेड्स के साथ संकलन करने पर "एक आउटपुट फ़ोल्डर में निर्माण कर सकता है" समस्याएँ पैदा कर सकता है?

— ब्रूनोएलएम

Answer 5

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

समय खुलने और समय के निर्माण के लिए, कि छोटे समाधानों को तोड़े बिना इसे ठीक करना कठिन है। आप यहां गति बढ़ाने के लिए बिल्ड (Google "समानांतर MS Build" को ऐसा करने के तरीके और UI में एकीकृत करने के लिए) की जांच कर सकते हैं। इसके अलावा, डिजाइन को देखें और देखें कि क्या आपके कुछ प्रोजेक्टों को कम करने के परिणामस्वरूप कम समग्र मदद मिल सकती है।

Answer 6

इमारत के दर्द को कम करने के संदर्भ में, आप विशिष्ट परियोजनाओं के निर्माण को सक्षम या अक्षम करने के लिए बिल्ड के लिए "कॉन्फ़िगरेशन प्रबंधक ..." विकल्प का उपयोग कर सकते हैं। आपके पास एक "प्रोजेक्ट [एन] बिल्ड" हो सकता है जो कुछ विशेष परियोजनाओं को बाहर कर सकता है और जब आप विशिष्ट परियोजनाओं को लक्षित कर रहे हों तो इसका उपयोग कर सकते हैं।

जहाँ तक 100+ परियोजनाएँ हैं, मुझे पता है कि आप इस सवाल को हल करने के लिए अपने हल के आकार में कटौती के लाभों के बारे में नहीं जानना चाहते हैं, लेकिन मुझे लगता है कि लोड समय (और) में तेजी लाने के लिए आपके पास कोई अन्य विकल्प नहीं है स्मृति उपयोग) devenv की।

Comments

हम्म, क्या यह गलत होने के लिए, या सिर्फ असहमति के लिए उतारा गया था? मैं पूर्व के साथ रह सकता हूं यदि आप मुझे बता सकते हैं कि क्यों।

— माइकल मीडोज़

सहमत, मैं टिप्पणी के बिना नीचा दिखाना पसंद करता हूं, इसलिए माइकल आपको समीकरण को संतुलित करने के लिए मेरा +1 मिलता है ;-)

— si618

btw, मुझे व्यक्तिगत रूप से इस तरह की चीज़ के लिए कॉन्फ़िगरेशन प्रबंधन के साथ चक्कर लगाना पसंद नहीं है। क्यों? क्योंकि यदि आप गलती से अपना संशोधित कॉन्फ़िगरेशन करते हैं, तो आपका बिल्ड सर्वर या अन्य डेवलपर्स प्रभावित होंगे।

— si618

माना। दरअसल, बहुत सारी परियोजनाओं के समाधान के साथ भी यही समस्या लागू होती है। :)

— माइकल मीडोज

Answer 7

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

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

ध्यान दें

उपरोक्त मेरे समाधानों के लिए काम करता है, जो आम तौर पर वेब अनुप्रयोग हैं और मैंने संदर्भों के साथ किसी भी मुद्दे का अनुभव नहीं किया है, लेकिन यह संभव हो सकता है!

Answer 8

हमारे पास एक समान मुद्दा है। हम इसे छोटे समाधानों का उपयोग करके हल करते हैं। हमारे पास एक मास्टर समाधान है जो सब कुछ खोलता है। लेकिन पूर्ण। उस पर बुरा है। इसलिए, हम डेवलपर प्रकार द्वारा छोटे समाधानों को विभाजित करते हैं। तो, DB डेवलपर्स के पास एक समाधान है जो उन परियोजनाओं को लोड करता है जिनकी वे देखभाल करते हैं, सेवा डेवलपर्स और UI डेवलपर्स एक ही चीज़। यह दुर्लभ है जब किसी को पूरे समाधान को खोलने के लिए प्राप्त करना होता है कि उन्हें दिन के आधार पर क्या करना चाहिए। यह एक रामबाण नहीं है - यह अपसाइड और डाउनसाइड है। इस लेख में "बहु-समाधान मॉडल" देखें (वीएसएस का उपयोग करने के बारे में भाग की उपेक्षा करें :)

Answer 9

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

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

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

मुझे यह एक सर्वोत्तम अभ्यास लगता है क्योंकि इस बात की कोई सीमा नहीं है कि जब आप इस तरीके से शारीरिक रूप से टूट जाते हैं तो समग्र प्रयास कितने जटिल हो सकते हैं। सभी परियोजनाओं को एक ही समाधान में लाना अंततः एक ऊपरी सीमा को प्रभावित करेगा।

आशा है कि यह जानकारी मदद करती है।

Answer 10

हमारे पास लगभग 60+ परियोजनाएं हैं और हम समाधान फ़ाइलों का उपयोग नहीं करते हैं। हमारे पास C # और VB.Net परियोजनाओं का मिश्रण है। प्रदर्शन हमेशा एक मुद्दा था। हम एक ही समय में सभी परियोजनाओं पर काम नहीं करते हैं। प्रत्येक डेवलपर उन परियोजनाओं के आधार पर अपनी स्वयं की समाधान फाइलें बनाता है, जिन पर वे काम कर रहे हैं। समाधान फ़ाइलों को हमारे स्रोत नियंत्रण में जाँच नहीं मिलती है।

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

हम प्रोजेक्ट संदर्भ का उपयोग नहीं करते हैं, इसके बजाय कॉमनबिन फ़ोल्डर से फ़ाइल आधारित संदर्भ। मैंने एक कस्टम MSBuild टास्क लिखा जो परियोजनाओं का निरीक्षण करेगा और बिल्ड ऑर्डर का निर्धारण करेगा।

हम कुछ वर्षों से इसका उपयोग कर रहे हैं और हमें कोई शिकायत नहीं है।

Comments

क्या आप अपने कस्टम msbuild कार्य को साझा करना चाहेंगे?

— andreapier

Answer 11

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

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

मेरी सलाह यह है कि ऐसा करें और एक केंद्रीकृत ढांचा विकसित करें (यदि आप करेंगे तो एंटरप्राइज लाइब्रेरी का अपना कार्यान्वयन)। आप या तो इसे साझा करने के लिए जीएसी कर सकते हैं या आप सीधे फ़ाइल स्थान को संदर्भित कर सकते हैं ताकि आपके पास एक केंद्रीय स्टोर हो। आप केंद्रीकृत व्यावसायिक वस्तुओं के लिए भी एक ही रणनीति का उपयोग कर सकते हैं।

यदि आप सीधे DLL का संदर्भ लेना चाहते हैं, तो आप इसे अपने प्रोजेक्ट में कॉपी करना चाहते हैं स्थानीय कॉपी के साथ (कहीं न कहीं c: \ mycompany \ bin \ mycompany.dll)। एक रनटाइम आपको अपने ऐप में कुछ सेटिंग्स जोड़ने की आवश्यकता होगी। इसे GAC या रनटाइम बिन में नहीं फ़ाइल के संदर्भ में बनाने के लिए web.config या web.config। सभी वास्तविकताओं में यह मायने नहीं रखता है कि यह स्थानीय है या नहीं, या यदि dll बिन में समाप्त होता है या यहां तक ​​कि GAC में भी है, क्योंकि कॉन्फ़िगरेशन उन दोनों को ओवरराइड करेगा। मुझे लगता है कि स्थानीय की नकल करना और एक गन्दा व्यवस्था करना बुरा व्यवहार है। यदि आपको उन विधानसभाओं में से एक में डिबग करने की आवश्यकता है, तो आपको स्थानीय रूप से अस्थायी रूप से कॉपी करना होगा।

आप GAC के बिना विश्व स्तर पर DLL का उपयोग करने के बारे में मेरा लेख पढ़ सकते हैं। मैं वास्तव में जीएसी को नापसंद करता हूं क्योंकि यह xcopy तैनाती को रोकता है और अनुप्रयोगों पर एक ऑटोरेस्टार्ट को ट्रिगर नहीं करता है।

http://nbaked.wordpress.com/2010/03/28/gac-alternative/

Answer 12

CopyLocal सेट करें = गलत निर्माण समय कम करेगा, लेकिन परिनियोजन समय के दौरान अलग-अलग समस्याएँ पैदा कर सकता है।

ऐसे कई परिदृश्य हैं, जब आपको कॉपी लोकल 'ट्रू टू लेफ्ट' की आवश्यकता होती है, जैसे टॉप-लेवल प्रोजेक्ट्स, सेकंड-लेवल डिपेंडेंसीज, डीएलएल रिफ्लेक्ट करके बुलाए जाते हैं।

CopyLocal = false की स्थापना के साथ मेरा अनुभव सफल नहीं रहा। मेरे ब्लॉग पोस्ट " प्रो नॉट चेंज" कॉपी लोकल "प्रोजेक्ट रेफरेंस का प्रो और समरी का सारांश देखें , जब तक कि बाद में समझ न आए।"