MSB3247 को हल करना - एक ही आश्रित विधानसभा के विभिन्न संस्करणों के बीच संघर्ष मिला


427

एक .NET 3.5 समाधान msbuild के साथ संकलन करते समय इस चेतावनी के साथ समाप्त हुआ।

कभी-कभी ND निर्भरता से मदद मिल सकती है लेकिन इस मामले में इसने कोई और जानकारी नहीं दी। बॉब की तरह मैंने ILDASM में प्रत्येक विधानसभा को खोलने का सहारा लिया, जब तक कि मुझे वह नहीं मिला जो आश्रित विधानसभा के पुराने संस्करण का संदर्भ दे रहा था।

मैंने वीएस 2010 बीटा 2 से MSBUILD का उपयोग करने की कोशिश की (जैसा कि कनेक्ट लेख ने संकेत दिया कि यह सीएलआर के अगले संस्करण में तय किया गया था) लेकिन यह या तो कोई और विवरण प्रदान नहीं करता है (शायद निश्चित पोस्ट बीटा 2)

क्या एक बेहतर (अधिक स्वचालित) दृष्टिकोण है?


2
मेरे मामले में मुझे बस यह सुनिश्चित करना था कि समाधान के सभी प्रोजेक्ट्स नगेट पैकेजों का एक ही संस्करण चला रहे थे (केवल सभी नवीनतम को अपडेट कर सकते हैं)।
माइकल

इसके अलावा stackoverflow.com/questions/24772053/…
SteveC

जवाबों:


576

"MSBuild प्रोजेक्ट आउटपुट वर्बोसिटी निर्माण" को "विस्तृत" या इसके बाद के संस्करण में बदलें। यह करने के लिए, इन उपायों का पालन करें:

  1. विकल्प संवाद ( उपकरण -> विकल्प ... ) लाएं ।
  2. बाएं हाथ के पेड़ में, प्रोजेक्ट्स और सॉल्यूशंस नोड चुनें, और फिर बिल्ड एंड रन चुनें
    • नोट: यदि यह नोड दिखाई नहीं देता है, तो सुनिश्चित करें कि संवाद के निचले भाग में स्थित चेकबॉक्स सभी सेटिंग्स को दिखाता है।
  3. दिखाई देने वाले टूल / विकल्प पृष्ठ में, सेट करें MSBuild प्रोजेक्ट को अपने वर्जन के आधार पर उचित सेटिंग के लिए आउटपुट वर्बोसिटी स्तर का निर्माण करें:

  4. प्रोजेक्ट बनाएँ और आउटपुट विंडो में देखें।

MSBuild संदेशों की जाँच करें। ResolveAssemblyReferencesकार्य है, जो काम है जहाँ से MSB3247 का जन्म होता, तो आप इस विशेष मुद्दे को डिबग मदद करनी चाहिए है।

मेरा विशिष्ट मामला SqlServerCe का गलत संदर्भ था। निचे देखो। मेरे पास SqlServerCe के दो अलग-अलग संस्करणों को संदर्भित करने वाली दो परियोजनाएं थीं। मैं पुराने संस्करण के साथ प्रोजेक्ट पर गया, संदर्भ हटा दिया, फिर सही संदर्भ जोड़ा।

Target ResolveAssemblyReferences:
    Consider app.config remapping of assembly "System.Data.SqlServerCe, ..." 
        from Version "3.5.1.0" [H:\...\Debug\System.Data.SqlServerCe.dll] 
        to Version "9.0.242.0" [C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PublicAssemblies\System.Data.SqlServerCe.dll]
        to solve conflict and get rid of warning.
    C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : 
        warning MSB3247: Found conflicts between different versions of the same dependent assembly.

संदर्भित असेंबली के संस्करणों को निर्धारित करने के लिए आपको प्रत्येक असेंबली खोलने की आवश्यकता नहीं है।

  • आप प्रत्येक संदर्भ के गुणों की जांच कर सकते हैं।
  • प्रोजेक्ट गुण खोलें और संदर्भ अनुभाग के संस्करणों की जाँच करें।
  • पाठ संपादक के साथ प्रोजेक्ट खोलें।
  • .Net रिफ्लेक्टर का उपयोग करें।

5
आपके समाधान मुझे अच्छे लगते हैं, हालांकि मुझे नहीं लगता कि संस्करण संख्याओं को देखने के लिए संदर्भ अनुभाग का उपयोग करना हमेशा उपयोगी होता है। मैंने अक्सर वीएस को "झूठ" के बारे में देखा है कि यह किस संस्करण का उपयोग कर रहा है। किस संस्करण में वास्तव में .csproj फ़ाइल का उल्लेख है।
डेविड गार्डिनर

