Erreur ASP.Net: «Le type« foo »existe à la fois dans« temp1.dll »et« temp2.dll »

Lors de l'exécution d'un projet d'application Web, à des moments apparemment aléatoires, une page peut échouer avec une erreur CS0433: le type existe dans plusieurs DLL. Les DLL sont toutes des DLL générées résidant dans le répertoire «Fichiers ASP.NET temporaires».

Ajoutez l'attribut batch = "false" à l'élément "compilation" du fichier web.config.

Ce problème se produit en raison de la façon dont ASP.NET 2.0 utilise les références d'application et la structure de dossiers de l'application pour compiler l'application. Si la propriété batch de l'élément dans le fichier web.config de l'application est définie sur true, ASP.NET 2.0 compile chaque dossier de l'application dans un assembly distinct.

http://www.sellsbrothers.com/1995

http://support.microsoft.com/kb/919284

Cela peut se produire si vous placez des fichiers .cs dans App_Code et que vous modifiez leur action de génération pour compiler dans un projet d'application Web.

Soit vous avez l'action de génération pour les fichiers .cs dans App_Code en tant que contenu, soit changez le nom de App_Code en autre chose. J'ai changé le nom car intellisense ne corrigera pas les fichiers .cs marqués comme contenu.

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

Une raison possible de cette erreur est qu'il y a 2 pages aspx qui ont le même nom dans leur inherits=dans le<@page language=......inherits=> ligne.

La modification du inherits=nom résout l'erreur.

Juste au cas où quelqu'un d'autre partagerait mon problème, j'ai eu cette erreur en essayant de publier un site Web d'un projet nouvellement ramifié, la construction fonctionnait parfaitement.

Il s'avère que j'avais oublié de supprimer la case à cocher "Autoriser le site précompilé à être mis à jour" sous Paramètres de publication -> Configurer la précompilation .

Comme autre point de données, je viens d'avoir ce problème sans aucune preuve de références circulaires comme décrit dans les liens dans la réponse de Ben. Construire mon projet de site Web échouerait avec quelques-unes de ces erreurs, et le paramétrage l'a compilation batch="false"corrigé, mais je ne voulais pas suivre cette voie car il s'agit d'un site Web de production volumineux.

Cette solution était dans un sous-dossier de mon dossier D: \ svn, que j'avais mappé à S :. Lorsque j'ai ouvert la solution à partir de S:, ces erreurs se sont produites, mais si je suis allé directement à D: \ svn et que j'ai ouvert la solution, aucune erreur.

J'ai également remarqué que, malgré le fait d'avoir compilation batch="true"dans mon web.config, lors de l'ouverture de la solution à partir du lecteur S mappé, tous mes fichiers .ascx sont compilés dans leurs propres assemblys. Si je l'ouvre depuis l'emplacement physique, les fichiers .ascx sont compilés dans les assemblages de leurs dossiers respectifs (ce qui batch="true"est censé fonctionner).

Étrange.

Cette erreur était due à un conflit entre le nom de classe du formulaire Web et le stub wsdl (code derrière le fichier .cs) ayant le même nom de classe ie

Page ASPX: Classe de tableau de bord: Tableau de bord de classe particulière

AppCode / APIServices.cs: tableau de bord de classe partielle publique

L'erreur était reproductible uniquement lors de la publication du site Web, mais la construction et le débogage n'ont signalé aucune erreur.

Dans mon cas, j'avais renommé un projet, donc aussi la DLL avait été renommée. Quand je viens de copier la nouvelle DLL mais que je n'ai pas pensé à supprimer l'ancienne du serveur, j'ai rapidement eu un tas de paires de classes avec les mêmes noms. La suppression des dll obsolètes faisait l'affaire (de cause).

Aucune de ces réponses n'a fonctionné pour moi, mais j'ai résolu le problème. Étant donné que j'utilisais la fonction de publication de VS pour déployer l'application Web, j'ai sélectionné l'option permettant de supprimer tous les fichiers existants avant de publier dans l'assistant de publication Web. Cela a forcé une copie propre de l'application et tout a bien fonctionné à partir de là.

