ASP.Net erreur: “Le type ‘foo’ existe dans les deux ”temp1.dll“ et ”temp2.dll" (pt 2)

Solution:

J'avais aussi déplacé ashx et asmx fichiers en même temps comme ça. L'attribut de Classe de la WebService/WebHandler directives ont été mis au mal de l'espace de noms. La morale de l'histoire est de s'assurer que vous affichez le balisage de tous as*x les fichiers que vous modifiez l'espace de noms en cliquant droit dessus et en choisissant "Afficher le Balisage".

Je rencontre le même problème que dans cette question et ce lien, mais aucune des réponses fixe mon problème. (edit: Réglage du web.config lot attribut fonctionne, mais c'est un coverup, pas une solution)

Le problème, je vais avoir, c'est avec un Contrôle Utilisateur que j'ai déplacé dans le répertoire racine d'un sous-répertoire dans le même projet d'Application Web. Ça marchait bien avant que je l'ai déplacé. Quand je l'ai déplacé, il a commencé à me donner le message d'erreur.

C'est dire que le nom de la classe existe dans les deux dll fichiers Temporaires ASP.NET les Fichiers. Bien sûr, quand j'ai ouvert Réflecteur, c'est dans deux dll.

Si je renommer la classe et le fichier ascx, tout fonctionne bien. Pas de usages du nom original existent dans les fichiers de l'ensemble de mon application. Quand j'ai renommer le fichier, j'ai ouvert tous les fichiers dll Temporaire ASP.NET les Fichiers avec Réflecteur, et l'absence de références à l'original du nom de la classe existe.

Où est donc ce fantôme de référence provenant de comment puis-je résoudre ce problème?

Mise à jour: j'ai littéralement grepped chaque fichier dans mon répertoire de travail pour la solution et mon répertoire temp pour l'ancien nom de la classe et supprimé tous les fichiers qu'il contenait. J'ai ensuite renommé en arrière à l'original, brisé nom et que j'ai toujours l'erreur.

Erreur de serveur dans l'Application'/'.
Erreur De Compilation Description: Une
erreur s'est produite lors de la compilation
d'une ressource nécessaire à ce service
demande. Veuillez consulter les informations suivantes
spécifique détails de l'erreur et de modifier votre
le code source de façon appropriée.

Erreur du compilateur ssage: CS0433: Le type
'ASP.dashboard_badusercontrol_ascx'
existe dans les deux 'c:\Docunts et
Settings\moi\Local
Settings\Temp\Temporary ASP.NET
Files\root\3c2b7e1f\2e8a7620\App_Web_badusercontrol.ascx.a57ad085.iljdmp1p.dll'
et 'c:\Docunts and Settings\moi\Local
Settings\Temp\Temporary ASP.NET
Files\root\3c2b7e1f\2e8a7620\App_Web_bhdqaimy.dll'

Source De L'Erreur:

Ligne 1098: Ligne 1099:
[Système.Diagnostics.DebuggerNonUserCodeAttribute()]
Ligne 1100: privé
global::ASP.dashboard_badusercontrol_ascx
@__BuildControlMyBadUserControl() {
Ligne 1101:
global::ASP.dashboard_badusercontrol_ascx
@__ctrl; Ligne 1102:

Fichier Source: c:\Docunts et
Settings\moi\Local
Settings\Temp\Temporary ASP.NET
Files\root\3c2b7e1f\2e8a7620\App_Web_foo.aspx.a57ad085.1nw6dais.0.cs
Ligne: 1100

Edit:
Ok, j'ai donc fait des tests un peu plus sur ce qui fonctionne et ne fonctionne pas.
Disons que le nom de fichier d'origine était "BadUserControl.ascx" dans l'espace de noms "MyNamespace".

J'ai déplacé le fichier dans un répertoire appelé "NewDirectory" et changé en l'espace de noms "MyNamespace.NewDirectory". Il n'y a pas de copies de "BadUserControl.ascx" n'importe où ailleurs sur mon disque dur. J'ai vérifié mon TFS l'histoire pour assurer la SEULE différence est l'ajout de ".NewDirectory" à l'espace de noms dans le balisage et les fichiers code-behind.

À l'intérieur de cet espace de noms sont deux autres contrôles utilisateur nommé "OtherUserControl" et "AnotherUserControl".

Cette situation d'échec:
J'ai 2 Registre des directives:

<%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %> 
<%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>

Ces situations de travail:

  1. Je garde "BadUserControl.ascx" nommé comme l'est.
    J'ai 1 directive de Registre sur une page dans le même espace de noms:

    <%@ Register src="BadUserControl.ascx" tagname="BadUserControl" tagprefix="uc1" %>
  2. - Je changer "BadUserControl.ascx" à "GoodUserControl.ascx"
    J'ai 2 Registre des directives:

    <%@ Register src="GoodUserControl.ascx" tagname="GoodUserControl" tagprefix="uc1" %>
<%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
  3. 2 Registre des directives sans BadUserControl.ascx à tous: 
    <%@ Register src="AnotherUserControl.ascx" tagname="AnotherUserControl" tagprefix="uc1" %>
<%@ Register src="OtherUserControl.ascx" tagname="OtherUserControl" tagprefix="uc2" %>
Tout et tout le débogage suggestions sont les bienvenues dans une tentative de gagner la prime.
Pourriez vous s'il vous plaît inclure l'exact du message d'erreur de compilation que vous obtenez? Il est difficile de dire à partir de votre description si la Dll en jeu sont générés les assemblées ou à GAC/bin assemblées.
Il y a l'erreur d'info pour vous.

OriginalL'auteur Greg | 2010-04-07

  1. 15

    Mise à JOUR: ok, comme vous l'avez constaté, la circulaire de référence était le mal deviner, qu'il y a d'autres situations qui peuvent entraîner un comportement similaire.

    La manière plus générale pour décrire le problème, c'est que le dosage lors de l'exécution de travaux dans un très permissive façon qui peut masquer des problèmes. Fondamentalement, nous essayons de lot tout dans un dossier, mais si nous obtenons une erreur de compilation lors de la compilation de ce lot, nous tombons à chaque compilation des fichiers. Dans de nombreux cas, cela fonctionne bien, mais parfois, cela peut conduire à une page donnée arriver compilé deux fois (similaire à ce que j'ai décrit ci-dessous, mais pour une raison différente).

    D'autre part, aspnet_compiler travaille dans un stricte, où si un traitement par lots échoue, échoue complètement et de ne pas tomber en arrière. C'est pourquoi l'exécution de cet outil est un excellent moyen de localiser les différents types de questions (ou latente) qui est loin d'être évident au moment de l'exécution. Je suppose que nous n'avons pas fait un bon travail d'évangélisation de cet outil pour cela 🙂

    Comme pour pourquoi renommer le fichier fixe, cela peut être causé par elle de changer l'ordre dans lequel les fichiers sont traitées, ce qui est un peu arbitraire. Il se peut que, si vous le renommer en quelque chose d'autre, vous verrez que ça se reproduise.

    Franchement, en regardant en arrière je souhaite que nous avions fait ce dosage comportement strictes lors de l'exécution, pour attraper ces situations antérieures. La raison nous avons choisi le courant de l'automne dos de conception était d'éviter tout défaut chaque fois que possible, mais cela vient avec un prix: quand quelque chose est mal, c'est une douleur pour l'attraper 🙂

    RÉPONSE ORIGINALE À CETTE QUESTION:
    En bref, le problème est que lorsque le dosage est activée (elle l'est par défaut), vous devriez éviter d'avoir un niveau de répertoire des dépendances circulaires. Laissez-moi vous expliquer ce que je veux dire.

    Ici est un exemple. Disons que vous avez:

    • Dans dossier1: page.aspx et uc2.ascx
    • Dans forder2: uc1.ascx

    Et dire que la page.aspx références uc1.ascx (via une directive @register), et que uc1.ascx références uc2.ascx. Au niveau du fichier, c'est parfaitement bien, mais au niveau du répertoire, il y a une dépendance circulaire: dossier1 références quelque chose dans dossier2, qui renvoie à quelque chose dans dossier1.

    Pourquoi c'est un problème a à voir avec la façon dont le traitement par lots: lorsque vous demandez à la page, il tente d'abord de tout compiler dans folder1 ensemble. Mais depuis folder1/page.aspx références dossier2/uc1.ascx, il doit compiler folder2 avant de pouvoir faire dossier1. Mais alors uc1 utilise uc2, le sens qu'il doit d'abord faire folder1! À ce stade, ASP.NET détecte la situation et tente de faire le meilleur de lui par la compilation uc2.asc par lui-même. Tout cela permet à certains scénarios de travail, il peut aussi causer des choses bizarres parce que certains articles en fin de compilées dans les deux assemblées. Ici, uc2.ascx serait à la fois compilé par lui-même et avec les folder1 lot.

    Il est en fait un moyen facile de détecter si votre site a un tel niveau de dossier de dépendances circulaires. À partir d'un VS fenêtre de la console, accédez à la racine de votre site et de les exécuter:

    aspnet_compiler -v foo -p .

    Si vous avez un niveau de dossier de dépendances circulaires, vous obtiendrez des erreurs qui ressemblent à:

    /foo/Sub/UC1.ascx(2): error ASPPARSE: Circular file references are not allowed.

    Le bon moyen pour éviter ce problème est ce que vous savez déjà: désactiver le traitement par lots. Maintenant, vous savez au moins pourquoi cela fonctionne 🙂

    Mais la meilleure chose à faire si vous le pouvez est pour éviter le niveau de dossier de dépendances circulaires. Si vous commencez à penser de chacun des dossiers en tant que "composant" qui produit une assemblée, qui a du sens, et peut aider à rendre les morceaux de votre site plus modulaire.

    Oui, il est aussi juste à appeler cela un ‘bug’ dans le système de compilation, ou au moins une limitation. Mais une fois que vous êtes au courant, c'est assez facile à éviter.

    C'est un grand, instructif réponse. Alors que je n'ai PAS de fichier circulaire de référence, j'ai eu une "erreur ASPPARSE: impossible de créer le type" d'erreur sur les deux complet sans rapport avec fichiers: Un asmx et un ashx. Depuis double-cliquant sur ces fichiers s'ouvre le code-behind par défaut, je n'ai jamais pensé à la vue de la marge sur ces fichiers quand j'ai fait le déplacement. Une fois que j'ai regardé le balisage, il était évident que l'attribut "Class" a souligné le mal de l'espace de noms. La fixation de ces deux fichiers à cause de mon Contrôle à l'Utilisateur de compiler correctement.
    David, je suis encore confus quant à pourquoi tout simplement de renommer le contrôle de l'utilisateur serait la cause de cette erreur de s'en aller, même avec l'espace de noms des problèmes dans les autres fichiers. J'ai supprimé le Temporaire ASP.NET Fichiers et bin/obj répertoires. Pourrait l'ancien état compilé du site ont été stockées quelque part d'autre?
    J'ai ajouté une mise à jour. Mais pour répondre à votre question, l'état compilé n'est pas stocké n'importe où ailleurs. Plus probablement, c'est un effet de l'arbitraire de la commande dans le traitement d'un fichier que j'ai décrit ci-dessus.
    Super réponse! Je vous remercie beaucoup. Cela a été le fléau de mon existence depuis quelques jours.

    OriginalL'auteur David Ebbo

  2. 4

    Propre Temporary ASP.NET Files. Il se pourrait que le contrôle avant de passer a une assemblée et d'après une autre

    Merci pour l'idée. J'ai supprimé tout dans ce répertoire et le problème persiste. 🙁
    As-tu fait un Nettoyage dans le menu générer?
    Essayez de menu est une bonne idée. Mais tout d'abord, je veux dire la suppression de %Temp%\Temporary ASP.NET Files ou quelque chose comme %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

    OriginalL'auteur abatishchev

  3. 3

    Ce genre d'erreur est due à l'espace de nom. Vérifiez le nom d'espace pour tous les fichiers afin de s'assurer qu'il n'y est pas dupliqué d'un nom ou d'utilisation de l'espace d'erreur d'erreur.

    Cela a eu lieu directement après la modification de l'espace de noms. J'ai pensé à cela aussi, mais si tout ce que je fais est de changer le nom du fichier et le nom de la classe et de laisser l'espace de noms intacte, l'erreur disparaît. Je vais de façon optimale.
    La façon la plus simple que vous pouvez faire est de simplement supprimer le nouvel espace de noms et de faire une recherche de l'espace de noms dans votre projet et assurez-vous il n'est pas dupliqué. Et également de vérifier le déclaratif sur votre aspx ou fichier ascx assurez-vous qu'ils se réfèrent à l'espace de noms correct.
    Il a certainement travaillé quand j'ai effacé le nouvel espace de noms. J'ai découvert quelques informations supplémentaires, donc je suis en train de modifier la question.
    si vous mettez n'importe quel chemin d'accès à l'espace de noms dans le code-behind, vous avez probablement besoin d'utiliser exactement le même espace de noms (MyNamespace.newdirectory) dans le registre des directives
    C'est techniquement une réponse correcte. Le problème était caché dans le balisage non apparentés de asmx et ashx les fichiers que j'ai eu aussi déplacé. Depuis double-cliquant sur ces types de fichiers s'ouvre le code-behind être par défaut, je n'ai jamais pensé à vérifier.

    OriginalL'auteur zsong

  4. 2

    J'ai parfois l'obtenir avec ma web usercontrols. Ils se plaignent qu'ils existent deux fois quand j'ai modifier un fichier différent. Je ne sais pas quelle folie qui en est la cause mais je sais que si j'appuie sur espace > enregistrer sur la plainte de contrôle, il force le serveur à recompiler et il fonctionne très bien après.

    Merci pour la bonne idée!J'ai supprimé tout ce qui, dans le Contrôle de l'Utilisateur. Toutes les balises et le code derrière. La seule chose qui reste a l'usage, espace de noms, nom de classe, et de la directive de Contrôle. Il n'a toujours pas. 🙁
    Je n'étais pas suggérer d'en effacer le contenu du contrôle de l'utilisateur, juste pour faire toute modification de la commande (appuyez sur espace, puis de les supprimer à nouveau) et de l'enregistrer. Cela marque le contrôle comme "sale" dans les yeux du compilateur et l'oblige à recompiler le contrôle, la prochaine fois que vous visitez la page.
    Désolé d'être source de confusion. J'ai essayé juste de le modifier, et qui n'a pas fonctionné, alors j'ai effacé tout et il n'a pas de travail.

    OriginalL'auteur rtpHarry

  5. 2

    Est-il plus d'un projet dans le cadre de votre solution?

    Essayez de nettoyer le dossier /bin (manuellement). Il est possible que l'ancien fichier de build persiste encore quelque part, vous empêchant de bâtiment...

    Aussi, jetez un oeil à votre références, peut - être vous êtes à la duplication de la définition de quelque chose que vous l'avez mentionné?

    C'est un tir sauvage - mais peut-être que vous avez que .dll installée dans le GAC?

    Oui, il est plus seulement d'un projet dans ma solution. Je grepped l'ensemble de la solution et je ne peux pas trouver un duplicata de référence. À la fois le contrôle de l'utilisateur et la page qui l'utilise sont dans le même répertoire. Il n'est pas dans le GAC.

    OriginalL'auteur veljkoz

  6. 2

    Je pense que certaines de ces réponses ont été au large de la marque. J'ai vu cela lors de votre code-behind fait référence à une autre version de l'assembly de votre site web.config ne. par exemple:

    (version 1.1.0.0 référencé dans aspx et 1.2.0.0 référencés dans le web.config)

    MyFile.aspx

    <%@ Register TagPrefix="cc1" Namespace="StrongNamed.Namespace" Assembly="StrongNamed, Version=1.1.0.0, Culture=neutral, PublicKeyToken=692fbea5521e1304" %>

    web.config:

    <assemblies>
    <add assembly="StrongNamed, Version=1.2.0.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
...

    J'ai vu des cas où, si les deux versions de l'assemblée sont dans le GAC, ASP.NET vous donnera l'erreur que vous décrivez.

    Merci pour la nouvelle direction. J'ai vérifié et je ne suis pas à l'aide de l'attribut d'Assemblage sur le Registre de la directive n'importe où dans mon code. Je suis également pas l'enregistrement de la commande en question via le web.config.

    OriginalL'auteur Mike Marshall

  7. 1
    • Fermez toutes les instances de visual studio en cours d'exécution.
    • Arrêter IIS (si en cours d'exécution, autrement arrêter que "devserver" chose)
    • Clair ASP.NET Temp dossier (complètement)
    • Clair BIN
    • Commencer IIS (si en cours d'exécution)
    • Démarrer VS
    • Reconstruire solution
    Merci pour la suggestion. J'ai suivi ces étapes et que le problème persiste.
    Avez-vous utilisé la Solution Propre option? (quelque part entre la réinitialisation des services internet) ?
    Nettoyer la Solution n'est toujours pas résolu.

    OriginalL'auteur riffnl

  8. 1

    Avec beaucoup de projets et de dossiers, il est possible parfois d'obtenir les espaces de noms foiré, surtout si vous essayez de forcer les choses en utilisant des déclarations d'espace de noms.

    Pour voir si c'est vraiment un problème, j'irais à travers tous mes fichiers de code - .cs et .le concepteur.cs - et supprimer TOUTES les déclarations d'espace de noms, puis de reconstruire tous les pour voir si cela résout le problème.

    Vous ne mentionnez pas quelle version de Visual Studio et .net vous utilisez, qui pourraient aider les trop - je me souviens de l'affaire à un problème similaire dans VS2005.

    Visual Studio 2008 SP1 de ciblage .NET 3.5 avec le WebDev serveur.
    C'est techniquement une réponse correcte. Le problème était caché dans le balisage non apparentés de asmx et ashx les fichiers que j'ai eu aussi déplacé. Depuis double-cliquant sur ces types de fichiers s'ouvre le code-behind être par défaut, je n'ai jamais pensé à vérifier.
    L'généré, designer.cs des fichiers peut parfois sortir de la synchronisation, et je n'ai jamais trouvé un bon moyen de les forcer à se régénérer correctement.

    OriginalL'auteur chris

  9. 1

    J'ai rencontré ce problème au moins deux fois.

    David Ebon la réponse est sans aucun doute celui qui explique ce qui se passe.

    Dans mon projet, j'ai créé un utilisateur de contrôle que je dynamiquement inséré dans un espace réservé.

    Si le code-behind pour le contrôle serait quelque chose comme:

    public partial class CustomerAppointmentList : System.Web.UI.UserControl
{
}

    Noter que ce contrôle n'est pas dans tout espace de nom que ce soit.

    Dans le code behind de la clientèle.aspx.cs " je charge cette usercontrol dynamiquement:

    {
    var contentControl = (CustomerAppointmentList)LoadControl("../controls/customerappointmentlist.ascx");
}

    Parce que la classe 'CustomerAppointmentList" n'existe pas dans la page aspx, j'ai à y faire référence dans mon custmer.aspx:

    <%@ Reference Control="../controls/customerappointmentlist.ascx" %>

    Lorsque l'asp.net compilateur a pour compiler le client.aspx il viendra à travers le "CustomerAppointmentList' classe et ajouter le type à la bibliothèque pour ce dossier.

    Quelques secondes plus tard le asp.net le compilateur va ajouter le "CustomerAppointmentList' classe à une autre bibliothèque pour le dossier des "contrôles".

    Après l'ajout d'une interface 'ICustomerAppointmentList" dans une bibliothèque externe (projectname.web.dll) et modifiant le code, le problème a disparu.
    Donc:

    1. Supprimer la "Référence" dans votre fichier aspx.
    2. Créer une interface de contrôle de l'utilisateur.
    3. Assurez-vous que le 'CustomerAppointmentList' classe hérite de contrôle de l'utilisateur.
    4. Lors de l'utilisation de LoadControl, exprimées à l'interface que vous venez de créer.

    Mon nouveau code (ascx.cs):

        public partial class CustomerAppointmentList : System.Web.UI.UserControl, ICustomerAppointmentList
{
}

    (aspx.cs) 

    {
var contentControl = (ICustomerAppointmentList)LoadControl("../controls/customerappointmentlist.ascx");  
}

    OriginalL'auteur mathijsuitmegen

  10. 1

    Essayez de supprimer tous les fichiers et dossiers dans le dossier "Temporaire ASP.Net les Fichiers",c'est dans cette voie:

    c:\windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Fichiers

    cela a fonctionné pour moi

    OriginalL'auteur Reza Mortazavi

  11. 0

    Pour moi ce qui s'est passé quand j'ai eu mon PrecompiledWeb/Publier emplacement situé dans le répertoire en cours qui était où le dossier racine du site était trop.

    Mon Site Web a été ensuite voir le dossier de publication dans le cadre du projet lors de la compilation/bâtiment et ensuite de trouver les doublons de cette manière.

    c'est à dire Ne pas mettre la version publiée de votre site dans votre site de code de dossiers.

    OriginalL'auteur David d C e Freitas