5
@ डेविड गार्डिनर - मैं C # प्रोजेक्ट्स का उपयोग करते समय आपके "झूठ" बयान से सहमत होगा। मेरे अनुभव में, C # प्रोजेक्ट संदर्भित संस्करण और संकलित / लिंक किए गए वास्तविक संस्करण के बारे में भ्रमित हो सकते हैं। जब ऐसा होता है, तो मैं समाधान को साफ करता हूं, मैन्युअल रूप से बिन और obj फ़ोल्डरों को हटा देता हूं, फिर अस्थायी प्रोजेक्ट असेंबली को% APPDATA% में हटा दें। एक पुनर्निर्माण समाधान आमतौर पर समस्या का समाधान करता है। (VB शायद ही कभी इस विशिष्ट समस्या से ग्रस्त है।)
AMissico

54
वास्तव में आउटपुट विंडो का उपयोग करने के लिए लोगों को बताने के लिए जीत। बिल्ड F5 + त्रुटि सूची विंडो से बहुत अधिक है।
JJS

2
जैसा कि ErikHeemskerk ने अपने उत्तर में उल्लेख किया है, Visual Studio 2010 में आपको ResolveAssemblyReferences का आउटपुट देखने के लिए आउटपुट वर्बोसिटी को विस्तृत करने की आवश्यकता होगी।
रॉबिन क्लैर्स

12
संकेत: वर्बोज़ बिल्ड आउटपुट में सटीक स्थान खोजने के लिए, टेक्स्ट को एक टेक्स्ट एडिटर में कॉपी करें, "एक ही आश्रित विधानसभा के विभिन्न संस्करणों के बीच मिला संघर्ष" की खोज करें।
कंटैंगो

133

माइक हैडलो ने एक छोटा सा कंसोल ऐप पोस्ट किया है जिसका नाम असम्पी है जो प्रत्येक विधानसभा के संदर्भों को अच्छी तरह से सूचीबद्ध करता है:

Reference: System.Net.Http.Formatting
        4.0.0.0 by Shared.MessageStack
        4.0.0.0 by System.Web.Http

Reference: System.Net.Http
        2.0.0.0 by Shared.MessageStack
        2.0.0.0 by System.Net.Http.Formatting
        4.0.0.0 by System.Net.Http.WebRequest
        2.0.0.0 by System.Web.Http.Common
        2.0.0.0 by System.Web.Http
        2.0.0.0 by System.Web.Http.WebHost

यह MSB3247 चेतावनी की तह तक जाने का एक बहुत तेज़ तरीका है, MSBuild आउटपुट पर निर्भर रहने की तुलना में।


1
AsmSpy भयानक है, आपको बस याद रखने की ज़रूरत है कि आप बेमेल संस्करणों के साथ तृतीय पक्ष DLL के संदर्भों की तलाश कर रहे हैं। आम तौर पर, मानक पुस्तकालयों के संदर्भ में बेमेल संस्करण इन चेतावनियों का कारण नहीं बनेंगे (और आप उन्हें देखेंगे)।
टॉड थॉमसन

यह एक महान छोटा उपकरण है जिसने मुझे अपनी समस्या को तुरंत हल करने में मदद की। मेरे मामले में, हालांकि, यह वास्तव में थर्ड पार्टी DLL नहीं था, बल्कि System.Management.Automation.dll के संदर्भ में था, जिसमें mscorlib.dll के अलग-अलग संदर्भ थे।
क्रिस गिलम

उपकरण अच्छा है, हालांकि, यह सभी परिस्थितियों में काम नहीं करता है। कम से कम एक .NET 4.5 परियोजना के लिए यह मेरे लिए टकराने वाले संदर्भ संस्करणों को नहीं दिखाता था। + msbuild आउटपुट पथ और सभी के साथ प्रश्न में DLL का नाम देता है।
ट्वोम

11
इस तरह के शब्दों के लिए धन्यवाद लोग :)
माइक हैडलो

आपने मुझे कुछ घंटे काम करने के लिए बचा लिया! इसने विस्तृत आउटपुट के माध्यम से पढ़ने में मदद की, लेकिन एक बार जब मैंने किया तो आपके टूल के साथ फिर से सत्यापन करना आसान था।
नॉर्मन एच।

22

