NuGet और कई समाधान

हम दो समाधान है: foo.sln और bar.slnNuGet और कई समाधान

मैं एक आम पुस्तकालय है कि दोनों foo और बार के द्वारा प्रयोग किया जाता है। Common.csproj दोनों द्वारा उपयोग किया जाता है।

यदि मैं foo खोलता हूं और nuget संदर्भ अद्यतन करता हूं, तो सामान्य.csproj बिंदु foo/packages/में सभी संदर्भ। यदि मैं बाद में बार खोलता हूं और nuget संदर्भ अद्यतन करता हूं, तो सभी संदर्भ बार/पैकेज/में सेट किए जाते हैं। स्वाभाविक रूप से, यह foo टीम को बंद कर देता है क्योंकि यह सामान्य.csproj और Foo-विशिष्ट सामग्री जैसे Foo.Data.csproj के बीच असंगतताओं का कारण बन सकता है, जो अभी भी foo/packages को इंगित करता है।

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

issue on codeplex, (शीर्ष मतदान मुद्दा, आकस्मिक रूप से) लगता है, लेकिन स्पष्ट रूप से मैं यह समझने के लिए बहुत मोटा हूं कि यह समस्या कैसे हल हो जाती है। क्या कोई इसे ठीक करने का तरीका बता सकता है?

स्रोत

2011-09-15 Code Silverback

मुझे आश्चर्य है कि यह अचानक एक मुद्दा बन गया है क्योंकि मैं इसे समस्याओं के बिना महीनों तक कर रहा हूं, कल एक अद्यतन था और अचानक हम दोनों 24 घंटों के भीतर इसमें भाग लेते थे। या शायद यह एक संयोग है। – GraemeF

यह भी देखें कि http://stackoverflow.com/questions/6277925/nu-get-issue-with-project-level-dependences-for-projects-referenced-by-multipl/7908976#7908976। यह वर्णन करता है कि कॉन्फ़िगरेशन को कैसे बदलें, यह निर्दिष्ट करने के लिए कि समाधान इसकी फ़ाइलों को संग्रहीत करेगा। यदि आप एक ही डीआईआर पर सभी समाधानों को इंगित करते हैं, तो संकेत-पथ सही होना चाहिए चाहे आप किस समाधान का उपयोग करें। –

@ReedRector, आपको लिंक को एक उत्तर के रूप में रखना चाहिए, न कि टिप्पणी के रूप में। –

क्यों एक अलग विधानसभा कि आप संदर्भ और उसके में समाधान की तुलना में बल्कि अपनी ही निर्भरता है के रूप में common.csproj नहीं।

कर कि आप संदर्भित पैकेज को अपडेट करने या तो foo या पट्टी से आम की रक्षा करके और इसे तोड़ना

स्रोत

2011-09-16 10:14:35 Nathan

यह समस्या NuGet से अधिक है। यदि आपके पास दो समाधानों में संदर्भित एक प्रोजेक्ट है, और एक समाधान में खुला होने पर प्रोजेक्ट में असेंबली संदर्भों को बदलें, निश्चित रूप से यह उस समाधान के संदर्भ पथ को दूसरे समाधान में खुला होने पर बदल देगा। संदर्भ हमेशा बदल गया था (NuGet या अन्यथा के साथ) इस पर ध्यान दिए बिना यह हमेशा मामला रहा है।

लेकिन असली समस्या यह है कि जब आप कोई अद्यतन करते हैं, तो अद्यतन पैकेज foo/packages निर्देशिका में नहीं दिखते हैं?

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

मुख्य तर्क है कि मैं इस के खिलाफ सुना है कि आप आम कोड जबकि डिबगिंग से निकलने के लिए चाहते हो सकता है है, लेकिन अब यह दृश्य स्टूडियो के साथ एक मुद्दा है 2010

बुनियादी सवाल आप से पूछना करने की जरूरत है क्या सामान्य.csproj का मालिक है? क्या यह फू टीम या बार टीम है?

स्रोत

2011-09-22 11:35:07

यह सबसे अच्छा जवाब है जिसे मैंने समझाया है। अगर मैं इसे दस बार वोट दे सकता हूं तो मैं – ferventcoder

+1 बस इस सटीक स्थिति में भाग गया और संभवतः इस समाधान में चलेगा (थोड़ी देर के लिए procrastinating रहा)। – Sumo

मैंने यह भी पाया कि NuGet 2.1 इस समस्या को हल कर सकता है। http://docs.nuget.org/docs/release-notes/nuget-2.1#Specify_%e2%80%98packages%e2%80%99_Folder_Location – Sumo

हमारे मामले में, टीएफएस के साथ कई डेवलपर और समाधान, और विभिन्न शाखाओं में इसके कई संस्करण ... और प्रत्येक डेवलपर उनकी समझ जहां स्रोत को झूठ बोलना चाहिए।

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

हमारे समाधान में सापेक्ष पथ से छुटकारा पाने में शामिल हैं। यदि आप एक अलग डिस्क पर NuGetPackages डालते हैं तो आप इसे कर सकते हैं। तो जैसे:

net use /persistent:yes p: \\localhost\C$\NuGetPackagesDiskFolder

किसी भी फ़ोल्डर नाम आप अभ्यस्त
उसके बाद, तुम सच में निरपेक्ष पथ NuGet.Config

<config> 
<add key="repositorypath" value="p:\NuGetPackages" /> 
</config> 
<packageRestore> 
<add key="enabled" value="True" /> 
</packageRestore>

में निर्दिष्ट कर सकते हैं हटा दें स्वतः फ़ाइलों

ps के बाद: मौजूदा समाधानों में बदलाव के साथ थोड़ी सी परेशानी होगी, अगर वे स्रोत नियंत्रण में रहते हैं तो सबसे आसान तरीका है। प्रत्येक .csprojमें p: \ NuGetPackages के पथ को सही करना है।अन्यथा सभी रेफरी को पुनर्स्थापित करना और मैन्युअल रूप से स्रोतों में हटाए गए सभी संकुलों को कॉन्फ़िगर करना आवश्यक है।

स्रोत

2014-10-29 04:55:13 aple

मैं प्रोजेक्ट फ़ाइल में $ (SolutionDir) चर रखने के लिए संकेत पथ को बदलकर समस्या को ठीक करता हूं:

Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL"> 
     <HintPath>$(SolutionDir)packages\EntityFramework.6.1.3\lib\net40\EntityFramework.dll</HintPath>

स्रोत

2017-01-27 10:20:26 Rolf

उत्तर

संबंधित मुद्दे