D'où vient l'erreur CS0433 “Type " X " existe déjà dans les deux A.dll et B.dll ”?

Arrêter w3svc et supprimer tout de c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\

ajouté

• sur Windows 7

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

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

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

  (remplacer v4.0.30319 par le cadre de la version que vous utilisez si une version plus récente sur votre serveur)

OriginalL'auteur Alex Polkhovsky

Ce qui pourrait arriver si vous placez .cs fichiers dans App_Code et changé leur action de construire à compiler dans un Projet d'Application Web.

Soit de l'action de construire pour la .cs fichiers dans App_Code comme Contenu ou de modifier le nom de App_Code à autre chose. J'ai changé le nom depuis intellisense ne sera pas corrigé .cs fichiers marqués comme contenu.

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

OriginalL'auteur Lilja

Cela peut aussi arriver si vous avez des TagPrefix dans votre fichier ASPX.

Ce serait la cause de 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" à "uc2"

Fixe...

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

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

OriginalL'auteur Jason Geiger

Cela peut se produire lorsque le même nom de classe est spécifié dans plusieurs .aspx.cs fichiers, c'est à dire
lorsque les 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 construction de la webapplication cela donne un avertissement, mais l'application s'exécute, cependant, après la publication de la demande ne fonctionne plus et lève l'exception comme mentionné dans le cas des OP question.

Veillant à ce que les deux noms de classe de ne pas se chevauchent résout le problème.

OriginalL'auteur Deepak

Ce qui m'est arrivé à cause d'une erreur dans mon Web.Config

<add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Web.WebPages, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

La Sytem.Web.Helpers a été souligné dans 1.0.0.0 au lieu de 3.0.0.0 (MVC 3 est utilisé sur ce projet).

Parce qu'IIS n'arrivais pas à trouver la référence dans le dossier local il a regardé dans le GAC et a trouvé deux versions différentes. Après la pointant vers la bonne référence IIS trouvé le local dll et utilisées qu'au lieu de chercher le GAC.

OriginalL'auteur mlapaglia

Référence : https://support.microsoft.com/en-in/help/2028526/building-an-asp-net-project-in-visual-studio-results-in-compiler-error

Lors de la construction d'un ASP.NET projet à l'aide de Visual Studio, vous pouvez au hasard voir un message d'erreur semblable au suivant:

Compilateur Message d'Erreur: CS0433: Le type 'ASP.summary_common_controls_notes_ascx' existe dans les deux 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msftx123.dll" et "c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msfty456.dll'

Description: Une erreur s'est produite lors de la compilation d'une ressource nécessaire pour répondre à cette demande. Veuillez examiner les détails des erreurs spécifiques et modifier votre code source de manière appropriée.

Source De L'Erreur: Ligne 100: Ligne 101:

De Nouvelles Notes De La Ligne 102:

Ligne 103:

1450 Ligne 104:

Résumé.

Fichier Source: d:\http\post\publisher\default.aspx Ligne: 102

Scénarios courants où cette erreur peut se produire sont discutés ci-dessous

Scénario 1

Description: Une cause commune, c'est quand il y a deux assemblées dans la même application web bin contenant deux définitions de classe mais qui ont le même nom de classe. Cela peut se produire si plus d'un Défaut.aspx été compilées en une seule assemblée. Souvent, cela se produit lorsque la page principale (valeur par Défaut.le maître) et la page ASPX par Défaut (valeur par Défaut.aspx) déclarer un _Default classe.
Solution: Modifiez le nom de la classe de la page principale (à partir de _Default dans la plupart des cas) et de reconstruire le projet. Il est important de résoudre tout conflit de noms entre les classes.

Scénario 2

Description: La Référence des Chemins dans Visual Studio est utilisé pour spécifier le chemin d'accès au dossier pour l'assemblage des références utilisées par le projet. Il est possible que le chemin d'accès contient un assembly qui contient le même nom de classe. Il est peut-être qu'il y a de multiples Références ajoutées à la même assemblée (éventuellement différentes version ou le nom) provoquant un conflit de noms.

Solution: Supprimer l'ancienne version de référence. Pour ce faire, dans Visual Studio avec le bouton droit de la souris sur votre site web et de vérifier les "Références" dans les propriétés.

Scénario 3

Description: Par défaut, lorsqu'un ASP.NET l'application Web est compilé le code compilé est placé dans le Temporaire ASP.NET dossier de Fichiers. Par défaut, les autorisations d'accès sont donnés à l'ASP.NET compte d'utilisateur local, qui a la haute-approbation des autorisations nécessaires pour accéder à du code compilé. Il est possible que certains changements ont été apportés dans les autorisations par défaut causant la gestion des versions des conflits. Une autre possibilité serait que le logiciel anti-virus pourrait être le verrouillage d'un assemblage par inadvertance.
Solution: Désactivez le Temporaire ASP.NET Dossier de Fichiers de tous les contenus.