शायद ही कभी @AMissico जवाब पर्याप्त नहीं है। मेरे मामले में, मुझे आउटपुट विंडो में त्रुटि नहीं मिली, इसलिए मैंने निम्न चरणों का पालन करके एक लॉग फ़ाइल बनाने और उसका विश्लेषण करने का निर्णय लिया:

  1. फ़ाइल में बिल्ड लॉग सहेज रहा है ... https://msdn.microsoft.com/en-us/library/ms171470.aspx

    msbuild MyProject.proj /fl /flp:logfile=MyProjectOutput.log;verbosity=detailed

  2. पाठ ढूंढें: warning MS...या विशिष्ट चेतावनी की जानकारी: (उदाहरण के लिए लाइन 9293) Found conflicts between different versions...और संघर्ष की त्रुटि का पूरा विवरण इस संदेश के ऊपर होगा (उदाहरण पंक्ति 9277)There was a conflicts between... त्रुटि संदेश प्राप्त करें

विजुअल स्टूडियो 2013


आउटपुट में 3277 की खोज करने के लिए महान संकेत।
सूफूका

21

मैंने पाया है कि (कम से कम विजुअल स्टूडियो 2010 में) आपको समस्या का पता लगाने में सक्षम होने के लिए आउटपुट वर्बोसिटी को कम से कम विस्तृत करने की आवश्यकता है।

यह हो सकता है कि मेरी समस्या एक संदर्भ थी जो पहले GAC संदर्भ थी, लेकिन मेरी मशीन के पुनः स्थापित होने के बाद ऐसा नहीं था।


1
टूल्स-> विकल्प-> प्रोजेक्ट्स और सॉल्यूशंस-> आउटपुट वर्बोसिटी सेट करने के लिए बिल्ड और रन पर जाएं।
Farshid

8

मेरे पास एक ही त्रुटि थी और अन्य उत्तरों के साथ इसका पता नहीं लगा सका। मैंने पाया कि हम NuGet संकुल को "समेकित" कर सकते हैं।

  1. समाधान पर राइट क्लिक करें
  2. Nuget पैकेज प्रबंधित करें पर क्लिक करें
  3. टैब को समेकित करें और उसी संस्करण में अपडेट करें।

7

डिफ़ॉल्ट ASP.NET MVC 4 बीटा के लिए उत्पन्न यह चेतावनी यहाँ देखें

किसी भी कास्ट में इस चेतावनी को अपने प्रोजेक्ट के लिए .csproj फ़ाइल को मैन्युअल रूप से संपादित करके समाप्त किया जा सकता है।

संशोधित करें ........: संदर्भ शामिल करें = "System.Net.Http"

पढ़ने के लिए ......: संदर्भ शामिल करें = "System.Net.Http, संस्करण = 4.0.0.0"


1
मैंने इसका अनुसरण किया और त्रुटि गायब हो गई। फिर भी पता नहीं कैसे या क्यों, मैंने VS2010 के साथ MVC 4 परियोजना शुरू की, फिर VS2012 पर विस्थापित हो गया। हालांकि, संस्करण की विशेषता को जोड़कर, त्रुटि को गायब कर दिया। धन्यवाद
मैम

6

एक निर्भरता पाठक का उपयोग करें

Dep.exe का उपयोग करके आप संपूर्ण फ़ोल्डर की सभी नेस्टेड निर्भरता को सूचीबद्ध कर सकते हैं। ग्रीक्स या awk जैसे यूनिक्स उपकरणों के साथ संयुक्त, यह आपकी समस्या को हल करने में आपकी मदद कर सकता है

एक से अधिक संस्करणों में संदर्भित असेंबलियों का पता लगाना

$ dep | awk '{ print $1 " " $2; print $4 " " $5 }' | awk '{ if (length(versions[$1]) == 0) versions[$1] = $2; if (versions[$1] != $2) errors[$1] = $1; }  END{ for(e in errors) print e } ' 
System.Web.Http            

यह अस्पष्ट कमांड लाइन dep.exe चलाता है, फिर आउटपुट को दो बार जागने के लिए पाइप करता है

  • माता-पिता और बच्चे को एक कॉलम में रखें (प्रत्येक पंक्ति में एक माता-पिता और एक बच्चा होता है ताकि यह तथ्य व्यक्त किया जा सके कि यह माता-पिता उस बच्चे पर निर्भर है)
  • फिर एक सहयोगी सरणी का उपयोग करके एक प्रकार का 'समूह' करें

यह समझ लेना कि कैसे यह सभा तुम्हारे बिन खींची गई

$ dep myproject/bin | grep -i System\.Web\.Http
MyProject-1.0.0.0 >> System.Web.Http.Web-5.2.3.0 2 ( FooLib-1.0.0.0 )
MyProject-1.0.0.0 >> System.Web.Http.Web-4.0.0.0 2 ( BarLib-1.0.0.0 )
FooLib-1.0.0.0 > System.Web.Http.Web-5.2.3.0 1
BarLib-1.0.0.0 > System.Web.Http.Web-4.0.0.0 1 

