एक ही आश्रित विधानसभा के विभिन्न संस्करणों के बीच टकराव पाया गया जिसे हल नहीं किया जा सका


371

जब मैं साफ करता हूं और फिर अपने समाधान का निर्माण करता हूं जिसमें कई परियोजनाएं होती हैं, तो आउटपुट विंडो रिपोर्ट करती है कि बिल्ड सफल रहा। हालाँकि, जब मैं त्रुटि सूची विंडो देखता हूं, तो यह मुझे यह चेतावनी दिखाता है:

एक ही आश्रित विधानसभा के विभिन्न संस्करणों के बीच टकराव पाया गया जिसे हल नहीं किया जा सका। ये संदर्भ विरोध बिल्ड लॉग में सूचीबद्ध होते हैं जब लॉग वर्बोसिटी को विस्तृत करने के लिए सेट किया जाता है। C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVin.txt

जब मैं इस संदेश को डबल-क्लिक करता हूं, तो यह C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets फ़ाइल खोलता है लेकिन मुझे इसमें कुछ भी समझ में नहीं आता है।

मैं वेब के लिए विजुअल स्टूडियो एक्सप्रेस 2013 का उपयोग कर रहा हूं।

मुझे कैसे पता चलेगा कि क्या गलत है और किस डीएलएल के साथ और फिर मैं कैसे चेतावनी को दूर कर सकता हूं?



2
मैंने संदेश में DLL का नाम शामिल करने के लिए MS Connect सुझाव प्रस्तुत किया। connect.microsoft.com/VisualStudio/feedback/details/2619450
माइकल फ्रीजिम

जवाबों:


513

eta: एसओ के अपने @Nick क्रेवर द्वारा इस सामान पर एक हत्यारा लेख है जिसे आपको पढ़ना चाहिए


जबकि अन्य प्रतिक्रियाओं का कहना है, वे इसे स्पष्ट नहीं करते हैं, इसलिए मैं करूंगा ...।

VS2013.2 पर, उद्धृत जानकारी के उत्सर्जन को वास्तव में ट्रिगर करने के लिए, आपको संदेश को पढ़ने की ज़रूरत नहीं है, जो कहता है:

C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): चेतावनी MSB3277: एक ही आश्रित के विभिन्न संस्करणों के बीच टकराव पाया गया जिसे हल नहीं किया जा सका। ये संदर्भ विरोध बिल्ड लॉग में सूचीबद्ध होते हैं जब लॉग वर्बोसिटी को विस्तृत करने के लिए सेट किया जाता है

यह गलत है (या कम से कम यह विज़ुअल स्टूडियो के कुछ संस्करणों के लिए था - यह VS2015 अपडेट 3 या बाद की तारीख तक ठीक लगता है)। इसके बजाय इसे डायग्नोस्टिक ( टूल्स-> ऑप्शंस-> प्रोजेक्ट और सॉल्यूशंस-> बिल्ड एंड रन , सेट MSBuild प्रोजेक्ट बिल्ड आउटपुट वर्बोसिटी ) की ओर मोड़ें , इसके अलावा आप इस तरह के संदेश देखेंगे:

"Newtonsoft.Json, संस्करण = 6.0.0.0, संस्कृति = तटस्थ, PublicKeyToken = 30ad4fe6b2a6aeed" और "Newtonsoft.Json, संस्करण = 6.0.1.17707, संस्कृति = तटस्थ, PublicKeyToken = 30ad4fe6b2a6aeed] के बीच संघर्ष था।

  • "Newtonsoft.Json, संस्करण = 6.0.0.0, संस्कृति = तटस्थ, PublicKeyToken = 30ad4fe6b2a6aeed" को इसलिए चुना गया क्योंकि यह प्राथमिक था और "Newtonsoft.Json, संस्करण = 6.0.5.17707, संस्कृति = तटस्थ, PublicKeyToken = 30ad4fe6b2a6a6eeded।

फिर

  • Ctrl-Alt-O निर्माण विंडो में जाने के लिए
  • ड्रिलडाउन खोजने के लिए " चुना गया था "।

