"कॉपी लोकल" और प्रोजेक्ट संदर्भों के लिए सबसे अच्छा अभ्यास क्या है?

Question

मेरे पास एक बड़ी सी # समाधान फ़ाइल (~ 100 परियोजनाएं) हैं, और मैं बिल्ड समय में सुधार करने की कोशिश कर रहा हूं। मुझे लगता है कि "कॉपी लोकल" हमारे लिए कई मामलों में बेकार है, लेकिन मैं सर्वोत्तम प्रथाओं के बारे में सोच रहा हूं।

हमारे .sln में, हमारे पास असेंबली B के आधार पर आवेदन A है जो असेंबली C. पर निर्भर करता है। हमारे मामले में, "B" के दर्जनों और "C" के एक मुट्ठी भर हैं। चूँकि ये सभी .sln में शामिल हैं, हम प्रोजेक्ट संदर्भ का उपयोग कर रहे हैं। वर्तमान में सभी असेंबली $ (सॉल्यूशनडियर) / डीबग (या रिलीज़) में निर्मित होती हैं।

डिफ़ॉल्ट रूप से, विज़ुअल स्टूडियो इन प्रोजेक्ट संदर्भों को "कॉपी लोकल" के रूप में चिह्नित करता है, जिसके परिणामस्वरूप प्रत्येक "सी" को $ "(सॉल्यूडिर) / डीबग में कॉपी किया जाता है जो प्रत्येक" बी "के लिए एक बार बनता है। यह फिजूलखर्ची लगती है। अगर मैं "स्थानीय कॉपी करें" बंद कर दूं तो क्या गलत हो सकता है? बड़े सिस्टम वाले अन्य लोग क्या करते हैं?

जाँच करना:

प्रतिक्रियाओं के बहुत सारे छोटे .sln फ़ाइलों में निर्माण को तोड़ने का सुझाव देते हैं ... ऊपर दिए गए उदाहरण में, मैं "बी" पहले नींव कक्षाएं "बी" का निर्माण करूंगा, इसके बाद मॉड्यूल "बी" के थोक, और फिर कुछ एप्लिकेशन, " ए"। इस मॉडल में, मुझे B से C के लिए गैर-परियोजना संदर्भ देने की आवश्यकता है। जो समस्या मैं वहां चला रहा हूं वह यह है कि "डीबग" या "रिलीज़" संकेत पथ में बेक हो जाती है और मैं "B" के मेरे रिलीज़ बिल्ड का निर्माण करता हूं। डिबग के खिलाफ "सी" बनाता है।

आप में से उन लोगों के लिए जो बिल्ड को कई .sln फ़ाइलों में विभाजित करते हैं, आप इस समस्या को कैसे प्रबंधित करते हैं?

Comments

आप सीधे परियोजना फ़ाइल को संपादित करके अपने संकेत पथ को डिबग या रिलीज़ निर्देशिका बना सकते हैं। डिबग या रिलीज़ के स्थान पर $ (कॉन्फ़िगरेशन) का उपयोग करें। जैसे, <HintPath> .. \ output \ $ (कॉन्फ़िगरेशन) \ test.dll </ HintPath> यह एक दर्द है जब आपके पास बहुत सारे संदर्भ हैं (हालांकि किसी के लिए ऐड-इन लिखना मुश्किल नहीं होना चाहिए इसे प्रबंधित करें)।

— अल्ट्रावेलोसिटी

क्या दृश्य स्टूडियो में 'कॉपी लोकल' <Private>True</Private>एक csproj के समान है ?

— कर्नल पैनिक

लेकिन .slnछोटे लोगों में बंटवारे से वीएस की स्वचालित दु: खद निर्भरता की गणना हो जाती है <ProjectReference/>। मैं कई छोटे से .slnअधिक एक बड़े .slnखुद से सिर्फ इसलिए चले गए हैं क्योंकि VS कम समस्याओं का कारण बनता है ... तो, शायद अनुवर्ती मूल प्रश्न का एक नहीं-सबसे अच्छा समाधान मान रहा है? ;-)

— बिंकी

जिज्ञासा के कारण। चीजों को जटिल क्यों करते हैं और पहले स्थान पर 100+ परियोजनाएं हैं? क्या यह बुरा डिज़ाइन है या क्या है?

