Woher kommt der Fehler CS0433 “Type ‘X’ existiert bereits in A.dll und B.dll” herkommen?

Wenn ich eine Webanwendung von Visual Studio 2008 SP1 unter Verwendung des internen Webservers (nicht IIS) ausführe, erhalte ich den oben genannten Fehler.

Der vollständige Fehler (Quelldatei Default.aspx.cs ):

Compiler-Fehlermeldung: CS0433: Der Typ ‘WebApplication3.Site1’ existiert sowohl in ‘c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2. muczzy9v.dll ‘und’ c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ 80dd34ed_6968ca01 \ WebApplication3.DLL ‘

Die vorhergehende vollständige Warnung:

Warnung: CS0436: Der Typ ‘WebApplication3._Default’ in ‘c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0. cs Konflikte mit dem importierten Typ ‘WebApplication3._Default’ in ‘c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ root \ aa563bcf \ 59deedc0 \ assembly \ dl3 \ 44c3a3cf \ e096e61c_6568ca01 \ WebApplication3 .DLL ‘. Verwenden Sie den in ‘c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ root \ aa563bcf \ 59deedc0 \ App_Web_default.aspx.cdcab7d2._tlkwdos.0.cs’ definierten Typ.

Quelle von Warnpunkten auf eine Zwischendatei 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; 

und meine Frage: Woher kommt das?

Die Webapp (nicht Website!) Hat eine Default.aspx und eine Site1.Master , keine Abhängigkeiten. Sie sind fast leer, mit einem asp:Label auf der Seite. Zuvor funktionierte diese Webanwendung einwandfrei. Wenn ich Referenzen in Default.aspx.cs auf den Master lösche, geht alles gut. Der Master hat nur einen Code.

Es ist tatsächlich eine von vielen kleinen Feuer-und-vergessen-Test-Webapps, also ist mir das egal. Aber ich hatte das vorher nicht gesehen und jetzt bin ich neugierig was zu tun ist, außer Code in ein neues Projekt zu kopieren (Reinigungslösung hilft nicht).

Hinweis: Ich habe diesen Beitrag gelesen und einige andere, sie gelten nicht.

Theorie

Wenn dieses Problem nicht durch einen Fehler in der Anwendung verursacht wird (z. B. doppelter classnname):

Dieses Problem tritt auf, nachdem eine Änderung am Projekt der Anwendung vorgenommen wurde, die zu einem neuen Build führt (z. B. Code- / Referenz- / Ressourcenänderung). Das Problem scheint in der Ausgabe dieses neuen Builds zu liegen: Aus verschiedenen Gründen ersetzt Visual Studio nicht den gesamten Inhalt der Obj / Bin-Ordner Ihrer Anwendung. Dies führt dazu, dass mindestens ein Teil des Inhalts des bin-Ordners Ihrer Anwendung nicht mehr aktuell ist.

Wenn dieses Problem auftritt, wird das Problem durch das Löschen des Ordners “Temporäre ASP.NET-Dateien” allein nicht getriggers. Es kann das Problem nicht beheben, da der veraltete Inhalt des bin-Ordners Ihrer Anwendung beim nächsten Zugriff auf Ihre Anwendung wieder in den Ordner “Temporäre ASP.NET-Dateien” kopiert wird, wodurch das Problem weiterhin besteht. Der Schlüssel besteht darin, alle vorhandenen Dateien zu entfernen und Visual Studio zu zwingen, jedes Objekt neu zu erstellen. Wenn Sie also das nächste Mal auf Ihre Anwendung zugreifen, werden die neuen Bin-Dateien in den Ordner “Temporäre ASP.NET-Dateien” kopiert.

Lösung

  1. Schließen Sie Visual Studio
  2. Führe ein iisreset durch
  3. Löschen Sie alle Ordner und Dateien in dem Ordner “Temporary ASP.NET Files” (der Pfad wird in der Fehlermeldung verwiesen)
  4. Löschen Sie die Ordner “obj” und “bin” der betreffenden Anwendung
  5. Starten Sie Visual Studio neu und öffnen Sie die Lösung
  6. Führen Sie eine “Clean Solution”, gefolgt von einer “Rebuild Solution” durch

