La résolution MSB3247 - conflits entre les différentes versions trouvées du même ensemble dépendant

StackOverflow https://stackoverflow.com/questions/1871073

  •  18-09-2019
  •  | 
  •  

Question

Une solution .NET 3.5 a fini avec cet avertissement lors de la compilation avec msbuild.

Parfois NDepend peut aider, mais dans ce cas, il n'a pas donné plus de détails. Comme Bob J'ai fini par avoir à recourir à l'ouverture de chaque Assemblée ILDASM jusqu'à ce que je trouve celui qui faisait référence à une version plus ancienne de l'assemblée dépendante.

Je l'ai fait essayer d'utiliser MSBUILD de VS 2010 Beta 2 (comme l'article Connect a indiqué cela a été corrigé dans la prochaine version du CLR), mais qui n'a pas fourni plus de détails soit

Y at-il une meilleure approche (plus automatisée)?

Était-ce utile?

La solution

Changer le « projet MSBuild sortie de la construction verbosité » à « détaillée » ou au-dessus. Pour ce faire, procédez comme suit:

  1. afficher la boîte de dialogue Options. ( Outils -> Options ... )
  2. Dans l'arborescence de gauche, sélectionnez Projets et Solutions nœud, puis sélectionnez créer et exécuter .
    • . Remarque: si ce noeud ne se présente pas, assurez-vous que la case à cocher en bas de la boîte de dialogue Afficher tous les paramètres est cochée

  3. Dans les outils / options page qui apparaît, définissez le MSBuild build projet de sortie verbosité niveau pour le réglage approprié en fonction de votre version:

  4. Construire le projet et regarder dans la fenêtre de sortie.

Découvrez les messages MSBuild. La tâche de ResolveAssemblyReferences, ce qui est la tâche à partir de laquelle MSB3247 son origine, devrait vous aider à résoudre ce problème particulier.

Mon cas particulier était une référence incorrecte à SqlServerCe. Voir ci-dessous. J'ai eu deux projets faisant référence à deux versions différentes de SqlServerCe. Je suis allé au projet avec l'ancienne version, supprimé la référence, puis ajouté la référence correcte. 

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.

Vous ne devez pas ouvrir chaque assemblée afin de déterminer les versions des assemblages référencés.

  • Vous pouvez vérifier les propriétés de chaque référence.
  • Ouvrez les propriétés du projet et vérifier les versions de la section Références.
  • Ouvrez les projets avec un éditeur de texte.
  • Utilisez .Net Reflector.

Autres conseils

Mike Hadlow a posté une petite application de console appelée AsmSpy qui répertorie plutôt bien les références de chaque ensemble: 

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

Ceci est beaucoup plus rapide pour aller au fond du MSB3247 d'avertissement, que de dépendre de la sortie MSBuild.

Quelque temps @AMissico réponse ne suffit pas. Dans mon cas, je ne pouvais pas trouver l'erreur dans les fenêtres de sortie alors j'ai décidé de créer un fichier journal et analyser, en procédant comme suit:

  1. Enregistrement du journal de la construction d'un fichier ... https: / /msdn.microsoft.com/en-us/library/ms171470.aspx

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

  2. Trouver le texte: warning MS... ou les informations d'avertissement spécifique: (par exemple la ligne 9293) Found conflicts between different versions... et le détail complet de l'erreur de conflit sera au-dessus de ce message (par exemple la ligne 9277) There was a conflicts between... Trouver le message d'erreur

Visual Studio 2013

Je trouve que (au moins dans Visual Studio 2010), vous devez définir la verbosité de sortie au moins détaillé pour être en mesure de repérer le problème.

Il est peut-être que mon problème était une référence qui était auparavant une référence GAC, mais ce ne fut plus le cas après la réinstallation de ma machine.

Cet avertissement généré par défaut ASP.NET MVC 4 beta voir

  

, une fonte de cet avertissement peut être éliminé en modifiant manuellement le   .csproj pour votre projet.

     

modifier ........: Référence Inclure = "System.Net.Http"

     

lire ......: Référence Inclure = "System.Net.Http, Version = 4.0.0.0"

J'ai eu la même erreur et ne pouvait pas comprendre avec les autres réponses. Je trouve que nous pouvons « Regrouper » paquets NuGet.

  1. Faites un clic droit sur la solution
  2. Cliquez sur Gérer les paquets NuGet
  3. onglet Regrouper et mettre à jour la même version.

Utiliser un lecteur de dépendance

Utilisation dep.exe vous pouvez lister toutes les dépendances imbriquées d'un dossier entier. Combiné avec des outils comme grep unix ou awk, il peut vous aider à résoudre votre problème

assemblées Trouver étant référencées dans plus d'une version 

$ 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

Cette ligne de commande exécute obscure dep.exe puis la sortie des tubes à deux fois awk à

  • mettre le parent et enfant dans une seule colonne (par défaut, chaque ligne contient un parent et un enfant d'exprimer le fait que ce parent dépend de l'enfant)
  • puis faire une sorte de « groupe par » en utilisant un tableau associatif

Comprendre comment cet ensemble a obtenu tiré dans votre bac 

$ 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

Dans cet exemple, l'outil vous montrera que System.Web.Http 5.2.3 vient de votre dépendance à FooLib alors que la version 4.0.0 vient de BarLib.

Ensuite, vous avez le choix entre

  • convaincre les propriétaires des libs à utiliser la même version
  • cesser d'utiliser un les
  • ajouter réoriente obligatoires dans votre fichier de configuration pour utiliser la dernière version

Comment faire pour exécuter ces choses dans Windows

Si vous ne disposez pas d'un shell de type unix, vous aurez besoin de télécharger un avant de pouvoir exécuter awkand grep. Essayez une des options suivantes

J'ai eu ce problème aussi et utilisé les conseils de AMissico découvrir aussi le problème (bien dû régler le niveau de verbosité à détaillé.

Le problème était en fait assez simple mais après avoir trouvé le coupable.

Arrière-plan: Je mis à jour mon projet de VS2008 à VS2010. Dans le cadre VS2008 cible était de 3,5 et quand je l'ai amené dans VS2010 je l'ai passé à 4 (Full). J'ai aussi mis à jour certains composants tiers, y compris des rapports Crystal.

Il est apparu la plupart des références système où pointant à la version 4.0.0.0, mais un couple n'a pas été changé automatiquement (système et System.Web.Services) et cherchaient encore à 2.0.0.0. rapports Crystal fait référence 4.0.0.0 et c'était donc où les conflits se produisaient. Il suffit de mettre le curseur à la première bibliothèque du système dans l'explorateur de solution, le curseur en bas de la liste et la recherche de toutes les références à 2.0.0.0, la suppression et re ajoutée plus récente 4.0.0.0 la version a fait l'affaire.

L'étrange était que la plupart des références ont été correctement mis à jour et s'il n'y avait pas de rapports Crystal, je ne serais probablement jamais remarqué ... avait

J'ai fait une application basée sur l'application Mike Hadlow: AsmSpy.

Mon application est une application WPF avec interface graphique et peut être téléchargé à partir de mon serveur web à domicile: AsmSpyPlus. exe .

Code est disponible à l'adresse: GitHub

Comme mentionné ici , vous devez supprimer les références non utilisées et les avertissements partirez.

Gestionnaire de génération ASP.NET est la construction du site en passant par les dossiers par ordre alphabétique, et pour chaque dossier, il figure sur les dépendances et il construit les dépendances d'abord, puis le dossier sélectionné.

Dans ce cas, le dossier problématique qui est ~ / Controls, est sélectionné pour être construit au début, à partir encore une raison inconnue, il construit quelques-uns des contrôles là-bas comme un ensemble séparé au lieu de l'intérieur du même ensemble que d'autres contrôles (semble être lié au fait que certains contrôles dépendent d'autres contrôles dans le même dossier).

Ensuite, le dossier suivant qui est construit (~ / Fichier-Centre / contrôle) dépend du dossier racine ~ / qui dépend de ~ / contrôles, de sorte que le dossier ~ / Controls est en cours de construction à nouveau cette fois les contrôles qui ont été séparés de leur propre assemblée sont maintenant joints au même ensemble que d'autres contrôles avec l'ensemble séparés encore référencé.

Donc, à cette assemblée point 2 (au moins) ont les mêmes contrôles et la génération échoue.

Bien que nous ne savons toujours pas pourquoi cela est arrivé, nous avons pu contourner le problème en changeant le nom du dossier Contrôles à ZControls, de cette façon, il ne se construit pas avant ~ / Fichier-Centre / contrôle, seulement après et de cette façon il est construit comme il se doit.

Quick Fix:

Faites un clic droit sur la solution -> Gérer les packages NuGet pour solution -> Sous Regrouper vous pouvez voir s'il y a différentes versions du même paquet ont été installés. Désinstallez différentes versions et installer la dernière version.

Parfois, AutoGenerateBindingRedirects ne suffit pas (même avec GenerateBindingRedirectsOutputType ). Recherche de toutes les entrées de There was a conflict et les fixer manuellement un par un peut être fastidieux, j'ai donc écrit un petit morceau de code qui parse la sortie du journal et les pour vous génère (décharges à 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);

Astuce: utilisez MSBuild binaire et structuré Log Viewer et générer uniquement pour les redirections de liaison des conflits dans le projet qui émette l'avertissement (c'est seulement passé ces lignes there was a conflict au fichier texte d'entrée pour le code ci-dessus [AssemblyConflicts.txt]).

Une façon simple sans sans une prise en compte des dépendances (internes):

  1. Ouvrir "Solution Explorer".
  2. Cliquez sur "Afficher tous les fichiers"
  3. Développez "Références"
  4. Vous verrez un (ou plusieurs) référence (s) avec l'icône légèrement différente de celle du reste. En règle générale, il est avec la boîte jaune suggère que vous prenez une note. Il suffit de le supprimer.
  5. Ajoutez la référence en arrière et compiler votre code.
  6. C'est tout.

Dans mon cas, il y avait un problème avec référence MySQL. D'une certaine façon, je pourrais énumérer trois versions de celui-ci dans la liste de toutes les références disponibles. J'ai suivi le processus 1 à 6 ci-dessus et cela a fonctionné pour moi.

Visual Studio pour Mac plus communautaire:

de réponse AMissico il faut changer le niveau de journal, ni ASMSpy ni ASMSpyPlus sont disponibles sous forme d'une solution multi-plateforme, voici une plus courte pour Visual studio pour Mac:

  

https://docs.microsoft.com/en -nous / VisualStudio / mac / compilation et construction

Il est Communauté Visual Studio → Préférences ... → Projets → Construire → Connexion verbosité

Si vous avez ReSharper, supprimez toute référence utilisé sur votre solution.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top