— उपयोगी बत्ती

@ColonelPanic हाँ। कम से कम यह वह चीज है जो डिस्क पर बदल जाती है जब मैं जीयूआई में टॉगल करता हूं।

— Zero3

Answer 1

पिछले प्रोजेक्ट में मैंने प्रोजेक्ट रेफरेंस के साथ एक बड़े समाधान के साथ काम किया और एक प्रदर्शन समस्या में भी टकराया। समाधान तीन गुना था:

1. हमेशा कॉपी लोकल प्रॉपर्टी को झूठा सेट करें और कस्टम msbuild चरण के माध्यम से इसे लागू करें

2. प्रत्येक प्रोजेक्ट के लिए एक ही डायरेक्टरी के लिए आउटपुट डायरेक्टरी सेट करें (अधिमानतः $ के सापेक्ष)

3. डिफ़ॉल्ट सीएस लक्ष्य जो फ्रेमवर्क के साथ भेज दिया जाता है, वर्तमान में बनाए जा रहे प्रोजेक्ट के आउटपुट डायरेक्टरी में कॉपी किए जाने वाले संदर्भों के सेट की गणना करता है। चूंकि इसके लिए 'संदर्भ' संबंध के तहत एक सकर्मक समापन की गणना की आवश्यकता होती है, यह बहुत महंगा हो सकता है। इसके लिए मेरा GetCopyToOutputDirectoryItemsलक्ष्य आम लक्ष्य फ़ाइल (जैसे। Common.targets) में लक्ष्य को फिर से परिभाषित करना था जो आयात के बाद हर परियोजना में आयात किया जाता है Microsoft.CSharp.targets। निम्नलिखित की तरह देखने के लिए प्रत्येक प्रोजेक्ट फ़ाइल में परिणाम:

   <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
     <PropertyGroup>
       ... snip ...
     </ItemGroup>
     <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
     <Import Project="[relative path to Common.targets]" />
     <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
          Other similar extension points exist, see Microsoft.Common.targets.
     <Target Name="BeforeBuild">
     </Target>
     <Target Name="AfterBuild">
     </Target>
     -->
   </Project>

इसने हमारे निर्माण समय को कुछ घंटों में (ज्यादातर मेमोरी की कमी के कारण), कुछ मिनटों में घटा दिया।

नए सिरे से परिभाषित GetCopyToOutputDirectoryItemsलाइनों 2,438-2,450 और 2,474-2,524 से कॉपी करके बनाया जा सकता है C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targetsमें Common.targets।

परिणामी लक्ष्य परिभाषा की पूर्णता के लिए तब बन जाता है:

<!-- This is a modified version of the Microsoft.Common.targets
     version of this target it does not include transitively
     referenced projects. Since this leads to enormous memory
     consumption and is not needed since we use the single
     output directory strategy.
============================================================
                    GetCopyToOutputDirectoryItems