Erläuterung

  • Schritte 1-2: Entfernen Sie Ressourcensperren aus den Ordnern / Dateien, die wir löschen müssen.
  • Schritte 3-4: Entfernen Sie alle alten Build-Dateien
  • Schritte 5-6: Erstellen Sie neue Versionen der Build-Dateien

Fahren Sie w3svc herunter, und löschen Sie alles unter c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\

hinzugefügt

  • unter Windows 7

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

  • Bei IIS-Servern (64 Bit) kann dies ebenfalls auftreten. Suche:

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

    (Ersetzen Sie v4.0.30319 durch die von Ihnen verwendete Framework-Version, falls diese neuer auf Ihrem Server ist)

Sehen Sie sich das Inherits-Tag aller aspx-Seiten und Masterseiten an. Wahrscheinlich gibt es zwei Teilklassen, die denselben Namen haben. Ändere eins und kompiliere neu.

Hier sind einige weitere Informationen:

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

Dies kann passieren, wenn Sie .cs-Dateien in App_Code platzieren und ihre Erstellungsaktion so ändern, dass sie in einem Webanwendungsprojekt kompiliert wird.

Entweder haben Sie die Build-Aktion für die .cs-Dateien in App_Code als Inhalt oder ändern den Namen von App_Code in etwas anderes. Ich habe den Namen geändert, da intellisense keine .cs Dateien repariert, die als Inhalt markiert sind.

Weitere Informationen unter http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html

Das Entfernen der classndateien aus dem App_Code Ordner und das direkte Platzieren unter der Website haben dieses Problem für mich getriggers.

Dies kann auch passieren, wenn Sie TagPrefix in Ihrer ASPX-Datei dupliziert haben.

Dies würde diesen Fehler verursachen …

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

Sie können dies beheben, indem Sie einfach das 2. “uc1” in “uc2” ändern.

Fest…

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

“Clean Solution” gefolgt von “Rebuild Solution” scheint es ebenfalls zu beheben.

Dies kann vorkommen, wenn derselbe classnname in mehreren .aspx.cs Dateien angegeben ist, dh wenn zwei Seiten mit unterschiedlichen Dateinamen erstellt wurden, die aber aus Versehen den gleichen classnnamen haben.

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

Beim Erstellen der Webapplikation wird zwar eine Warnung ausgegeben, die Anwendung läuft jedoch nach dem Veröffentlichen der Anwendung nicht mehr und triggers die Ausnahme aus, wie in der OP-Frage erwähnt.

Stellen Sie sicher, dass zwei classnnamen sich nicht überschneiden, um das Problem zu lösen.

Ich hatte immer noch das Problem nach all diesen Vorschlägen. Einige classn in App_Code wurden in zwei DLLs kompiliert. So etwas (vereinfacht):

 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'. 

Ich habe gerade den Ordner “App_Code” in “Code” umbenannt. Dies ist ein MVC5-Projekt, daher sollte es kein Problem geben, CS-Dateien im Stammverzeichnis des Webprojekts bereitzustellen.

Dies ist mir aufgrund eines Fehlers in meiner Web.Config passiert

      

Der Sytem.Web.Helpers wurde auf 1.0.0.0 statt auf 3.0.0.0 gezeigt (MVC 3 wird für dieses Projekt verwendet).

Da IIS den Verweis im lokalen Ordner nicht finden konnte, wurde er im GAC gesucht und zwei verschiedene Versionen gefunden. Nach dem Zeigen auf die richtige Referenz fand IIS die lokale DLL und benutzte diese, anstatt den GAC zu durchsuchen.

Ich habe einen anderen Grund gefunden: verschiedene Versionen für Icons in Toolbox und Referenzen im Projekt. Nach dem Einfügen der Objekte in irgendeiner Form wurde der Fehler gestartet.

Ich änderte schließlich, wie der MasterType in der Seitenmarkierung referenziert wird.

Ich habe geändert: < %@ MasterType VirtualPath="~/x/y/MyMaster.Master" %> bis < %@ MasterType TypeName="FullyQualifiedNamespace.MyMaster" %>

Siehe hier für Details.

Hoffe das hilft jemandem aus.

