web-dev-qa-db-fra.com

Avertissement “Le type X dans Y.cs est en conflit avec le type X importé dans Z.dll”

Le main.cs de mon projet renvoie l'avertissement suivant:

Avertissement 1 Le type 'Extensions.MessageDetails' dans 'PATH\Extensions.cs' est en conflit avec le type importé 'Extensions.MessageDetails' dans 'chemin\lib.dll'. Utilisation du type défini dans 'path\Extensions.cs'. chemin\main.cs

Quel est le problème avec mon projet? Comment se débarrasser de l'avertissement?

Le code de mon projet a la structure suivante:

Extensions.cs 

namespace Extensions
{

    public class MessageDetails
    {
        public string message { get; set; }
        public string link { get; set; }
        public string picture { get; set; }
        public string name { get; set; }
        public string caption { get; set; }
        public string description { get; set; }
        public string userid { get; set; }
        public string username { get; set; }

        public object actions { get; set; }
        public object privacy { get; set; }
        public object targeting { get; set; }
    }

}

lib.dll 

namespace MyClassLib {

    public class MyClassLibFoo {
        public void foo(MessageDetails parameters) {
            /* .. */
        }
    }

}

main.cs 

using MyClassLib;
using Extensions;

class Program
{
    static void Main(string[] args)
    {
        MessageDetails md = new MessageDetails();
    }
}
c#.nettypesnamespaces
31
The Mask

Il semble que Extensions.cs soit à la fois une partie du projet qui construit lib.dll et votre main.exe

Supprimez-le de l'un des projets pour résoudre ce problème.

23
parapura rajkumar

Dans mon cas, avec Visual Studio 2013, j'ai constaté qu'une de mes bibliothèques de classe avait développé une référence à elle-même. Je pense que cela s’est produit lorsque j’ai ajouté un nouveau projet à ma solution ou qu’il s’agissait d’un bogue, mais dans un cas comme dans l’autre, cela causait exactement ce problème.

Vérifiez vos références de projet pour toutes les références circulaires.

52
James Blake

J'ai eu ce genre de problème où je suis revenu d'une version cible de .NET Framework de 4.5.2 à 4.0. 

Les classes de mon dossier App_Code avaient des méthodes qui appelaient des méthodes dans les autres classes de ce dossier. Lorsque j'ai créé un dossier standard nommé "AppCode" et déplacé mes classes dans celui-ci, le problème ne se posait plus. 

Si je recrée le dossier "App_Code" et que je déplace mes classes dans celui-ci, ce problème sera à nouveau résolu. Je suis convaincu que cela a à voir avec ma version .NET Framework ou que Visual Studio ne gère tout simplement pas bien sa modification après avoir été initialement construit/ciblé vers une autre version.

10
vapcguy

Vous ne pouvez pas avoir deux copies de la classe extensions, même si le code est le même, elles ne sont pas considérées comme le même objet. Votre dll et votre application principale devront tous deux faire référence au même.

Vous pouvez essayer de créer une bibliothèque de classe 'Common Files' et d'y ajouter la classe d'extensions, de cette manière, vous utiliserez toujours la classe appropriée.

4
Eamonn McEvoy

J'ai eu ce problème avec un projet qui est également hébergé sur NuGet. J'ai vérifié toutes les références du projet. Enfin, l'explorateur d'objets a révélé que la DLL d'une ancienne version de mon paquet NuGet était chargée dans Visual Studio à partir du dossier de cache NuGet ("C:\Utilisateurs\{nom d'utilisateur} \. Nuget\packages"). J'ai supprimé le paquet du dossier de cache, il a disparu du navigateur d'objets et tout fonctionnait bien à nouveau.

2
SvenEV

J'ai eu un projet partagé, "Projet A", qui a été inclus à la fois dans "Projet B" et "Projet C".

"Projet A" a été ajouté en tant que projet partagé dans "Projet B" et "Projet C."

Le "projet A" comprenait également une référence traditionnelle au "projet B".

Pour corriger le problème, j'ai supprimé la référence à "Projet B" de "Projet A."

1
NightShovel

J'ai eu le même problème. Juste une solution simple pour cela. 

Vérifiez vos références de projet, il doit y avoir la même référence de projet. enlève ça, ça va marcher. 

0
Rahul Nikam

Si vous avez vraiment besoin que les deux classes soient déclarées ou référencées dans deux dll distinctes, vous pouvez marquer votre classe comme étant internal.

Les types internes ou les membres ne sont accessibles que dans les fichiers du même assemblage, ce qui évitera la collision.

0
Guillermo Hernandez

parfois, j’obtiens cette erreur - c’est un bogue dans mon cas .. Tout ce que je dois faire pour la corriger est de changer la première lettre de mon nom de fichier script en majuscule en minuscule dans le fichier dans Unity Engine dans mon cas) Puis changez le nom/la classe en conséquence dans mon script. Idk pourquoi cela se produit .. juste - et Idk pourquoi ce correctif fonctionne .. mais dans mon cas ça marche toujours. - Sinon, vous avez probablement 2 copies du même script/même nom de classe pour 2 scripts diff. J'espère que cela t'aides.

0
doodlebits