इस उदाहरण में, टूल आपको दिखाएगा कि System.Web.Http 5.2.3 आपकी निर्भरता से FooLib पर आता है जबकि संस्करण 4.0.0 BarLib से आता है।

फिर आपके बीच चुनाव है

  • एक ही संस्करण का उपयोग करने के लिए libs के मालिकों को आश्वस्त करना
  • एक का उपयोग बंद करो
  • नवीनतम संस्करण का उपयोग करने के लिए अपनी कॉन्फ़िग फ़ाइल में बाध्यकारी रीडायरेक्ट्स जोड़ना

विंडोज में इन चीजों को कैसे चलाएं

यदि आपके पास एक यूनिक्स प्रकार का शेल नहीं है, तो आपको चलाने में सक्षम होने से पहले एक डाउनलोड करना होगा awkऔर grep। निम्न में से कोई एक आज़माएँ


4

मुझे भी यह समस्या थी और एमीसिको की सलाह का इस्तेमाल करने से भी समस्या का पता चलता है (हालाँकि विस्तृत से वर्बोसिटी लेवल सेट करना पड़ता था।

समस्या वास्तव में काफी आगे थी हालांकि अपराधी को खोजने के बाद।

पृष्ठभूमि: मैंने अपने प्रोजेक्ट को VS2008 से VS2010 में अपग्रेड किया। VS2008 में लक्ष्य की रूपरेखा 3.5 थी और जब मैंने इसे VS2010 में लाया तो मैंने इसे 4 (पूर्ण) में बदल दिया। मैंने क्रिस्टल रिपोर्ट सहित कुछ तृतीय पक्ष घटकों को भी अपग्रेड किया।

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

यह अजीब था कि अधिकांश संदर्भों को सही ढंग से अपडेट किया गया था और अगर यह क्रिस्टल रिपोर्ट के लिए नहीं थे, तो मैंने शायद कभी नहीं देखा होगा ...



2

जैसा कि यहां बताया गया है , आपको अप्रयुक्त संदर्भों को हटाने की आवश्यकता है और चेतावनी जाएगी।


1

ASP.NET बिल्ड मैनेजर फ़ोल्डर के माध्यम से वर्णानुक्रम में जाकर वेबसाइट का निर्माण कर रहा है, और प्रत्येक फ़ोल्डर के लिए यह निर्भरता का पता लगाता है और पहले निर्भरता का निर्माण करता है और फिर चयनित फ़ोल्डर का।

इस मामले में समस्याग्रस्त फ़ोल्डर जो ~ / नियंत्रण है, को शुरुआत में बनाया जाना चुना जाता है, फिर भी एक अज्ञात कारण से, यह अन्य नियंत्रणों के समान विधानसभा के अंदर एक अलग विधानसभा के रूप में कुछ नियंत्रण बनाता है (लगता है इस तथ्य से जुड़ा होना चाहिए कि कुछ नियंत्रण उसी फ़ोल्डर में अन्य नियंत्रणों पर निर्भर हैं)।

फिर अगला फ़ोल्डर जो बनाया गया है (~ / File-Center / Control) रूट फ़ोल्डर पर निर्भर है ~ / जो कि ~ / Controls पर निर्भर है, इसलिए फ़ोल्डर ~ / Controls को केवल इस बार फिर से बनाया जा रहा है जो नियंत्रण अलग किए गए थे उनकी अपनी विधानसभा अब उसी विधानसभा में शामिल हो गई है, जिस तरह अलग विधानसभा के साथ अन्य नियंत्रण अभी भी संदर्भित हैं।

तो इस बिंदु पर 2 विधानसभा (कम से कम) में एक ही नियंत्रण है और बिल्ड विफल है।

हालाँकि हम अभी भी नहीं जानते कि ऐसा क्यों हुआ, हम नियंत्रण फ़ोल्डर का नाम बदलकर ZControls में काम करने में सक्षम थे, इस तरह इसे ~ / File-Center / Control से पहले नहीं बनाया गया है, केवल और इसके बाद इसे बनाया गया है जैसा होना चाहिए।


1

जल्दी ठीक:

समाधान पर राइट क्लिक करें -> समाधान के लिए NuGet संकुल प्रबंधित करें -> समेकित के तहत आप देख सकते हैं कि क्या एक ही पैकेज के विभिन्न संस्करण स्थापित थे। विभिन्न संस्करणों की स्थापना रद्द करें और नवीनतम को स्थापित करें।


1

कभी-कभी AutoGenerateBindingRedirectsपर्याप्त नहीं होता (यहां तक ​​कि GenerateBindingRedirectsOutputType)। सभी There was a conflictप्रविष्टियों की खोज करना और उन्हें मैन्युअल रूप से एक-एक करके ठीक करना थकाऊ हो सकता है, इसलिए मैंने एक छोटा सा कोड लिखा जो लॉग आउटपुट को पार्स करता है और आपके लिए उन्हें उत्पन्न करता है (डंप्स टू stdout):

// Paste all "there was a conflict" lines from the msbuild diagnostics log to the file below
const string conflictFile = @"C:\AssemblyConflicts.txt";

var sb = new StringBuilder();
var conflictLines = await File.ReadAllLinesAsync(conflictFile);
foreach (var line in conflictLines.Where(l => !String.IsNullOrWhiteSpace(l)))
{
    Console.WriteLine("Processing line: {0}", line);

    var lineComponents = line.Split('"');
    if (lineComponents.Length < 2) 
        throw new FormatException("Unexpected conflict line component count");

    var assemblySegment = lineComponents[1];
    Console.WriteLine("Processing assembly segment: {0}", assemblySegment);
    var assemblyComponents = assemblySegment
                              .Split(",")
                              .Select(kv => kv.Trim())
                              .Select(kv => kv.Split("=")
                              .Last())
                              .ToArray();

    if (assemblyComponents.Length != 4) 
        throw new FormatException("Unexpected conflict segment component count");

    var assembly = assemblyComponents[0];
    var version = assemblyComponents[1];
    var culture = assemblyComponents[2];
    var publicKeyToken = assemblyComponents[3];

    Console.WriteLine("Generating assebmly redirect for Assembly={0}, Version={1}, Culture={2}, PublicKeyToken={3}", assembly, version, culture, publicKeyToken);
    sb.AppendLine($"<dependentAssembly><assemblyIdentity name=\"{assembly}\" publicKeyToken=\"{publicKeyToken}\" culture=\"{culture}\" /><bindingRedirect oldVersion=\"0.0.0.0-{version}\" newVersion=\"{version}\" /></dependentAssembly>");
}

Console.WriteLine("Generated assembly redirects:");
Console.WriteLine(sb);

युक्ति: MSBuild बाइनरी और स्ट्रक्चर्ड लॉग व्यूअर का उपयोग करें और केवल उस परियोजना के संघर्षों के लिए बाध्यकारी पुनर्निर्देशन उत्पन्न करें जो चेतावनी का उत्सर्जन करता है (अर्थात, there was a conflictऊपर कोड के लिए इनपुट पाठ फ़ाइल के लिए केवल उन पंक्तियों को अतीत में AssemblyConflicts.txt]]]।


