50 votes

Avertissement du compilateur C# 1685

Donc, (apparemment) de façon inattendue, mon projet commence à recevoir l'avertissement de compilation 1685 :

Le type prédéfini System.Runtime.CompilerServices.ExtensionAttribute'. est défini dans plusieurs assemblages dans l'alias global ; en utilisant la définition de 'c : \Program Fichiers \Reference Assemblages \Microsoft\Framework\v3.5\System.Core.dll '

Perplexe, j'ai fait des recherches dans l'article de MSDN pour en trouver la cause. Voici les informations que j'ai trouvées :

Référence Visual C# : Erreurs et Avertissements Avertissement du compilateur (niveau 1) CS1685

Message d'erreur Le type prédéfini System.type name' est défini dans plusieurs assemblages dans l'alias global global ; en utilisant la définition de 'File Nom

Cette erreur se produit lorsqu'un type de système prédéfini prédéfini, tel que System.int32, se trouve se trouve dans deux assemblages. Une façon de le faire peut se produire si vous faites référence à mscorlib à partir de deux endroits différents, par exemple, en essayant d'exécuter le .Net Framework versions 1.0 et 1.1 côte à côte.

Le compilateur utilisera la définition d'un seul des assemblages. Le compilateur compilateur ne recherche que les alias globaux, ne recherche pas les bibliothèques définies /référence. Si vous avez spécifié /nostdlib, le compilateur va chercher pour Object, et dans le futur commencera toutes les recherches de types prédéfinis dans dans le fichier où il a trouvé Object.

Maintenant, je me gratte vraiment la tête.

  1. Je n'utilise pas deux versions différentes versions différentes de .NET Framework (sauf si vous comptez 2.0 et 3.5).

  2. Je ne fais pas référence à des assemblages assemblages qui pourraient me rendre suspectes.

  3. Je ne me souviens pas d'avoir apporté des modifications à mon application qui auraient pu provoquer ce changement.

  4. J'ai vérifié que tous les composants ciblent la version 2.0.50727 de .NET Framework.

Je suis ouvert aux suggestions, ou aux idées sur la façon de corriger cela. Je traite les avertissements comme des erreurs, et ça me rend fou.

Ce qui m'ennuie vraiment, c'est que je ne sais pas por qué c'est en train de se produire. Les choses qui se produisent doivent avoir une cause discernable, et je dois savoir pourquoi elles se produisent. Si je ne peux pas l'expliquer, je ne peux pas y remédier avec précision. Les conjectures ne sont jamais satisfaisantes.

L'application est simple et se compose d'une bibliothèque de classes et d'une application de formulaires Windows.

  • Une bibliothèque de classe C# DLL fournissant une fonctionnalité de base encapsulant l'accès aux bases de données. Cette DLL fait référence aux composants suivants :

    • Système
    • System.Core
    • System.Core.Data
    • System.Data
    • System.Data.DataSetExtensions
    • System.Data.OracleClient
    • System.Drawing
    • System.Windows.Forms
    • System.Xml
    • System.Xml.Linq
  • Une application C# Windows Forms fournissant l'interface utilisateur. Cette application fait référence aux composants suivants :

    • CleanCode
    • CleanCodeControls (les deux offrent un support pour l'éditeur de syntaxe et sont construits localement avec .NET 3.5).
    • LinqBridge
    • Roswell.Framework (la bibliothèque de classes ci-dessus)
    • Système
    • System.Core
    • System.Data
    • System.Data.DataSetExtensions
    • System.Data.OracleClient
    • System.Deployment
    • Système.conception
    • System.Drawing
    • System.Windows.Forms
    • System.Xml
    • System.Xml.Linq

Faites-moi savoir si vous avez besoin de plus d'informations et je me ferai un plaisir de vous les fournir.

Merci d'avance.

104voto

Remco te Wierik Points 423

Un autre moyen facile de vérifier : Dans votre code, utilisez temporairement la classe quelque part. Exemple :

System.Runtime.CompilerServices.ExtensionAttribute x = null;

Lors de la construction, cela générera une erreur :

Le type 'System.Runtime.CompilerServices.ExtensionAttribute' existe à la fois dans 'c : \Program Fichiers \Reference Assemblages \Microsoft\Framework\v3.5\System.Core.dll et .....

Et vous montrer immédiatement les 2 sources causant le conflit.

22voto

JaredPar Points 333733

Marc a presque certainement raison. Voici un moyen de vérifier

  1. Ouvrir Reflector.exe
  2. Ajouter tous les assemblages hors système
  3. F3 et recherchez ExtensionAttribute

S'il apparaît ailleurs que dans System.Core, vous savez d'où il vient.

22voto

Marc Gravell Points 482669

LINQBridge me rend immédiatement méfiant. L'objectif principal est de fournir des attributs/méthodes d'extension, etc. aux utilisateurs de la version 2.0. Si vous avez la version 3.5 (System.Core.dll), n'utilisez pas LINQBridge. Si vous avez faire ont besoin de LINQBridge dans la version 3.5 pour une raison obscure (et je n'en vois pas), alors vous devrez peut-être utiliser un alias externe. Mais je realmente doute que vous en ayez besoin !

9voto

VitalyB Points 2318

Une autre solution pour ce problème est d'utiliser un alias global pour l'ensemble de l'assemblage :

Référence -> Propriétés -> Alias -> Remplacer 'global' par quelque chose d'autre.

5voto

Efrain Points 1014

Pour info : j'ai eu le même problème et j'ai pu le résoudre en utilisant la commande "Optimiser les références" de Resharper, puis en supprimant toutes les références inutilisées. Pas tout à fait sûr por qué que ça a marché, mais ça a marché.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X