D’où vient l’erreur CS0433 “Type ‘X’ existe-t-elle à la fois dans A.dll et B.dll”?

Lorsque je lance une application Web à partir de Visual Studio 2008 SP1 à l’aide du serveur Web interne (et non IIS), je reçois l’erreur susmentionnée.

L’erreur complète (fichier source Default.aspx.cs ):

Message d’erreur du compilateur: CS0433: Le type ‘WebApplication3.Site1’ existe dans les deux fichiers ‘c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Fichiers ASP.NET temporaires \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2. muczzy9v.dll ‘et’ c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Fichiers ASP.NET temporaires \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL ‘

L’avertissement complet précédent:

Avertissement: CS0436: Le type ‘WebApplication3._Default’ dans ‘c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Fichiers ASP.NET temporaires \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0. cs ‘est en conflit avec le type importé’ WebApplication3._Default ‘dans’ c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Fichiers ASP.NET temporaires \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3 .DLL ‘. En utilisant le type défini dans ‘c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Fichiers ASP.NET temporaires \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs’.

Source des points d’avertissement vers un fichier intermédiaire App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs :

Line 162: Line 163: [System.Runtime.ComstackrServices.ComstackrGlobalScopeAtsortingbute()] Line 164: public class default_aspx : global::WebApplication3._Default, System.Web.IHttpHandler { Line 165: Line 166: private static bool @__initialized; 

et ma question: d’où vient-il?

La webapp (pas le site Web!) A un Default.aspx et un Site1.Master , pas de dépendances. Ils sont presque vides, avec un asp:Label sur la page. Auparavant, cette application Web fonctionnait bien. Lorsque je supprime toute référence dans Default.aspx.cs au maître, tout se passe bien. Le maître a du code seulement.

Il s’agit en fait de l’une des nombreuses applications Web de test d’incendie et d’oubli, alors je m’en fous. Mais je n’avais jamais vu cela auparavant et maintenant je suis curieux de savoir quoi faire, autre que de copier le code dans un nouveau projet (la solution de nettoyage n’aide pas).

Note: J’ai lu cet article et quelques autres, ils ne s’appliquent pas.

    Théorie

    Lorsque ce problème n’est pas causé par un bogue dans l’application (par exemple, le nom de la classe en double):

    Ce problème semble se présenter après une modification du projet de l’application qui entraîne une nouvelle génération (par exemple, modification du code / de la référence / de la ressource). Le problème semble se situer dans la sortie de cette nouvelle version: pour diverses raisons, Visual Studio ne remplace pas tout le contenu des dossiers obj / bin de votre application. Il en résulte qu’au moins une partie du contenu du dossier bin de votre application est obsolète.

    Lorsque ce problème se produit, la suppression du dossier “Fichiers ASP.NET temporaires”, seul, ne résout pas le problème. Il ne peut pas résoudre le problème, car le contenu obsolète du dossier bin de votre application est copié dans le dossier «Temporary ASP.NET Files» la prochaine fois que vous accédez à votre application, entraînant la persistance du problème. La clé est de supprimer tous les fichiers existants et de forcer Visual Studio à reconstruire chaque object. La prochaine fois que vous accéderez à votre application, les nouveaux fichiers bin seront copiés dans le dossier “Temporary ASP.NET Files”.

    Solution

    1. Fermer Visual Studio
    2. Effectuer un iisreset
    3. Supprimer tous les dossiers et fichiers du dossier “Temporary ASP.NET Files” (le chemin d’access est référencé dans le message d’erreur)
    4. Supprimer les dossiers “obj” et “bin” de l’application incriminée
    5. Redémarrez Visual Studio et ouvrez la solution
    6. Effectuer une “solution propre” suivie d’une “solution de reconstruction”

    Explication

    • Etapes 1 et 2: supprimer les verrous de ressources des dossiers / fichiers à supprimer.
    • Etapes 3-4: supprimer tous les anciens fichiers de build
    • Etapes 5-6: créer de nouvelles versions des fichiers de build

    Arrêtez w3svc et supprimez tout depuis c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\

    ajoutée

    • sur Windows 7

      c:\Users\{username}\AppData\Local\Temp\Temporary ASP.NET Files\root\

    • sur les serveurs IIS (64 bits), cela peut également se produire. Chercher:

      C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root

      (remplacez la version 4.0.30319 par la version du framework que vous utilisez si elle est plus récente sur votre serveur)

    Regardez la balise Inherits de toutes vos pages aspx et de vos pages maîtres. Les chances sont qu’il y a deux classes partielles qui ont le même nom. Changer un et recomstackr.

    Voici quelques informations supplémentaires:

    http://blogs.msdn.com/b/carloc/archive/2007/06/12/comstackr-error-message-cs0433-in-asp-net-2-0.aspx

    Cela peut se produire si vous placez des fichiers .cs dans App_Code et modifiez leur action de compilation pour les comstackr dans un projet d’application Web.

    Soit l’action de génération pour les fichiers .cs dans App_Code en tant que contenu ou changer le nom de App_Code en autre chose. J’ai changé de nom car intellisense ne corrigera pas les fichiers .cs marqués comme du contenu.

    Plus d’infos sur http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

    Supprimer les fichiers de classe du dossier App_Code et les placer directement sous le site Web a résolu ce problème pour moi.

    Cela peut également se produire si vous avez dupliqué TagPrefix dans votre fichier ASPX.

    Cela provoquerait cette erreur …

     < %@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %> < %@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc1" %> 

    Vous pouvez résoudre ce problème en changeant simplement le 2ème “uc1” en “uc2”

    Fixé…

     < %@ Register Src="Control1.ascx" TagName="Control1" TagPrefix="uc1" %> < %@ Register Src="Control2.ascx" TagName="Control2" TagPrefix="uc2" %> 

    “Clean Solution” suivi de “Rebuild Solution” semble aussi le réparer.

    Cela peut se produire lorsque le même nom de classe est spécifié dans plusieurs fichiers .aspx.cs , c’est-à-dire lorsque deux pages sont créées avec un nom de fichier différent mais par erreur ont le même nom de classe.

     // file a.aspx public partial class Test1: System.Web.UI.Page // file b.aspx public partial class Test1: System.Web.UI.Page 

    Lors de la création de l’application Web, cela génère un avertissement, mais l’application s’exécute, toutefois, après la publication de l’application, elle ne fonctionne plus et renvoie l’exception mentionnée dans la question du PO.

    S’assurer que deux noms de classes ne se chevauchent pas résout le problème.

    J’ai toujours eu le problème après toutes ces suggestions. Une classe dans App_Code était en cours de compilation sur deux DLL. Quelque chose comme ça (simplifié):

     warning CS0436: The type 'HcmDbGeographyModelBinder' in '\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\App_Code.oqr0kusq.0.cs' conflicts with the imported type 'HcmDbGeographyModelBinder' in '\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\assembly\dl3\ea0aa3ee\6022e6d5_2cc8cf01\HCM.Web.Backoffice.DLL'. 

    Je viens de renommer le dossier “App_Code” en “Code”. Ceci est un projet MVC5, donc il ne devrait pas y avoir de problème avec le service de fichiers .cs à la racine du projet Web.

    Cela m’est arrivé à cause d’une erreur dans mon Web.Config

          

    Sytem.Web.Helpers était pointé sur 1.0.0.0 au lieu de 3.0.0.0 (MVC 3 étant utilisé sur ce projet).

    Parce que IIS n’a pas pu trouver la référence dans le dossier local, il a regardé dans le GAC et a trouvé deux versions différentes. Après l’avoir pointé sur la référence correcte, IIS a trouvé la DLL locale et l’a utilisée au lieu de rechercher le GAC.

    J’ai trouvé une autre raison: différentes versions utilisées pour les icons dans la boîte à outils et des références dans le projet. Après avoir inséré les objects sous une forme quelconque, l’erreur a commencé.

    J’ai fini par changer la façon dont le MasterType est référencé dans le balisage de la page.

    J’ai changé: < %@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> à < %@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

    Voir ici pour plus de détails.

    J’espère que cela aide quelqu’un.

    Pour moi du moins, cela s’est produit lorsque j’ai supprimé une référence à un assemblage et ajouté une référence à une version plus récente, qui portait un nom différent. Dans ce cas, il semble que l’ancien assembly soit resté dans le dossier bin et obj et qu’il n’a pas été supprimé avec l’opération de solution en mode minimal de Visual Studio (peut-être parce qu’il ne fait plus partie du projet). Dans ce cas, il suffisait de supprimer le contenu des dossiers bin et obj du projet où il se trouvait, à partir de Windows Explorer (ou d’un outil de gestion de fichiers). Ensuite, à partir de Visual Studio, nettoyez la solution et reconstruisez.

    Dans notre cas, la raison était une différence dans les versions .dll des sites IIS. Ils sont placés l’un sous l’autre dans IIS, vous permettant d’accéder à l’autre via un sous-domaine. Il hérite du premier fichier web.config, et en combinant cela avec le fichier web.config suivant, il a échoué, avec différentes versions de mvc.dll.

    J’ai eu le même problème. Voici ma solution: Mettez les classes isolées qui requièrent la propriété [Build Action] de App_Code [Build Action] définie sur [Comstack] dans un dossier autre que App_Code comme Application_Code car le dossier App_Code sera compilé en tant qu’assembly distinct ayant la même classe compilée dans 2 assemblys.

    J’ai eu le même problème avec deux contrôles ascx ayant le même nom de classe:

    Control1: < % @ Control Language = "C #" NomClasse = " myClassName ” AutoEventWireup = “true …> Control2: < % @ Control Language =" C # "ClassName =" myClassName “AutoEventWireup =” true …>

    Je l’ai corrigé en renommant simplement le nom de la classe:

    Control1: < % @ Control Language = "C #" NomClasse = " myClassName1 ” AutoEventWireup = “true …> Control2: < % @ Control Language =" C # "ClassName =" myClassName2 “AutoEventWireup =” true …>

    Fermez la solution et rouvrez-la, puis vérifiez les références du projet pour les doubler :

    entrer la description de l'image ici

    Cela peut se produire si vous utilisez NuGet et modifiez l’emplacement de référence des DLL. Pour y remédier, vous devez modifier manuellement le fichier proj en supprimant les entrées, par exemple:

       

    Attention, ces références “

    Une solution rapide et pratique consiste à abuser de l’incroyable intellisense de Visual Studio en référençant temporairement la classe quelque part.

    Exemple:

     System.Runtime.ComstackrServices.ExtensionAtsortingbute x = null; 

    Lorsque vous créez ou déplacez le curseur sur la ligne, vous pouvez afficher l’erreur suivante:

    “System.Runtime.ComstackrServices.ExtensionAtsortingbute” existe à la fois dans “C: \ Program Files \ Reference Assemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll”

    Cela vous indique les deux sources à l’origine du conflit immédiatement.

    System.Core.dll est le fichier .dll que vous souhaitez conserver, alors supprimez l’autre.

    J’ai trouvé le mien assis dans le répertoire bin , mais cela peut être ailleurs dans le projet.

    En fait, cela vaut la peine de le noter, car le répertoire bin ne faisant peut-être pas partie du jeu de modifications TFS, il peut expliquer pourquoi l’archivage de vos modifications ne résout pas le problème pour les autres membres de votre équipe. .

    Je convertis un ancien site Web asp.net (v 1 ou 2) pour qu’il fonctionne sous .net 4.5 en tant qu’application Web.

    Ma solution consistait à déplacer les delegates du gestionnaire d’événements du contrôle utilisateur à l’origine du problème dans un fichier physique distinct:

     //move this line to a new physical file: public delegate void LocationSearchedEventHandler( object sender ); public partial class controls_Drives_LocationAddPanel : UserControl { public event LocationAddedEventHandler LocationAdded; protected virtual void OnLocationAdded(LocationAddEventArg e) { 

    Il y a de multiples raisons à cela. Et la plupart de ceux mentionnés ci-dessus s’appliquent à différents scénarios. Ce que j’ai noté, c’est que l’erreur se produit UNIQUEMENT lorsque l’authentification est définie sur autre chose que «Aucun». Pour mes besoins de test, je vais régler cela et cela fonctionne.

    aller sur web.config

    dans le add batch="false"

    il devrait régler le problème

    Oui, même problème et résolu en modifiant le code hérité de c # et la balise de page dans aspx