दिलचस्प पोस्ट
क्यों प्रयोक्ता परिभाषित चालन-निर्माता अंतर्निहित प्रति-कन्स्ट्रक्टर को अक्षम करता है? जावास्क्रिप्ट / HTML5 में एक्सेल फाइल को कैसे पार्स करना है कर्ल कमांड लाइन के माध्यम से एक्सएमएल फ़ाइल भेजें / पोस्ट करें क्या एसवीएन त्रुटि 413 अनुरोध इकाई बहुत बड़ा कारण है? सी # 2.0 में हैशसेट का उपयोग करते हुए, 3.5 के साथ संगत ListView में कई उलटी गिनती टाइमर कैसे प्रबंधित करें? TextView या WebView में टेक्स्ट हाइलाइट करें जावा में स्ट्रिंग स्ट्रिंग्स के लिए 64 बिट हैश फंक्शन क्या है? वास्तव में जावास्क्रिप्ट में 'निष्पादन संदर्भ' क्या है? CacheProvider के लिए अपवाद NoClassDefFoundError पायथन में उपयोगकर्ता इनपुट के बाद "नाम: त्रुटि: नाम '' परिभाषित नहीं है ' मैं पाठ से एक UIImage बनाने के लिए NSString आकर्षित कार्यक्षमता का उपयोग कैसे करूं? लिनक्स में एक आवेदन की एक एकल आवृत्ति सुनिश्चित करें IPhone पर फेसबुक ऐप की तरह SplitView किसी भी मुद्रा स्ट्रिंग को दोहरे में परिवर्तित करें

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

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

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

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

जाँच करना:

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

आप में से जो कई। एसएलएन फाइलों में निर्माण को विभाजित करते हैं, आप इस समस्या को कैसे प्रबंधित करते हैं?

वेब के समाधान से एकत्रित समाधान ""प्रतिलिपि स्थानीय" के लिए और परियोजना संदर्भ के लिए सबसे अच्छा अभ्यास क्या है?"

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

  1. हमेशा स्थानीय संपत्ति की प्रतिलिपि को गलत सेट करें और इसे कस्टम एमएसबिल्ड चरण के माध्यम से लागू करें

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

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

     <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 C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets से Common.targets में पंक्तियों 2,438-2,450 और 2,474-2,524 की नकल करके बनाई जा सकती हैं।

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

 <!-- 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 परियोजनाएं हासिल करने के लिए इसे व्यावहारिक रूप से प्राप्त किया, इसका मुख्य लाभ यह है कि परियोजनाओं का निर्माण क्रम अभी भी वी.एस. ।

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

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

सीसी। नेट वीएस परियोजनाएं प्रतिलिपि स्थानीय संदर्भ असेंबली विकल्प को सही पर सेट करती हैं। […] न केवल इस वृद्धि को संकलन समय (एन 3 के मामले में एक्स 3), लेकिन यह आपके काम के माहौल को खराब करता है। अंतिम लेकिन कम से कम, ऐसा करने से संभावित समस्याओं को संस्करण के लिए जोखिम का परिचय दिया जाता है बीटीडब्ल्यू, एनडीएपर्ड एक चेतावनी का उत्सर्जन करता है, अगर 2 नामों में 2 असेंबली को एक ही नाम से मिला, लेकिन एक ही सामग्री या संस्करण नहीं।

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

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

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

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

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

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

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

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

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

/ P: CreateHardLinksForAdditionalFilesIfPossible = true CreateHardLinksForCopyAdditionalFilesIfPossible = true CreateHardLinksForCopyFilesToOutputDirectoryIfPossible = true CreateHardLinksForCopyLocalIfPossible = true CreateHardLinksForPublishFilesIfPossible = true

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

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

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

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

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

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

कई परिदृश्य हैं, जब आपको प्रतिलिपि लोकल की आवश्यकता होती है, तो 'सच को छोड़ दिया जाता है, उदा

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

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

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

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

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

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

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

<developmentMode developerInstallation="true" />

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

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

यह सर्वोत्तम प्रथा नहीं हो सकता है, लेकिन यह है कि मैं कैसे काम करता हूं।

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

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

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

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

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

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

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

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

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

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

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

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

  • c: \ solution folder \ bin -> रैमडिस्क r: \ समाधान फ़ोल्डर \ बिन \
  • c: \ solution folder \ obj -> रैमडिस्क r: \ समाधान फ़ोल्डर \ obj \

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

दरअसल यह सब कुछ नहीं था जो उसने किया। लेकिन यह वास्तव में प्रदर्शन की मेरी समझ को प्रभावित करता है
100% प्रोसेसर का उपयोग और सभी निर्भरता के साथ 3 मिनट के अंतर्गत एक विशाल परियोजना