... और हां, [डायग्नोस्टिक] संदेश के विस्तार को देखने वालों के लिए, यह इस अनभिज्ञता के लिए खबर थी कि शहर में एक सम्मेलन है, जिसमें सभी 6.xसंस्करण हैं, आंतरिक रूप से असेंबली संस्करण 6.0.0.0, अर्थात केवल सेमी वीर मेजर घटक असेंबली में जाता है संस्करण :)


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

4
लॉग स्तर विस्तृत वीएस के अंदर काम करने लगता है (इसलिए कोई नैदानिक ​​आवश्यक नहीं)। हालांकि यह पहली बार नहीं होगा कि MSBuild VS के अंदर अलग तरह से व्यवहार करता है ....
जोहानिस रूडोल्फ

105
मेनू टूल्स से लॉग वर्बोसिटी को बदलने के लिए-> विकल्प, फिर प्रोजेक्ट और सॉल्यूशन खोजें-> बिल्ड एंड रन
जेन

3
मेरे मामले में, मेरे तीन संघर्ष थे और उनमें से एक अन्य दो के लिए जिम्मेदार था। मैंने अपने "विस्तृत" बिल्ड लॉग को नोटपैड में कॉपी किया, "संघर्ष" की खोज की, मैंने पहचाने गए संदर्भ के लिए नुगेट पैकेज को अपडेट किया और समस्या हल हो गई।
आइजैक लाइमैन

@robotnik संपादित सुझाव के लिए धन्यवाद [जिसे अन्य लोगों ने अस्वीकार किया था]। मैंने वास्तव में उत्तर के निचले भाग में जानकारी को शामिल किया था, लेकिन उम्मीद है कि उत्तर अब भी उतना ही स्पष्ट है जितना आप चाहते हैं।
रूबेन बार्टलिंक

76

कमांड लाइन से अपने समाधान का निर्माण करने के लिए msbuild Foo.sln /t:Rebuild /v:diag(से C:\Program Files (x86)\MSBuild\12.0\bin) चलाएं और थोड़ा और विवरण प्राप्त करें, फिर .csproj.उस लॉग को ढूंढें जो चेतावनी को देखता है और अन्य प्रोजेक्ट्स के संदर्भों और संदर्भों की जांच करता है जो समान कॉमन असेंबली का उपयोग करते हैं जो संस्करण में भिन्न होते हैं।

संपादित करें: आप सीधे VS2013 में बिल्ड वर्बोसिटी भी सेट कर सकते हैं। पर जाएं Tools> Optionsमेनू तो करने के लिए जाने Projects and Solutionsऔर करने के लिए सेट MSBuild शब्दाडंबर Diagnostic

संपादित करें: जैसा कि मैंने अभी खुद पाया है कुछ स्पष्टीकरण। मेरे मामले में चेतावनी मुझे रेफ़र प्रॉम्प्ट का उपयोग करते हुए एक संदर्भ जोड़ने के रूप में जोड़ने के कारण हुई थी, जो कि डायलॉग डायलॉग के विरोध में थी, जो कि संस्करण 4 और v12 दोनों से चुनने के लिए उपलब्ध होने के बावजूद भी संस्करणहीन था।

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework" />

बनाम

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, ..." />