Cette solution peut être utile si votre copie de débogage locale fonctionne correctement, mais pas le système publié. Aussi génial si vous ne voulez pas prendre le temps de localiser les DLL individuelles à supprimer et que les fichiers de production sont supprimés en premier.

Dans mon cas, la suppression de tous les assemblys de sortie des dossiers bin dans tous les projets de la solution a résolu le problème. Malheureusement, je n'ai aucune explication pour cela.

Dans mon cas, le problème a été résolu lorsque j'ai édité un fichier Designer.cs qui avait toujours le nom de classe dupliqué. pour une raison quelconque, lorsque j'ai renommé la classe «logout» en «logout2», dans le fichier du concepteur, elle n'a pas été automatiquement modifiée et était toujours «déconnexion», et ce nom de classe existait déjà dans une dll précompilée dans mon projet (qui appartient à une application Web tierce avec laquelle je travaille et que je développe).

Vous avez ce problème lorsque vous placez une partie d'une page aspx dans le contrôle utilisateur séparé. Sur ma machine tout allait bien, sur le serveur a eu une erreur.

Renommé la classe et le fichier de problème.

http://support.microsoft.com/kb/919284 Méthode 2: réorganiser les dossiers dans l'application écrit sur d'éventuelles références circulaires

Aucune de ces solutions n'a fonctionné pour moi. Mes deux DLL en conflit se trouvaient dans C: \ ... \ AppData \ ... \ Fichiers ASP.NET temporaires \ ...

Le problème était que j'avais restauré mon dépôt source vers une version antérieure - avant de déplacer un type d'un projet vers un autre projet dans la même solution.

J'ai essayé de supprimer la nouvelle DLL - qui n'aurait même pas dû être là du tout dans l'ancienne base de code - de l'emplacement "Fichiers ASP.NET temporaires" identifié par msbuild. msbuild vient de le remettre.

J'ai également essayé le paramètre web.config que certains ici ont utilisé avec succès, mais cela n'a pas fonctionné non plus. Bien que, au moment où j'écris ceci, je me rends compte qu'il y avait en fait deux projets MVC dans la même solution et que les deux comportaient des erreurs, le problème peut donc avoir été que je n'ai pas ajouté le paramètre aux deux.

J'ai essayé de faire avancer mon repo source, de nettoyer et de reculer à nouveau et de nettoyer. Rien.

J'ai essayé de supprimer tout l'emplacement "Fichiers ASP.NET temporaires". msbuild vient de le remettre.

Enfin, j'ai essayé de reconstruire dans Visual Studio. Bien que la sortie de ligne de commande et la sortie "Erreurs" aient toutes deux donné la même erreur msbuild "Fichiers ASP.NET temporaires", l'erreur Intellisense - lors du survol du type en conflit - se plaignait en fait des DLL dans les répertoires de sortie. Apparemment, "Clean" et "Rebuild" ne faisaient pas leur travail. J'ai supprimé manuellement les DLL dans les répertoires de sortie identifiés par Intellisense et le problème a été résolu.

tl; dr - Assurez-vous de couvrir toutes vos web.configs avec le paramètre batch, et essayez d'exploiter Intellisense pour plus d'indices.

Mon problème était lié à un fichier .dll qui était généré dans mon dossier de projet.

Si vous faites référence à un autre fichier, au lieu de faire tout ce que vous voyez ci-dessus, ce qui a résolu mon problème instantanément était simplement de supprimer le .dll qui restait dans mon répertoire / bin pour mon projet.

Le problème n'est pas nécessairement un correctif web.config - c'est une référence circulaire qui doit être résolue. J'ai réalisé que j'avais effacé l'ancien .dll dans mon fichier de projet d'origine mais pas dans le projet qui le référençait.