Scénario 4

Description: Lorsque le lot attribut dans le web.la config est définie sur True, il élimine le retard causé par la compilation nécessaire lorsque vous accédez à un fichier pour la première fois. ASP.NET précompilation de l'onu, les fichiers compilés dans un mode batch, ce qui retarde la première fois que les fichiers sont compilés. La désactivation de la compilation par lot peut exposer masqué des erreurs de compilation qui peuvent exister dans l'application, mais ne sont pas signalés. Cependant le plus important pour cette question, il dit ASP.NET pour compiler dynamiquement individu .aspx/.ascx fichiers dans des assemblées distinctes au lieu d'une seule assemblée.
Solution: Définissez lot=false dans la section web.config. Cela devrait être considéré comme une solution temporaire en tant que paramètre de lot=false dans la compilation de la section a un impact significatif sur les performances sur le temps de compilation de l'application dans Visual Studio.

Scénario 5

Description: la Modification du web.fichier de configuration pour un ASP.NET l'application ou la modification d'un fichier dans le dossier bin (telles que l'ajout, la suppression ou le changement de nom) provoque le domaine d'application de redémarrer. Lorsque cela se produit tout état de session est perdue et la mise en cache des éléments sont supprimés de la mémoire cache, comme le site web redémarre. Il est possible que le problème est provoqué par un état incohérent dans l'application web.
Solution: le Déclenchement d'un domaine d'application à redémarrer par le toucher (le montage) sur le web.fichier de configuration.

Scénario 6

Description: Vous pouvez stocker le code source dans le dossier App_Code, et il sera automatiquement compilé au moment de l'exécution. L'assemblage qui en résulte est accessible à tout autre code dans l'application Web. Le dossier App_Code fonctionne donc un peu comme le dossier Bin, sauf que vous pouvez stocker le code source dans ce lieu de code compilé. La classe sera recompilé quand il ya un changement dans le fichier source. Si il y a des conflits en raison de la vétusté de l'assemblée alors forcement une recompilation peut résoudre le problème.
Solution: appuyez sur un fichier dans la Corbeille ou App_Code dossiers pour déclencher une recompilation complète.

OriginalL'auteur Sandeep Kumar

Pour moi au moins, ce qui s'est passé quand j'ai enlevé une référence à une assemblée et d'y ajouter une référence à une version plus récente d'elle, qui avait un nom différent. Dans ce cas, il semble que l'ancienne assemblée est resté dans la bin et obj dossier, et n'a pas été supprimé avec la solution propre fonctionnement à partir de Visual Studio (peut-être parce qu'il ne fait pas partie du projet plus). Dans ce cas, il suffisait de supprimer le contenu de la bin et obj dossiers du projet où il erreur se produit, à partir de l'Explorateur Windows (ou un outil de gestion de fichiers). Puis, à partir de Visual Studio, propre à la solution et à reconstruire.

OriginalL'auteur Guillermo Gutiérrez

J'ai eu le même problème.
C'est ma solution :
Mettre isolé classes qui nécessitent de la propriété [Build Action] définir comme [Compile] vers un dossier autre que App_Code comme Application_Code depuis le App_Code dossier sera compilé en tant que distincte de l'assemblée, ayant la même Classe compilée dans les 2 assemblées.

OriginalL'auteur ali mahmoodi

Proche de la Solution et de l'ouvrir à nouveau, puis vérifiez les références de projets pour de doubler:

Cela peut se produire si vous avez été à l'aide de NuGet et changé la Dll endroit de référence. Pour corriger cela, vous devez modifier manuellement le proj fichier en supprimant les entrées, par exemple:

  <Import Project="..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets" Condition="Exists('..\packages\CefSharp.WinForms.53.0.0\build\CefSharp.WinForms.targets')" />

Montre que ces "<Import" références peuvent apparaître à différents endroits dans le proj fichier.

OriginalL'auteur Jeremy Thompson

Je suis de la conversion d'un vieux asp.net (v 1 ou 2) site web pour s'exécuter sous .net 4.5 comme une application web.

Ma solution a été de déplacer le contrôle de l'utilisateur du gestionnaire d'événement délégués qui ont été à l'origine du problème à un fichier physique:

//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)
    {

OriginalL'auteur marcel_g

aller à web.config

dans le <compilation ajouter batch="false"

il devrait résoudre le problème

OriginalL'auteur Adeel