MSBuild /v:diagवर्बोसिटी के साथ लॉग में यह निम्न की तरह लग रहा था। दो संदर्भों का विवरण देते हुए: -

  There was a conflict between 
  "Microsoft.Build.Framework, Version=4.0.0.0, ..." and 
  "Microsoft.Build.Framework, Version=12.0.0.0, ...". (TaskId:16)

      "Microsoft.Build.Framework, Version=4.0.0.0, ..." was chosen because it was primary and 
      "Microsoft.Build.Framework, Version=12.0.0.0, ..." was not. (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=4.0.0.0, ..." 
      [C:\...\v4.5.1\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v4.5.1\Microsoft.Build.Framework.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v4.5.1\Microsoft.Build.Framework.dll". (TaskId:16)
              Microsoft.Build.Framework (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=12.0.0.0, ..." 
      [C:\...\v12.0\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v12.0\Microsoft.Build.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

          C:\...\v12.0\Microsoft.Build.Engine.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.Engine.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: 
Found conflicts between different versions of the same dependent assembly that could not be resolved.  
These reference conflicts are listed in the build log when log verbosity is set to detailed. 
[C:\Users\Ilya.Kozhevnikov\Dropbox\BuildTree\BuildTree\BuildTree.csproj]

10
मैंने एक लॉग फ़ाइल में उस कमांड को पाइप करना समाप्त कर दिया है, इसलिए मैं इसे आसान देख सकता हूं:msbuild "Foo.sln" /t:Rebuild /v:d > build.log
CrazyPyro

2
इसके लिए टर्मिनल पर जाने का सबसे अच्छा तरीका: stackoverflow.com/a/22702405/268066
CrazyPyro

@CrazyPyro msbuild के पास "पाइप में निर्मित" है - यहां लॉगर्स स्पष्टीकरण के लिए स्विच पर/l:FileLogger,Microsoft.Build.Engine;logfile=build.log ध्यान दें
drzaus

3
"बिल्ड लॉग" कहाँ स्थित है? मुझे यह कैसे मिल सकता है?
कैदी ZERO

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

39

मैं केवल रुबेन के उत्तर को प्रदर्शित किए गए दो संदेशों के बीच तुलना के साथ समर्थन कर सकता हूं:

यहां छवि विवरण दर्ज करें

और संदेश:

C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): चेतावनी MSB3277: एक ही आश्रित के विभिन्न संस्करणों के बीच टकराव पाया गया जिसे हल नहीं किया जा सका। ये संदर्भ विरोध बिल्ड लॉग में सूचीबद्ध होते हैं जब लॉग वर्बोसिटी को विस्तृत पर सेट किया जाता है ।

इसलिए, रुबेन का अधिकार — यह सच नहीं है। कोई भी विवाद नहीं है, बस एक लापता विधानसभा है। यह विशेष रूप से उबाऊ है जब परियोजना एक ASP.NET अनुप्रयोग है, क्योंकि विचारों को मांग पर संकलित किया गया है, अर्थात्, पहली बार प्रदर्शित होने से ठीक पहले। यह तब होता है जब विधानसभा उपलब्ध होना आवश्यक हो जाता है। (बाकी कोड के साथ-साथ विचारों को पूर्व-संकलित करने का एक विकल्प है, लेकिन यह एक और कहानी है ।) दूसरी ओर, यदि आप क्रियात्मकता को निदान के लिए निर्धारित करते हैं तो आपको निम्न आउटपुट मिलते हैं:

C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): MSB3245 चेतावनी: इस संदर्भ को हल नहीं कर सका। असेंबली का पता नहीं लगा सका "System.Web.Razor, संस्करण = 3.0.0.0, संस्कृति = तटस्थ, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL"। यह सुनिश्चित करने के लिए जांचें कि डिस्क पर असेंबली मौजूद है। यदि यह संदर्भ आपके कोड द्वारा आवश्यक है, तो आपको संकलन त्रुटियाँ मिल सकती हैं।

परिणामस्वरूप, आपको बस इतना करना होगा:

  1. असेंबली का संदर्भ मैन्युअल रूप से जोड़ें (डिस्क पर इसे खोजें, शायद GAC, और इसे "प्रत्यक्ष" संदर्भ के रूप में जोड़ें), या
  2. इसे डाउनलोड करने के लिए NuGet पैकेज (यदि गैलरी में प्रकाशित किया गया है) का उपयोग करें और इसके भीतर मौजूद असेंबली का संदर्भ दें।

यहाँ NuGet गैलरी के बारे में अधिक । ASP.NET precompiling के बारे में अधिक जानकारी यहाँ दी गई है


वीएस 2017 में, जब मैंने "MSBuild प्रोजेक्ट बिल्ड वर्बोसिटी" (लॉग फ़ाइल नहीं) को विस्तृत (डायग्नोस्टिक नहीं) के रूप में सेट किया, तो मुझे अपने आउटपुट विंडो में "असेंबली का पता नहीं लगा सका"।
अलेक्सिंटलोस

@ALEXintlsos: जाहिर है कि यह कार्यक्षमता बदल गई है; फिर भी आपको जहाँ भी त्रुटि हुई है - उससे छुटकारा पाने के लिए अनुदेश का पालन करें।
अलेक्जेंडर क्रिस्टोव

22

दृश्य स्टूडियो में बिल्ड वर्बोसिटी को बदलने से सही दिशा में इंगित करने में मदद मिलेगी। VS में वर्बोसिटी बदलने के लिए नीचे दिए गए चरणों का पालन करें

  1. वीएस में टूल्स-> विकल्प मेनू पर जाएं
  2. ओपन प्रोजेक्ट्स एंड सॉल्यूशंस-> बिल्ड एंड रन
  3. MSBuild प्रोजेक्ट का निर्माण आउटपुट वर्बोसिटी का मान बदलें। से किसी एक को चुनें Quiet, Minimal, Normal, DetailedऔरDiagnostic

बिल्ड लॉग में परिवर्तन देखने के लिए वीएस में आउटपुट विंडो ( Ctrl+ Alt+ O) की जांच करें ।


16

और फिर मैं चेतावनी कैसे दूर करूं?

आप शायद इसे ठीक करने के लिए अपने NuGet संकुल को पुनर्स्थापित या अपग्रेड करने जा रहे हैं ।


2
यह, Visual Studio को पुनरारंभ करने के संयोजन के साथ जब उसने किसी पैकेज को ठीक से पुनः स्थापित करने से इनकार कर दिया, तो मेरे लिए समस्या हल हो गई।
ओहद श्नाइडर

22
जांच करने का सबसे सरल तरीका: समाधान पर राइट क्लिक करें -> Manage NuGet packages for solution-> नीचे Consolidateआप देख सकते हैं कि क्या एक ही पैकेज के विभिन्न संस्करण स्थापित थे
elshev

16

@Elshev की टिप्पणियों में से किसी एक को दोहराते हुए समाधान पर क्लिक करें -> समाधान के लिए NuGet संकुल प्रबंधित करें -> समेकन के तहत आप देख सकते हैं कि क्या एक ही पैकेज के विभिन्न संस्करण स्थापित किए गए थे। वहां पैकेज अपडेट करें। संघर्ष त्रुटि हल हो गई है।


1
यह मेरे लिए हल नहीं हुआ। मुझे Newtonsoft.JSON को अनइंस्टॉल करना पड़ा और NuGet के माध्यम से पुनः इंस्टॉल करना पड़ा। यह अन्य पैकेजों पर निर्भरता को अद्यतन करता है।
गेर गॉडफ्रे

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

यह मेरे लिए काम नहीं करता क्योंकि एक पैकेज की स्थापना रद्द करने के लिए यह एक निर्माण का प्रयास करता है जो ऐसा नहीं हो सकता है क्योंकि पैकेजों का संघर्ष है। इसलिए मैं पैकेज को पुनः स्थापित करने में असमर्थ हूं :(
निकोर्नोटो

8

मैं Visual Studio 2017 का उपयोग कर रहा हूं और जब मैंने कुछ Nuget पैकेज अपडेट किए तो इसका सामना किया। मेरे लिए जो काम किया गया था वह मेरी web.configफ़ाइल को खोलने और <runtime><assemblyBinding>नोड खोजने और इसे हटाने के लिए था। web.configप्रोजेक्ट को सहेजें और पुनर्निर्माण करें।

Error Listखिड़की से देखो । आप देखेंगे कि बाध्यकारी संघर्षों के बारे में एक बड़ी लंबी चेतावनी की तरह क्या दिखता है। इसे डबल-क्लिक करें और यह स्वचालित रूप <runtime><assemblyBinding>से सही मैपिंग के साथ ब्लॉक को फिर से बनाएगा ।


6

डॉटनेट सीएलआई मुद्दे 6583 में कहा गया है कि इस मुद्दे को dotnet nuget locals --clear allकमांड से हल किया जाना चाहिए ।


1
इसने मेरे लिए काम नहीं किया; कमांड चलाने के बाद स्थिति समान थी।
ज़िमानो

3

मैं इसे वेब प्रोजेक्ट में नूगट पैकेज के साथ न्यूटनसॉफ्ट जोंसन स्थापित करने के लिए हल कर सकता हूं


3

जाहिर है कि इस समस्या के लिए बहुत सारे अलग-अलग कारण हैं और इस प्रकार बहुत सारे समाधान हैं। मिश्रण में खदान को फेंकने के लिए, हमने असेंबली (System.Net.Http) को अपग्रेड किया, जिसे पहले हमारे वेब प्रोजेक्ट में सीधे NuGet द्वारा प्रबंधित संस्करण में संदर्भित किया गया था। इसने उस परियोजना के भीतर प्रत्यक्ष संदर्भ को हटा दिया, लेकिन हमारी परीक्षण परियोजना में अभी भी प्रत्यक्ष संदर्भ शामिल था। NuGet- प्रबंधित असेंबली का उपयोग करने के लिए दोनों प्रोजेक्ट्स को अपग्रेड करने से समस्या हल हो गई।


2

यदि आपने संकुल में कोई परिवर्तन किया है - एसएलएन को फिर से खोलें। यह मेरे लिए काम किया!


1

मैंने पाया कि कभी-कभी, नौगेट पैकेज स्थापित होंगे (मैं जो अनुमान लगा रहा हूं) .NET कोर आवश्यक घटक या अन्य आइटम हैं जो पहले से स्थापित ढांचे के साथ संघर्ष करते हैं। वहाँ मेरा समाधान परियोजना (.csproj) फ़ाइल को खोलने और उन संदर्भों को हटाने के लिए था। उदाहरण के लिए, System.IO, System.Threading और इस तरह, जब Microsoft.Bcl कुछ हाल ही में स्थापित NuGet पैकेज के माध्यम से शामिल किया गया है। मेरी परियोजनाओं में विशिष्ट संस्करणों के लिए कोई कारण नहीं है, इसलिए मैं संदर्भों को हटा देता हूं और परियोजना का निर्माण करता है। उम्मीद है की वो मदद करदे।

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

मैंने जो टिप्पणी की उसका उदाहरण:

<!-- <Reference Include="System.Runtime, Version=2.6.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> -->
  <!-- <HintPath>$(SolutionDir)packages\Microsoft.Bcl.1.1.9\lib\net40\System.Runtime.dll</HintPath> -->
  <!-- <Private>True</Private> -->
<!-- </Reference> -->


1

मैंने कई प्रतिक्रियाओं की सलाह का पालन किया, यह पता लगाने के लिए कि क्या गलत था, लेकिन कोई भी उत्तर यह नहीं समझाता कि इसे कैसे ठीक किया जाए। मेरा मुद्दा यह था कि एक संदर्भ को दूसरे संदर्भ के एक अलग संस्करण की आवश्यकता थी। इसलिए न्यूटनसॉफ्ट 6 संस्करण में था, लेकिन कुछ अन्य DLL 4.5 चाहते थे। फिर मैंने न्यूटंसॉफ्ट को अन्य सुझावों में से एक के रूप में उन्नत किया और इससे चीजें बदतर हो गईं।

इसलिए मैंने वास्तव में अपने न्यूटनसॉफ्ट इंस्टाल को डाउनग्रेड किया और चेतावनी चली गई (VS 2017):

समाधान एक्सप्लोरर में राइट क्लिक करें और नूगेट पैकेज प्रबंधित करें का चयन करें ... "इंस्टॉल किए गए" टैब के तहत, न्यूटनसॉफ्ट (या जो भी आपका संघर्ष है) ढूंढें, दाईं ओर, "संस्करण" के बगल में एक ड्रॉपडाउन दिखाई देता है जिसे आप पुराने में बदल सकते हैं संस्करणों। मेरे लिए यह स्पष्ट नहीं था कि इस ड्रॉपडाउन को डाउनग्रेड किया जा सके।


1

आप समस्या का पता लगाने में मदद करने के लिए पूर्ण निदान क्रिया के साथ डॉटनेट सीएलआई चला सकते हैं।

dotnet run --verbosity diagnostic >> full_build.log

एक बार निर्माण पूरा होने पर आप त्रुटि के लिए लॉग फ़ाइल (full_build.log) के माध्यम से खोज सकते हैं। उदाहरण के लिए "एक संघर्ष" की खोज करना, आपको समस्या के अधिकार में ले जाना चाहिए।


0

मैंने NuGet Packagaes के प्रबंधन से Microsoft ASP.NET MVC nuget.org की स्थापना रद्द कर दी है और इसे फिर से स्थापित किया है। इसे फिर से स्थापित करते समय रेजर संस्करण से संबंधित सभी संघर्षों को हल किया। कोशिश करो ।


0

मैंने MSBuild वर्बोसिटी को डायग्नोस्टिक में बदल दिया। लेकिन यह नहीं पाया गया कि समस्या कहां थी, इसलिए ऊपर दिए गए उत्तर के अनुसार मेरे पास app.config में यह कोड था:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="XbimXplorer.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

इसलिए मैंने सिर्फ पहला सिस्टम, संस्करण 4.0.0.0 से 12.0.0.0 तक बदल दिया और मेरी परियोजना ने काम किया।


0

अन्य उत्तरों के अनुसार, आउटपुट लॉगिंग स्तर को विस्तृत करने के लिए सेट करें और संघर्षों के लिए वहां खोजें, जो आपको बताएगा कि आगे कहां देखना है।

मेरे मामले में, इसने मुझे संदर्भों के स्रोत की तलाश में कुछ दिशाओं में भेज दिया, लेकिन अंत में यह पता चला कि समस्या मेरी पोर्टेबल क्लास लाइब्रेरी परियोजनाओं में से एक थी, यह गलत संस्करण को लक्षित कर रही थी और इसे अपनी ओर खींच रही थी संदर्भों का संस्करण, इसलिए संघर्ष। एक त्वरित पुन: लक्ष्य और समस्या हल हो गई थी।


0

मैं सिर्फ इस में भाग गया और समस्या को स्थानीय रूप से संदर्भित dlls के लिए एक पैकेज से स्विच करने के बाद। मुद्दा पुराना रनटाइम बाइंडिंग सामान था app.config


0

पैकेज संदर्भ में माइग्रेट करने के बाद मुझे यह चेतावनी मिली थी। डायग्नोस्टिक आउटपुट में ऐसी जानकारी थी कि लाइब्रेरी को उसी लाइब्रेरी द्वारा संदर्भित किया गया था। यह नए पैकेज संदर्भ का एक बग हो सकता है। समाधान AutoGenerateBindingRedirects को सक्षम करने और कस्टम बाइंडिंग पुनर्निर्देशन को हटाने के लिए था।


0

वीएस 2017, एमवीसी परियोजना

मुझे पता नहीं क्यों, लेकिन मेरे लिए, इस मुद्दे का समाधान outएक मॉडल विधि हस्ताक्षर से एक पैरामीटर को हटाने के लिए था जिसे नियंत्रक एक्शन विधि से बुलाया गया था। यह बहुत ही अजीब व्यवहार है लेकिन मेरी समस्या का समाधान यही था।


-2

Update-Packageपैकेज मैनेजर कंसोल के माध्यम से कमांड चलाएं

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

आधिकारिक डॉक्स https://docs.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages पर अधिक जानकारी


14
यह सलाह आपके दिन को बर्बाद कर सकती है यदि आप नवीनतम पैकेज नहीं चाहते हैं जो अक्सर उत्पादन कोड के लिए होता है।
टोनी ओ'हागन

1
यह सलाह में इंगित किया गया है और आपके लिए एक मुद्दा क्या हो सकता है, एक समस्या को ठीक करने का एक सुरक्षित और आसान तरीका है, इसलिए कृपया अपनी राय पर लोगों को निराश न करें।
एनिसिस टारास्केविसियस

1
यह समाधान मेरे काम नहीं आया। मेरे पास पहले से ही सभी नवीनतम संस्करण थे।
जीरो 3

@ Zero3 क्या आपने इसे अपने शीर्ष समाधान से चलाया है, किसी भी पैकेज को सीधे निर्दिष्ट किए बिना, यह आमतौर पर काम करता है, क्योंकि यह हर एक को पुनर्स्थापित करता है और संदर्भों को अद्यतन करता है, जो कि
मिसमैच का

3
यह वास्तव में भयानक सलाह है। यह राय नहीं है, यदि इरादे से नहीं किया गया है तो संकुल को अद्यतन करना कोड को तोड़ता है।
TheBatman
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.