D'où provient l'erreur CS0433 "Le type 'X' existe déjà dans A.dll et B.dll"?
Lorsque j'exécute une application Web à partir de Visual Studio 2008 SP1 à l'aide du serveur Web interne (et non d'IIS), je reçois l'erreur mentionnée ci-dessus.
L'erreur complète (fichier source Default.aspx.cs):
Message d'erreur du compilateur: CS0433: Le fichier Le type 'WebApplication3.Site1' existe dans tous les deux 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Fichiers\root\aa563bcf\59deedc0\App_Web_site1.master.cdcab7d2.muczzy9v.dll ' et 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Fichiers\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\Temporary ASP.NET Fichiers\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\Temporary ASP.NET Fichiers\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\Temporary ASP.NET Fichiers\root\aa563bcf\59deedc0\App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs '.
La source des avertissements pointe vers un fichier intermédiaire App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs:
Line 162:
Line 163: [System.Runtime.CompilerServices.CompilerGlobalScopeAttribute()]
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ù ça vient?
La webapp (pas le site!) 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 au fichier maître dans Default.aspx.cs, tout se passe bien. Le maître n'a que du code.
Il s’agit en fait d’une des nombreuses petites applications Web de test inconditionnelles, donc je me moque bien de cela. Mais je n'avais jamais vu cela auparavant et maintenant je suis curieux de savoir quoi faire, à part copier du code dans un nouveau projet (la solution de nettoyage n'aide pas).
Remarque: j'ai lu ce message et quelques autres, ils ne s'appliquent pas.
Théorie
Lorsque ce problème est pas causé par un bogue dans l'application (par exemple, nom de classe en double):
Ce problème semble présenter le fait qu'une modification apportée au projet de l'application entraîne une nouvelle génération (modification de code/référence/ressource, par exemple). Le problème semble résider dans la sortie de cette nouvelle version: pour diverses raisons, Visual Studio ne remplace pas le contenu entier des dossiers obj/bin de votre application. Cela entraîne au moins une partie du contenu du dossier bin de votre application obsolète.
Lorsque ce problème se produit, effacer le dossier «Fichiers temporaires ASP.NET», à lui 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 recopié dans le dossier "Fichiers temporaires ASP.NET" lors du prochain accès à votre application, ce qui entraîne la persistance du problème. La clé consiste à supprimer tous les fichiers existants et à obliger Visual Studio à reconstruire chaque objet. Ainsi, lors du prochain accès à votre application, les nouveaux fichiers bin seront copiés dans le dossier "Fichiers temporaires ASP.NET".
Solution
- Fermer Visual Studio
- Effectuer un iisreset
- Supprimez tous les dossiers et fichiers du dossier "Fichiers temporaires ASP.NET" (le chemin est référencé dans le message d'erreur).
- Supprimer les dossiers "obj" et "bin" de l'application incriminée
- Redémarrez Visual Studio et ouvrez la solution.
- Effectuer une "solution propre" suivie d'une "solution de reconstruction"
Explication
- Etapes 1 et 2: supprimez les verrous de ressources des dossiers/fichiers à supprimer.
- Etapes 3 à 4: supprimer tous les anciens fichiers de construction
- Etapes 5 et 6: créer de nouvelles versions des fichiers de construction
Arrêtez w3svc et supprimez tout ce qui est dans 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 IIS serveurs (64 bits) cela peut également se produire. Chercher:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root(remplacez v4.0.30319 par la version de framework utilisée si celle-ci est plus récente sur votre serveur)
Cela peut arriver si vous placez des fichiers .cs dans App_Code et modifiez leur action de génération pour les compiler dans un projet d'application Web.
Vous devez soit avoir l’action de construction pour les fichiers .cs dans App_Code en tant que contenu, soit changer le nom de App_Code. J'ai changé le nom, car intellisense ne corrige pas les fichiers .cs marqués comme contenu.
Plus d'infos sur http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html
Examinez la balise Inherits de toutes vos pages aspx et pages maîtres. Il y a des chances qu'il y ait deux classes partielles qui portent le même nom. Changer un et recompiler.
Voici quelques informations supplémentaires:
http://blogs.msdn.com/b/carloc/archive/2007/06/12/compiler-error-message-cs0433-in-asp-net-2-0.aspx
Supprimer les fichiers de classe du dossier App_Code et les placer directement sous le site Web a résolu ce problème.
J'ai toujours eu le problème après toutes ces suggestions. Une classe à l'intérieur de App_Code était en train d'être compilée en deux DLL. Quelque chose comme ça (simplifié):
warning CS0436: The type 'HcmDbGeographyModelBinder' in
'<user_profile_dir>\AppData\Local\Temp\Temporary ASP.NET Files\temp\3b1ed8ee\11405e8e\App_Code.oqr0kusq.0.cs'
conflicts with the imported type 'HcmDbGeographyModelBinder' in
'<user_profile_dir>\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, il ne devrait donc pas y avoir de problème pour le traitement des fichiers .cs à la racine du projet Web.
Cela peut se produire lorsque le même nom de classe est spécifié dans plusieurs fichiers .aspx.cs, c.-à-d. Lorsque deux pages sont créées avec un nom de fichier différent mais ont par erreur 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 donne un avertissement, mais l'application s'exécute, mais après la publication, l'application ne fonctionne plus et lève l'exception comme indiqué dans la question du PO.
S'assurer que deux noms de classe ne se chevauchent pas résout le problème.
Cela peut également arriver si vous avez dupliqué TagPrefix dans votre fichier ASPX.
Cela causerait 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 remplaçant simplement le deuxième "uc1" par "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 également résoudre le problème.
J'ai trouvé une autre raison: différentes versions utilisées pour les icônes dans la boîte à outils et les références dans le projet. Après avoir inséré les objets sous une forme quelconque, l'erreur a commencé.
Cela 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"/>
Le Sytem.Web.Helpers a été pointé à 1.0.0.0 au lieu de 3.0.0.0 (MVC 3 est utilisé sur ce projet).
Parce que IIS n'a pas pu trouver la référence dans le dossier local, il a cherché dans le GAC et a trouvé deux versions différentes. Après avoir pointé la référence correcte IIS a trouvé la DLL locale et l’a utilisée au lieu de chercher dans le GAC.
Lors de la construction d'un projet ASP.NET à l'aide de Visual Studio, un message d'erreur semblable au suivant peut s'afficher de manière aléatoire:
Message d'erreur du compilateur: CS0433: Le type 'ASP.summary_common_controls_notes_ascx' existe dans 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Fichiers temporaires ASP.NET\Book_Details\abc12345\def8910\App_Web_msftx123.dll' et ' c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Fichiers ASP.NET temporaires\Book_Details\abc12345\def8910\App_Web_msfty456.dll '
Description: une erreur s'est produite lors de la compilation d'une ressource requise pour traiter cette demande. Veuillez consulter les détails d'erreur spécifiques suivants et modifier votre code source de manière appropriée.
Erreur source: Ligne 100: Ligne 101:
Nouvelle ligne de notes 102:
Ligne 103:
1450, ligne 104:Résumé.
Fichier source: d:\http\post\publisher\default.aspx Ligne: 102
Les scénarios courants dans lesquels cette erreur peut se produire sont décrits ci-dessous.
Scénario 1
Description: une cause fréquente survient quand il y a deux assemblys dans le même dossier bin d'application Web contenant deux définitions de classe mais qui portent le même nom de classe. Cela peut se produire si plusieurs Default.aspx ont été compilés dans un seul assembly. Cela se produit généralement lorsque la page maître (Default.master) et la page ASPX par défaut (Default.aspx) déclarent toutes les deux une classe _Default. Solution: modifiez le nom de classe de la page maître (à partir de _Default dans la plupart des cas) et régénérez le projet. Il est important de résoudre tout conflit de nommage entre les classes.
Scénario 2
Description: les chemins de référence dans Visual Studio permettent de spécifier le chemin de dossier des références d'assembly utilisées par le projet. Il est possible que le chemin contienne un assembly contenant le même nom de classe. Il se peut que plusieurs références aient été ajoutées au même assemblage (éventuellement une version ou un nom différent), ce qui est à l'origine d'un conflit de noms.
Solution: Supprimez l'ancienne référence de version. Pour ce faire, dans Visual Studio, cliquez avec le bouton droit de la souris sur votre site Web et cochez la case "Références" dans les propriétés.
Scénario 3
Description: par défaut, lorsqu'une application Web ASP.NET est compilée, le code compilé est placé dans le dossier Temporary ASP.NET Files. Par défaut, les autorisations d'accès sont attribuées au compte d'utilisateur local ASP.NET, qui dispose des autorisations de haute confiance nécessaires pour accéder au code compilé. Il est possible que certaines modifications des autorisations par défaut entraînent des conflits de version. Une autre possibilité serait qu'un logiciel anti-virus verrouille par inadvertance un assemblage .. Solution. Supprimez tout le contenu du dossier Fichiers temporaires ASP.NET.
Scénario 4
Description: lorsque l'attribut batch du fichier web.config est défini sur True, le délai provoqué par la compilation requise est éliminé, ce qui élimine le délai requis pour la première utilisation d'un fichier. ASP.NET précompile tous les fichiers non compilés en mode de traitement par lots, ce qui entraîne des retards lors de la première compilation des fichiers. La désactivation de la compilation par lots peut exposer des erreurs de compilation masquées pouvant exister dans l'application, mais ne sont pas signalées. Toutefois, ce qui est plus important pour ce problème, il demande à ASP.NET de compiler de manière dynamique des fichiers .aspx/.ascx individuels en assemblys distincts au lieu d’un seul ensemble . Solution: définissez batch = false dans la section Web.config. Cela doit être considéré comme une solution temporaire, car la définition de batch = false dans la section compilation a un impact significatif sur les performances en termes de temps de génération de l'application dans Visual Studio.
Scénario 5
Description: la modification du fichier web.config pour une application ASP.NET ou la modification d'un fichier du dossier bin (par exemple, l'ajout, la suppression ou le changement de nom) entraîne le redémarrage de l'AppDomain. Lorsque cela se produit, tout l'état de la session est perdu et les éléments mis en cache sont supprimés du cache lors du redémarrage du site Web. Il est possible que le problème soit dû à un état incohérent dans l'application Web . Solution: déclenchez un redémarrage de AppDomain en touchant (en modifiant) le fichier web.config.
Scénario 6
Description: vous pouvez stocker le code source dans le dossier App_Code. Il sera automatiquement compilé au moment de l’exécution. L'assembly obtenu est accessible à tout autre code de l'application Web. Le dossier App_Code fonctionne donc beaucoup comme le dossier Bin, sauf que vous pouvez y stocker du code source au lieu du code compilé. La classe sera recompilée en cas de modification du fichier source. En cas de conflit dû à un assembly obsolète, le fait de forcer une recompilation peut résoudre le problème ..__ Solution: touchez un fichier dans les dossiers Bin ou App_Code pour déclencher une recompilation complète.
Dans notre cas, la raison était une différence dans les versions .dll de sites dans IIS. Ils sont placés les uns sous les autres dans IIS, vous permettant d'accéder à l'autre via un sous-domaine. Il hérite du premier web.config, et en le combinant avec le prochain web.config, il échouait, car il comportait différentes versions de mvc.dll.
Pour moi du moins, cela s'est produit lorsque j'ai supprimé une référence à une assemblée et ajouté une référence à une version plus récente de celle-ci, qui portait un nom différent. Dans ce cas, il semble que l'ancienne Assemblée soit restée dans le dossier bin etobj et n'a pas été supprimée avec l'opération de solution propre de Visual Studio (peut-être parce qu'elle ne fait plus partie du projet) . Dans ce cas, il suffisait de supprimer le contenu des dossiers bin et obj du projet où l’erreur se produit, à partir de l’explorateur Windows (ou d’un outil de gestion de fichiers). Ensuite, à partir de Visual Studio, nettoyez la solution et reconstruisez-la.
J'ai eu le même problème avec deux contrôles ascx ayant le même nom de classe:
Control1: <% @ Control Language = "C #" ClassName = " 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 #" ClassName = " myClassName1 " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName2 "AutoEventWireup =" true ...>
Fermez la solution et rouvrez-la, puis vérifiez les références de projets pour doubling:
Cela peut arriver si vous utilisiez NuGet et que vous changiez l'emplacement de référence des DLL. Pour résoudre ce problème, vous devez éditer manuellement le fichier proj 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')" />
Attention, ces références "<Import" peuvent apparaître à différents endroits du fichier proj.
Je convertis un ancien site Web asp.net (v 1 ou 2) pour qu'il s'exécute sous .net 4.5 en tant qu'application Web.
Ma solution consistait à déplacer les délégués du gestionnaire d'événements de 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 plusieurs raisons à cela. Et la plupart de celles mentionnées ci-dessus s'appliquent à différents scénarios. Ce que j'ai remarqué, 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 définir ceci et cela fonctionne.
J’ai eu le même problème . Voici ma solution: Placez les classes isolées nécessitant la propriété [Build Action] définie en tant que [Compile] dans tout dossier autre que App_Code comme Application_Code car le dossier App_Code sera compilé en tant qu’assembly séparé, ayant le même Classe compilée en 2 assemblées.
J'ai été redirigé ici en cliquant sur le premier hit Google en cliquant sur l'URL d'erreur pour CS0433, en particulier,
The type 'Package' exists in both 'Windows... Version=N.N.N.N, Culture=neutral, PublicKeyToken=null, ContentType=Windows...' and 'Windows..., Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=Windows...'
Au lieu de décrire tout ce que j'ai fait pour le réparer, laissez-moi vous raconter ce que j'ai fait pour le briser. Je suis allé mettre à jour les paquets NuGet pour un dépôt qui nécessitait une mise à jour de code. Les paquets étaient assez vieux (environ un an) et tout ce que j’avais essayé de faire au départ était de le mettre à jour pour un projet C #.
Entre le démarrage de ce processus et la rencontre de cette erreur, j'ai rétrogradé la version des projets C++ de ce SLN pour cibler 15063. J'ai également remarqué que le projet C # avait à la fois le TargetPlatformMinVersion et le TargetPlatformVersion nouvellement défini sur 10.0.17134.0
La seule chose que je devais faire pour "réparer" était de changer le TargetPlatformMinVersion en une version supérieure au TargetPlatformMinVersion du projet C #. La modification du projet C++ en l'une ou l'autre version n'a pas modifié le comportement. Je ne sais pas pourquoi cela a soudainement cessé de fonctionner, mais j'espère qu'une personne bloquée de la même manière pourrait se sortir d'un pétrin en utilisant des stratégies similaires.
J'ai fini par changer la façon dont le MasterType est référencé dans la page.
J'ai changé: <%@ MasterType VirtualPath="~/x/y/MyMaster.Master" %>to <%@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>
Voir ici pour plus de détails.
J'espère que cela aide quelqu'un.
En plus d'essayer la réponse de 2Toad, j'ai également dû fermer Visual Studio et supprimer mon dossier .vs. Après cela, tout est construit correctement.
Incidemment, l'erreur que j'ai rencontrée ne spécifiait pas du tout mon dossier Temp, mais faisait référence à quelque chose d'autre qui était évidemment généré par le système. J'ai négligé de sauvegarder l'erreur spécifique: \
Une solution très rapide et pratique consiste à abuser de l'intellisense incroyable de Visual Studio en référençant temporairement la classe quelque part.
Exemple:
System.Runtime.CompilerServices.ExtensionAttribute x = null;
Lors de la construction ou du survol du curseur sur la ligne, vous pouvez afficher l’erreur suivante:
'System.Runtime.CompilerServices.ExtensionAttribute' existe dans les deux fichiers 'C:\Programmes\Assemblys de référence\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. Supprimez l’autre.
J'ai trouvé le mien assis dans le répertoire bin, mais c'est peut-être ailleurs dans le projet.
En fait, il convient de le garder à l'esprit car, étant donné que le répertoire bin peut ne pas être inclus dans l'ensemble de modifications TFS, il peut expliquer pourquoi la vérification de vos modifications ne résout pas le problème pour les autres membres de votre équipe .