Get all project items that may need to be transferred to the
output directory.
============================================================ -->
<Target
    Name="GetCopyToOutputDirectoryItems"
    Outputs="@(AllItemsFullPathWithTargetPath)"
    DependsOnTargets="AssignTargetPaths;_SplitProjectReferencesByFileExistence">

    <!-- Get items from this project last so that they will be copied last. -->
    <CreateItem
        Include="@(ContentWithTargetPath->'%(FullPath)')"
        Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(ContentWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
            >
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(ContentWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>

    <CreateItem
        Include="@(_EmbeddedResourceWithTargetPath->'%(FullPath)')"
        Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
            >
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(_EmbeddedResourceWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>

    <CreateItem
        Include="@(Compile->'%(FullPath)')"
        Condition="'%(Compile.CopyToOutputDirectory)'=='Always' or '%(Compile.CopyToOutputDirectory)'=='PreserveNewest'">
        <Output TaskParameter="Include" ItemName="_CompileItemsToCopy"/>
    </CreateItem>
    <AssignTargetPath Files="@(_CompileItemsToCopy)" RootFolder="$(MSBuildProjectDirectory)">
        <Output TaskParameter="AssignedFiles" ItemName="_CompileItemsToCopyWithTargetPath" />
    </AssignTargetPath>
    <CreateItem Include="@(_CompileItemsToCopyWithTargetPath)">
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(_CompileItemsToCopyWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(_CompileItemsToCopyWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>

    <CreateItem
        Include="@(_NoneWithTargetPath->'%(FullPath)')"
        Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_NoneWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"
            >
        <Output TaskParameter="Include" ItemName="AllItemsFullPathWithTargetPath"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectoryAlways"
                Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='Always'"/>
        <Output TaskParameter="Include" ItemName="_SourceItemsToCopyToOutputDirectory"
                Condition="'%(_NoneWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'"/>
    </CreateItem>
</Target>

इस समाधान के साथ, मैंने इसे हल करने के लिए> 120 परियोजनाओं के रूप में ज्यादा काम करने योग्य पाया, इसका मुख्य लाभ यह है कि परियोजनाओं का निर्माण क्रम अभी भी वीएस द्वारा निर्धारित किया जा सकता है बजाय इसके कि आपके समाधान को विभाजित करके ।

Comments

क्या आप अपने द्वारा किए गए परिवर्तनों का वर्णन कर सकते हैं और क्यों? मेरी आंखें भी खुद को उल्टा करने की कोशिश करने के लिए कोडिंग के एक लंबे दिन के बाद थक गई हैं :)

— चार्ली फूल

कैसे इसे फिर से कॉपी और पेस्ट करने की कोशिश की जा रही है - एसओ ने 99% टैग की तरह गड़बड़ कर दी।

— ZXX

@ शार्ली फूल, @ जेडएक्सएक्स ने पाठ को संपादित किया एक विवरण होने के लिए एक्सएमएल को अच्छी तरह से लेआउट करने के लिए नहीं मिला।

— बास बॉसिंक

Microsoft.Common.targets से: GetCopyToOutputDirectoryItems सभी प्रोजेक्ट आइटम प्राप्त करें जिन्हें आउटपुट निर्देशिका में स्थानांतरित करने की आवश्यकता हो सकती है। इसमें पारगमन से संदर्भित परियोजनाओं के सामान शामिल हैं। ऐसा प्रतीत होता है कि यह लक्ष्य सभी संदर्भित परियोजनाओं के लिए सामग्री वस्तुओं के पूर्ण सकर्मक समापन की गणना करता है; हालांकि, यह मामला नहीं है।

— ब्रान्स डीएस

यह केवल अपने तात्कालिक बच्चों से सामग्री सामग्री एकत्र करता है न कि बच्चों के बच्चों से। ऐसा होने का कारण यह है कि ProjectReferenceWithConfiguration लिस्ट जो कि _SplitProjectReferencesByFileExistence द्वारा खपत होती है, केवल वर्तमान प्रोजेक्ट में पॉपुलेटेड है और बच्चों में खाली है। खाली सूची के कारण _MSBuildProjectReferenceExistent खाली होता है और पुनरावृत्ति को समाप्त करता है। इसलिए यह उपयोगी नहीं है।

— Brans Ds

Answer 2

मैं आपको उस विषय पर पैट्रिक स्मैकिया के लेख पढ़ने का सुझाव दूंगा:

• .NET असेंबली और विजुअल स्टूडियो प्रोजेक्ट्स के माध्यम से अपने कोड बेस का विभाजन -> क्या प्रत्येक विजुअल स्टूडियो प्रोजेक्ट वास्तव में अपनी विधानसभा में होना चाहिए? और 'कॉपी लोकल = ट्रू' का वास्तव में क्या मतलब है?
• सबक NUnit कोड आधार से सीखा -> VisualStudio परियोजना संदर्भ + कॉपी स्थानीय सही विकल्प बुराई है! )
• क्रूज़कंट्रोल.नेट के कोड आधार का विश्लेषण -> ट्रू के लिए सेट स्थानीय संदर्भ असेंबली कॉपी का बुरा उपयोग)

CC.Net VS प्रोजेक्ट्स सही पर सेट स्थानीय संदर्भ असेंबली विकल्प पर भरोसा करते हैं। [...] यह न केवल संकलन समय (NUnit के मामले में x3) में वृद्धि करता है, बल्कि यह आपके काम के माहौल को भी गड़बड़ करता है। अंतिम लेकिन कम से कम, ऐसा करने से संभावित समस्याओं के संस्करण के लिए जोखिम का परिचय होता है। अगर यह एक ही नाम के साथ 2 अलग-अलग निर्देशिकाओं में 2 विधानसभाओं को मिला, लेकिन एक ही सामग्री या संस्करण नहीं मिला, तो Btw, ND निर्भरता एक चेतावनी का उत्सर्जन करेगी।

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

आप अपनी परियोजनाओं की संख्या कम करने और अपने संकलन समय को बेहतर बनाने में मदद करने के लिए इस लेख को भी पढ़ सकते हैं ।

Comments

काश मैं एक से अधिक उत्थान के साथ स्मैकिया की प्रथाओं की सिफारिश कर सकता! परियोजनाओं की संख्या कम करना महत्वपूर्ण है, समाधान को विभाजित नहीं करना।

— एंथनी मस्तरीन

Answer 3

मेरा सुझाव है कि निर्भरता के पेड़ के शीर्ष पर लगभग सभी परियोजनाओं के लिए प्रतिलिपि स्थानीय = झूठी है। और शीर्ष सेट में सभी संदर्भों के लिए स्थानीय = सच की प्रतिलिपि बनाएँ। मैं कई लोगों को आउटपुट निर्देशिका साझा करने का सुझाव देता हूं; मुझे लगता है कि यह अनुभव पर आधारित एक भयानक विचार है। यदि आपकी स्टार्टअप परियोजना एक dll के संदर्भ में रखती है, जो किसी भी अन्य परियोजना के लिए एक संदर्भ रखती है, तो कुछ बिंदु पर एक एक्सेस \ साझा उल्लंघन का अनुभव होगा, भले ही सब कुछ पर स्थानीय = झूठी कॉपी करें और आपका निर्माण विफल हो जाए। यह मुद्दा बहुत कष्टप्रद है और नीचे ट्रैक करने के लिए कठिन है। मैं पूरी तरह से एक शार्प आउटपुट निर्देशिका से दूर रहने का सुझाव देता हूं और निर्भरता श्रृंखला के शीर्ष पर प्रोजेक्ट होने के बजाय संबंधित असेंबली को संबंधित फ़ोल्डर में लिखता हूं। यदि आपके पास "शीर्ष" पर कोई परियोजना नहीं है, तो फिर मैं सही जगह पर सब कुछ पाने के लिए पोस्ट-बिल्ड कॉपी का सुझाव दूंगा। इसके अलावा, मैं डिबगिंग की आसानी को ध्यान में रखने की कोशिश करूंगा। किसी भी exe परियोजनाओं मैं अभी भी कॉपी स्थानीय = सच छोड़ देता हूं तो F5 डिबगिंग अनुभव काम करेगा।

Comments

मेरे पास यही विचार था और किसी और को खोजने की उम्मीद कर रहा था जिसने यहां भी ऐसा ही सोचा हो; हालाँकि, मुझे उत्सुकता है कि इस पोस्ट में अधिक बदलाव क्यों नहीं हैं। जो लोग असहमत हैं: आप असहमत क्यों हैं?

— bwerks

जब तक कि एक ही परियोजना दो बार नहीं बन रही है, तब तक ऐसा नहीं हो सकता है, अगर यह एक बार बनाया गया और अपनी फ़ाइलों को कॉपी नहीं करता है, तो इसे अधिलेखित \ अभिगमन उल्लंघन क्यों मिलेगा?

— १

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

— मार्टिन बा

Answer 4

तुम सही हो। CopyLocal बिल्कुल आपके निर्माण समय को मार देगा। यदि आपके पास एक बड़ा स्रोत वृक्ष है तो आपको CopyLocal को निष्क्रिय करना चाहिए। दुर्भाग्य से यह उतना आसान नहीं है जितना कि इसे सफाई से निष्क्रिय करना होना चाहिए। मैंने MSBUILD से .NET में संदर्भों के लिए CopyLocal (निजी) सेटिंग को ओवरराइड करने पर CopyLocal को अक्षम करने के बारे में इस सटीक प्रश्न का उत्तर दिया है । इसकी जांच - पड़ताल करें। साथ ही विजुअल स्टूडियो (2008) में बड़े समाधान के लिए सर्वश्रेष्ठ अभ्यास।

यहाँ जैसा कि मैं इसे देख रहा हूँ CopyLocal पर कुछ और जानकारी है।

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

मैंने लेख में बड़े स्रोत के पेड़ से निपटने के तरीके के बारे में लिखा है MSBuild: विश्वसनीय निर्माण के लिए सर्वोत्तम अभ्यास, भाग 2 ।

Answer 5

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

Comments

ब्रूनो, कृपया मेरे फॉलोअप प्रश्न को ऊपर देखें - यदि हम छोटी .sln फ़ाइलों में विघटित होते हैं, तो आप डिबग बनाम रिलीज़ पहलू को कैसे प्रबंधित करते हैं जो तब मेरे संदर्भों के संकेत पथ में बेक किया जाता है?

— डेव मूर

मैं इस बिंदु से सहमत हूं, मैं जिस समाधान के साथ काम कर रहा हूं, उसमें ~ 100 परियोजनाएं हैं, जिनमें से केवल एक मुट्ठी में 3 से अधिक कक्षाएं हैं, बिल्ड बार चौंकाने वाले हैं, और परिणामस्वरूप मेरे पूर्ववर्तियों ने समाधान को 3 में विभाजित किया है जो पूरी तरह से टूट जाता है 'खोजें सभी संदर्भ 'और refactoring। पूरी बात मुट्ठी भर परियोजनाओं में फिट हो सकती है जो सेकंडों में बन जाएगी!

— जॉन एम

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

— ज्ञानदेव

Answer 6

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

/ P: CreateHardLinksForAdditionalFilesIfPossible = true CreateHardLinksForCopyAdditionalFilesIfPossible = true CreateHardLinksForCopyFilesToOutputDirectoryIfPossible सच =; CreateHardLinksForCopyLocalIfPossible = true CreateHardLinksForPublishFilesIfPossible = true

आप इसे केंद्रीय आयात फ़ाइल में भी जोड़ सकते हैं ताकि आपकी सभी परियोजनाओं को भी यह लाभ मिल सके।

Answer 7

यदि आपको प्रोजेक्ट रेफरेंस के माध्यम से या समाधान स्तर निर्भरता के माध्यम से निर्भरता संरचना मिली है, तो "कॉपी लोकल" को चालू करना सुरक्षित है। मैं तो यह भी कहूंगा कि यह एक सर्वोत्तम अभ्यास है, जिससे आप अपने बिल्ड को समानांतर में चलाने के लिए MSBuild 3.5 का उपयोग कर सकेंगे। रेफरेंस असेंबली को कॉपी करने की कोशिश के दौरान एक-दूसरे पर ट्रिपिंग करने वाली डिफरेंट प्रॉसेस के बिना / मैक्सकूपाउंट के जरिए)।

Answer 8

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

यदि आपके पास समाधान में कुछ परियोजनाएं हैं, तो निर्माण प्रक्रिया बहुत तेज है।

आप दृश्य स्टूडियो मैक्रो का उपयोग करके या "मेनू -> उपकरण -> बाहरी उपकरण ..." के साथ "कॉपी असेंबली टू मैट्रिक्स निर्देशिका" चरण को स्वचालित कर सकते हैं।

Answer 9

आपको CopyLocal मान बदलने की आवश्यकता नहीं है। आपको बस इतना करना है कि समाधान में सभी परियोजनाओं के लिए एक सामान्य $ (आउटपुटपैथ) को पूर्वनिर्धारित करें और $ को सही रखें (UseCommonOutputDirectory)। इसे देखें: http://blogs.msdn.com/b/kirillosenkov/archive/2015/04/04/use-a-common-intermediate-and-output-directory-for-your-solution.aspx

Comments

मुझे यकीन नहीं है कि यह 2009 में वापस उपलब्ध था, लेकिन यह 2015 में अच्छी तरह से काम करता है। धन्यवाद!

— डेव मूर

Answer 10

CopyLocal सेट करें = गलत निर्माण समय कम करेगा, लेकिन परिनियोजन के दौरान विभिन्न समस्याओं का कारण बन सकता है।

ऐसे कई परिदृश्य हैं, जब आपको कॉपी लोकल 'ट्रू' को छोड़ना होगा, जैसे

• शीर्ष स्तर की परियोजनाएँ,
• दूसरे स्तर की निर्भरता,
• प्रतिबिंब द्वारा बुलाए गए डीएलएल

SO प्रश्नों में वर्णित संभावित मुद्दे
" जब कॉपी-स्थानीय को सही होना चाहिए और कब नहीं होना चाहिए? ",
" त्रुटि संदेश 'अनुरोध किए गए प्रकारों में से एक या अधिक लोड करने में असमर्थ। अधिक जानकारी के लिए लोडर-अपवाद संपत्ति को पुनः प्राप्त करें।"  इस प्रश्न के लिए "
और   aaron-stainback का उत्तर ।

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

मुद्दों को हल करने का समय copyLocal = false की स्थापना के लाभों को अधिक वजन देता है।

Comments

सेटिंग CopyLocal=Falseनिश्चित रूप से कुछ मुद्दों का कारण बनेगी, लेकिन इसके समाधान भी हैं। इसके अलावा, आपको अपने ब्लॉग के प्रारूपण को ठीक करना चाहिए, यह मुश्किल से पढ़ने योग्य है, और वहां कह रहा है कि "मुझे <यादृच्छिक सलाहकार> से <यादृच्छिक कंपनी> को तैनाती के दौरान संभावित त्रुटियों के बारे में चेतावनी दी गई थी" एक तर्क नहीं है। आपको विकास करने की आवश्यकता है।

— सुजैन डुपरॉन

@ GeorgesDupéron, मुद्दों को हल करने का समय copyLocal = false की स्थापना के लाभों से अधिक है। सलाहकार का संदर्भ एक तर्क नहीं है, लेकिन क्रेडिट है, और मेरा ब्लॉग बताता है कि समस्याएं क्या हैं। आपकी प्रतिक्रिया के लिए धन्यवाद फिर से। स्वरूपण, मैं इसे ठीक कर दूंगा।

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

Answer 11

मैं एक सामान्य निर्देशिका (उदाहरण के लिए .. बिन) का निर्माण करता हूं, इसलिए मैं छोटे परीक्षण समाधान बना सकता हूं।

Answer 12

आप एक फ़ोल्डर का उपयोग करने का प्रयास कर सकते हैं, जहां सभी असेंबली जो प्रोजेक्ट्स के बीच साझा की जाती हैं, की प्रतिलिपि बनाई जाएगी, फिर एक DEVPATH पर्यावरण चर और सेट करें

<developmentMode developerInstallation="true" />

प्रत्येक डेवलपर के कार्य केंद्र पर मशीन में ।config फ़ाइल। केवल एक चीज जो आपको करने की आवश्यकता है वह है अपने फ़ोल्डर में किसी भी नए संस्करण की प्रतिलिपि बनाना जहां DEVPATH चर अंक।

यदि संभव हो तो अपने समाधान को कुछ छोटे समाधानों में विभाजित करें।

Comments

दिलचस्प ... यह डिबग बनाम रिलीज बिल्ड के साथ कैसे काम करेगा?

— डेव मूर

मुझे यकीन नहीं है कि DEVPATH के माध्यम से डिबग / रिलीज़ असेंबलियों को लोड करने के लिए कोई उपयुक्त समाधान मौजूद है या नहीं, इसका इरादा केवल साझा असेंबलियों के लिए उपयोग किया जाना है, मैं इसे नियमित बिल्ड बनाने के लिए नहीं सुझाऊँगा। यह भी जान लें कि इस तकनीक का उपयोग करते समय असेंबली संस्करण और जीएसी ओवरराइड होते हैं।

— अलेक्जेंडार

Answer 13

यह सबसे अच्छा व्यवहार नहीं हो सकता है, लेकिन यह है कि मैं कैसे काम करता हूं।

मैंने देखा कि प्रबंधित C ++ अपने सभी बायनेरिज़ को $ $ (सॉल्यूशनडिर) / 'डीबगऑरेलिज' में डंप करता है। इसलिए मैंने अपने सभी C # प्रोजेक्ट्स को भी वहां डंप कर दिया। मैंने समाधान में परियोजनाओं के सभी संदर्भों के "कॉपी लोकल" को भी बंद कर दिया। मैंने अपने छोटे 10 प्रोजेक्ट समाधान में समय पर सुधार का ध्यान दिया था। यह समाधान C #, प्रबंधित C ++, देशी C ++, C # webservice और इंस्टॉलर परियोजनाओं का मिश्रण है।

शायद कुछ टूट गया है, लेकिन चूंकि यह एकमात्र तरीका है जिससे मैं काम करता हूं, मैं इसे नोटिस नहीं करता हूं।

यह पता लगाना दिलचस्प होगा कि मैं क्या तोड़ रहा हूं।

Answer 14

आमतौर पर, आपको केवल स्थानीय कॉपी करने की आवश्यकता होती है यदि आप अपने प्रोजेक्ट को डीएलएल का उपयोग करके चाहते हैं जो आपके बिन बनाम में है कहीं और (जीएसी, अन्य परियोजनाएं, आदि)

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

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

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

Answer 15

आपके पास dll के डिबग संस्करणों की ओर इशारा करते हुए आपके प्रोजेक्ट संदर्भ हो सकते हैं। अपनी msbuild स्क्रिप्ट पर, आप इसे सेट कर सकते हैं /p:Configuration=Release, इस प्रकार आपके पास आपके एप्लिकेशन और सभी सैटेलाइट असेंबलियों का एक रिलीज़ संस्करण होगा।

Comments

ब्रूनो - हाँ, यह प्रोजेक्ट सन्दर्भ के साथ काम करता है, जो एक कारण है कि हम पहली बार में 100 परियोजना समाधान के साथ घाव कर रहे हैं। यह उन संदर्भों पर काम नहीं करता है जहां मैं पूर्व-निर्मित डिबग रिलीज़ को ब्राउज़ करता हूं - मैं डिबग असेंबली के खिलाफ निर्मित रिलीज़ ऐप के साथ हवा देता हूं, जो एक समस्या है

— डेव मूर

टेक्स्ट संपादक में अपनी प्रोजेक्ट फ़ाइल संपादित करें और अपने HintPath में $ (कॉन्फ़िगरेशन) का उपयोग करें, जैसे <HintPath> .. \ output \ $ (कॉन्फ़िगरेशन) \ test.dll </ HintPath>।

— अल्ट्रावेलोसिटी

Answer 16

यदि आप चाहते हैं कि एक केंद्रीय स्थान का उपयोग करने के लिए एक DLL का संदर्भ दें तो स्थानीय झूठी प्रतिलिपि GAC के बिना विफल हो जाएगी जब तक आप ऐसा नहीं करते।

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

Answer 17

यदि संदर्भ GAC के भीतर सम्‍मिलित नहीं है, तो हमें प्रतिलिपि स्‍थानीय को सही पर सेट करना होगा ताकि एप्लिकेशन काम करेगा, यदि हमें यकीन है कि संदर्भ GAC में पूर्वस्थापित किया जाएगा तो इसे गलत पर सेट किया जा सकता है।

Answer 18

ठीक है, मैं निश्चित रूप से नहीं जानता कि समस्याएं कैसे काम करती हैं, लेकिन मेरे पास एक बिल्ड समाधान के साथ संपर्क था जो खुद को इस तरह से मदद करता था कि सभी बनाई गई फाइलें जहां प्रतीकात्मक लिंक की मदद से रैमडिस्क पर रखी गई थीं ।

• सी: \ समाधान फ़ोल्डर \ बिन -> रैमडिस्क आर: \ समाधान फ़ोल्डर \ बिन \

• c: \ solution folder \ obj -> ramdisk r: \ solution फ़ोल्डर \ obj \

• तुम भी दृश्य स्टूडियो जो अस्थायी निर्देशिका यह निर्माण के लिए उपयोग कर सकते हैं बता सकते हैं।

वास्तव में यह सब ऐसा नहीं था। लेकिन इसने वास्तव में मेरे प्रदर्शन की समझ को प्रभावित किया।
100% प्रोसेसर का उपयोग और सभी आश्रितों के साथ 3 मिनट से कम समय में एक बड़ी परियोजना।