Dies geschah zumindest für mich, als ich einen Verweis auf eine Assembly entfernte und einen Verweis auf eine neuere Version hinzufügte, die einen anderen Namen hatte. In diesem Fall scheint die alte Assembly im Ordner bin und obj geblieben zu sein und wurde nicht mit der Operation saubere Lösung aus Visual Studio entfernt (vielleicht, weil sie nicht mehr Teil des Projekts ist). In diesem Fall reichte es aus, den Inhalt der Ordner bin und obj des Projekts, in dem der Fehler auftritt , aus dem Windows Explorer (oder einem Dateiverwaltungstool) zu löschen. Löschen Sie dann in Visual Studio die Lösung und erstellen Sie sie neu.

In unserem Fall war der Grund ein Unterschied in den DLL-Versionen von Websites in IIS. Sie werden in IIS untereinander platziert, sodass Sie über eine Subdomain auf den anderen zugreifen können. Es erbt von der ersten web.config, und kombiniert diese mit der nächsten web.config, fehlgeschlagen, mit verschiedenen Versionen von mvc.dll.

Ich hatte das ähnliche Problem. Dies ist meine Lösung: Setzen Sie isolierte classn, die die Eigenschaft [Build Action] als [Compile] in einen anderen Ordner als App_Code wie Application_Code App_Code da der App_Code Ordner als separate Assembly kompiliert wird und dieselbe class in 2 Assemblys kompiliert wird.

Ich hatte dasselbe Problem mit zwei ascx-Steuerelementen mit demselben classnnamen:

Control1: < % @ Control Language = "C #" Klassenname = " myClassName ” AutoEventWireup = “Wahr …> Control2: < % @ Control Language =" C # "Klassenname =" myClassName “AutoEventWireup =” True …>

Ich habe es durch einfaches Umbenennen des classnnamens behoben:

Control1: < % @ Control Language = "C #" Klassenname = " myClassName1 ” AutoEventWireup = “Wahr …> Control2: < % @ Control Language =" C # "Klassenname =" myClassName2 “AutoEventWireup =” True …>

Schließen Sie die Lösung, und öffnen Sie sie erneut. Überprüfen Sie dann die Projektreferenzen auf Dopplung :

Bildbeschreibung hier eingeben

Dies kann passieren, wenn Sie NuGet verwenden und den Speicherort der DLLs ändern. Um es zu beheben, müssen Sie die proj-Datei manuell bearbeiten, indem Sie die Einträge entfernen, zB:

   

Achten Sie darauf, dass diese “

Eine super schnelle und praktische Lösung besteht darin, das unglaubliche Intellisense von Visual Studio zu missbrauchen, indem man die class irgendwo temporär referenziert.

Beispiel:

 System.Runtime.CompilerServices.ExtensionAttribute x = null; 

Wenn Sie den Cursor über die Linie bewegen oder den Mauszeiger darüber bewegen, können Sie den folgenden Fehler anzeigen:

‘System.Runtime.CompilerServices.ExtensionAttribute’ existiert in ‘C: \ Programme \ Reference Assemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll’

Dies teilt Ihnen die zwei Quellen mit, die den Konflikt sofort verursachen.

System.Core.dll ist die DLL-Datei, die Sie behalten möchten, löschen Sie also die andere.

Ich habe festgestellt, dass ich im bin sitzt, aber möglicherweise an anderer Stelle im Projekt.

In der Tat sollte dies berücksichtigt werden, da das bin Verzeichnis möglicherweise nicht Teil des TFS-Changesets ist. Dies kann erklären, warum das Einchecken Ihrer Änderungen das Problem für andere Teammitglieder nicht triggers .

Ich konvertiere eine alte asp.net (v 1 oder 2) Website, die unter .net 4.5 als Webanwendung läuft.

Meine Lösung bestand darin, die Benutzersteuerelement-Ereignishandlerdelegaten, die das Problem verursachten, in eine separate physische Datei zu verschieben:

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

Dafür gibt es recht viele Gründe. Und die meisten der oben genannten gelten für verschiedene Szenarien. Was ich festgestellt habe, ist, dass der Fehler NUR auftritt, wenn die Authentifizierung auf etwas anderes als “None” gesetzt ist. Für meine Testzwecke werde ich das einstellen und es funktioniert.

Gehe zu web.config

in der add batch="false"

Es sollte das Problem beheben

Ja, hatte das gleiche Problem und triggerse es, indem er die Erben von c # code und page tag in aspx änderte