Je ne recommande pas d'apporter la modification à votre fichier web.config car ce n'est qu'une solution de rechange - ne résolvant pas vraiment le problème réel. Faites-le si vous n'avez pas envie de résoudre le problème, mais si vous voulez éviter de futurs maux de tête, supprimez simplement le .dll des deux endroits.

J'ai eu un cours partiel avec le même nom dans deux projets différents. Je l'ai résolu en ne le laissant que dans un seul projet.

Parfois, il peut être utile de supprimer la solution et de la recréer. Étant donné que cette utilisation se produit lors de la conversion de VS2005 à vs2010, certaines références au framework 4.0 (après la mise à niveau) restent dans la solution, même tous les projets sont définis comme 3.5.

Normalement, la reconstruction de la solution devrait résoudre ces problèmes.

J'ai eu le même problème lorsque je compilais l'application sur un serveur de compilation.

Mon contrôleur avait un code statique simple, j'ai donc changé mon ascx:

 <%@ Control Language="C#" AutoEventWireup="true" CodeBehind="controllerName.ascx.cs" Inherits="Controls.controllerName" %>

À

 <%@ Control Language="C#" AutoEventWireup="true" Src="controllerName.ascx.cs" Inherits="Controls.controllerName" %>

Suppression du mot clé partial du codebehind et ajout d'un espace de noms au codebehind.

Ce:

using System;
using System.Web.UI;

/// <summary>
/// My controller
/// </summary>
public partial class controllerName: UserControl
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
}

Pour ça:

using System;
using System.Web.UI;

namespace Controles
{
    /// <summary>
    /// My controller
    /// </summary>
    public class controllerName : UserControl
    {
        protected void Page_Load(object sender, EventArgs e)
        {
        }
    }
}

Et cela a fonctionné pour moi.

Pour moi, cela s'est produit lorsque mon emplacement PrecompiledWeb / Publish était défini sur le répertoire actuel qui était également l'emplacement du dossier racine du site.

Mon site Web voyait alors le dossier de publication dans le cadre du projet lors de la compilation / construction, puis de la recherche de doublons de cette manière.

c.-à-d. ne mettez pas la version publiée / précompilée de votre site dans les dossiers de code de votre site.

Si les DLL s'affichent dans un dossier temporaire, vous devriez essayer de nettoyer votre solution.

Publier ma solution:

Le problème était lié à «l'analyse à l'accès» de Mcafee Antivirus. La désactivation de cela a résolu le problème. D'une manière ou d'une autre, le dossier temporaire ASP n'était pas utilisé correctement par ASP lorsque l'antivirus était activé.

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

Le dossier App_Code est à l'origine du problème, placez la classe en dehors du dossier (fonctionne bien)

Le dossier App_Code n'est pas conçu pour les projets d'application Web

http://vishaljoshi.blogspot.in/2009/07/appcode-folder-doesnt-work-with-web.html

Allez dans Ajouter une référence et recherchez à la fois la dll, les deux dll auraient coché, décochez l'une des dll, car il y a des références à la même dll avec une ambiguïté de version différente est générée.

Ma solution était de remplacer CodePage = "...." par CodeBehind = "..." dans le fichier .aspx. D'une manière ou d'une autre, il a été laissé en tant que CodePage lors d'une migration à partir des versions précédentes de .NET. Cette directive de page crée un autre fichier dll qui entre en conflit avec le fichier dll des projets.

Aucune de ces solutions n'a fonctionné pour moi. La compilation en mode «Release» a fonctionné, mais quand je suis passé à «Debug», j'ai reçu un nombre incalculable de ces messages d'erreur.

Je ne comprends pas pourquoi, mais un simple redémarrage de Visual Studio était ma solution.

J'ai fait face au problème au moment de la compilation.

Je suis d' accord avec le lot = "vrai" attributs , l'erreur indique qu'il existe 2 assemblages

Solution 1: supprimer l'un d'entre eux

Solution2: configurez l'un d'entre eux