Behebung von MSB3247 - Gefundene Konflikte zwischen verschiedenen Versionen der gleichen abhängigen Assembly

Question

Eine .NET 3.5 Lösung endete mit dieser Warnung beim Kompilieren mit msbuild.

Manchmal kann NDepend helfen, aber in diesem Fall gab es keine weiteren Details. Wie Bob Am Ende musste ich jede Baugruppe in ILDASM öffnen, bis ich diejenige fand, die eine ältere Version der abhängigen Baugruppe referenzierte.

Ich habe versucht, mit MSBUILD von VS 2010 Beta 2 (wie der Connect-Artikel darauf hinweist, dass dies in der nächsten Version der CLR behoben wurde), aber das hat nicht mehr Details entweder (vielleicht nach Beta 2 behoben) bieten

Gibt es einen besseren (automatisierten) Ansatz?

Answer 1

Ich habe einen Antrag gestellt, der auf Antrag von Mike Hadlow: AsmSpy .

Meine Anwendung ist eine WPF-Anwendung mit GUI und kann von meinem Webserver zu Hause heruntergeladen werden: AsmSpyPlus.exe .

Der Code ist verfügbar unter: GitHub

Answer 2

Der ASP.NET-Build-Manager baut die Website auf, indem er die Ordner alphabetisch durchgeht und für jeden Ordner die Abhängigkeiten herausfindet und zuerst die Abhängigkeiten und dann den ausgewählten Ordner aufbaut.

In diesem Fall wird der problematische Ordner ~/Controls ausgewählt, um zu Beginn erstellt zu werden. Aus einem noch unbekannten Grund werden einige der Steuerelemente dort als separate Baugruppe erstellt, anstatt innerhalb der gleichen Baugruppe wie andere Steuerelemente (scheint damit zusammenzuhängen, dass einige Steuerelemente von anderen Steuerelementen im gleichen Ordner abhängig sind).

Dann wird der nächste Ordner, der gebaut wird (~/File-Center/Control) ist abhängig von der Root-Ordner ~/, die abhängig von ~/Controls ist, so dass der Ordner ~/Controls wird wieder nur dieses Mal die Steuerelemente, die getrennt wurden, um ihre eigene Baugruppe sind nun zu der gleichen Baugruppe wie andere Steuerelemente mit der getrennten Baugruppe noch referenziert werden verbunden.

Zu diesem Zeitpunkt haben also (mindestens) 2 Baugruppen die gleichen Steuerelemente und die Erstellung schlägt fehl.

Obwohl wir immer noch nicht wissen, warum dies geschah, konnten wir es umgehen, indem wir den Namen des Ordners Controls in ZControls änderten. Auf diese Weise wird er nicht vor ~/File-Center/Control gebaut, sondern erst danach, und auf diese Weise wird er so gebaut, wie er sollte.

Answer 3

Manchmal AutoGenerateBindingRedirects ist nicht genug (selbst mit GenerateBindingRedirectsOutputType ). Die Suche nach allen There was a conflict Einträge und deren manuelle Korrektur kann mühsam sein, daher habe ich einen kleinen Code geschrieben, der die Log-Ausgabe analysiert und sie für Sie generiert (Dumps nach 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);

Tipp: Verwenden Sie MSBuild Binäre und strukturierte Protokollanzeige und nur für die Konflikte in dem Projekt, das die Warnung auslöst, verbindliche Umleitungen erzeugen (d. h. nur über die there was a conflict Zeilen in die Eingabetextdatei für den obigen Code [ AssemblyConflicts.txt ]).

Answer 4

Ein einfachster Weg ohne eine Berücksichtigung von (internen) Abhängigkeiten:

1. Öffnen Sie den "Solution Explorer".
2. Klicken Sie auf "Alle Dateien anzeigen".
3. Erweitern Sie "Referenzen"
4. Sie werden eine (oder mehrere) Referenz(en) mit einem etwas anderen Symbol als die anderen sehen. In der Regel ist es mit einem gelben Kasten versehen, der Sie auffordert, ihn zu notieren. Entfernen Sie es einfach.
5. Fügen Sie den Verweis wieder ein und kompilieren Sie Ihren Code.
6. Das ist alles.

In meinem Fall gab es ein Problem mit der MySQL-Referenz. Irgendwie konnte ich drei Versionen davon unter der Liste aller verfügbaren Referenzen auflisten. Ich befolgte die obigen Schritte 1 bis 6 und es funktionierte bei mir.

Answer 5

Visual Studio für Mac Community hinzugefügt:

Als AMissicos Antwort eine Änderung des Log-Levels erfordert und weder ASMSpy noch ASMSpyPlus als plattformübergreifende Lösung verfügbar sind, finden Sie hier eine kurze Ergänzung für Visual Studio für Mac:

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

Es ist in Visual Studio-Gemeinschaft Präferenzen... Projekte Build Log Ausführlichkeit