0

बिना (आंतरिक) निर्भरता के किसी को ध्यान में रखे बिना सबसे सरल तरीका:

  1. "समाधान एक्सप्लोरर" खोलें।
  2. "सभी फाइलें दिखाएं" पर क्लिक करें
  3. "संदर्भ" का विस्तार करें
  4. आपको बाकी की तुलना में थोड़ा अलग आइकन के साथ एक (या अधिक) संदर्भ दिखाई देगा। आमतौर पर, यह पीले बॉक्स के साथ होता है जो आपको इसका ध्यान रखने का सुझाव देता है। बस इसे हटा दो।
  5. संदर्भ वापस जोड़ें और अपना कोड संकलित करें।
  6. बस इतना ही।

मेरे मामले में, MySQL के संदर्भ में एक समस्या थी। किसी तरह, मैं सभी उपलब्ध संदर्भों की सूची के तहत इसके तीन संस्करणों को सूचीबद्ध कर सकता हूं। मैंने 6 से ऊपर के माध्यम से 1 प्रक्रिया का पालन किया और यह मेरे लिए काम किया।


0

मैक समुदाय के लिए विजुअल स्टूडियो:

जैसा कि एमीसिको के जवाब में लॉग स्तर को बदलने की आवश्यकता होती है, और न तो ASMSpy और न ही ASMSpyPlus एक क्रॉस-प्लेटफॉर्म समाधान के रूप में उपलब्ध हैं, यहां मैक के लिए विजुअल स्टूडियो के लिए एक छोटा अतिरिक्त है:

https://docs.microsoft.com/en-us/visualstudio/mac/compiling-and-building

यह विजुअल स्टूडियो कम्युनिटी → वरीयताएँ ... → प्रोजेक्ट्स → बिल्ड लॉग → वर्बोसिटी है


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