Woher kommt der Fehler CS0433 "Typ 'X' existiert bereits in A.dll und B.dll"?

Question 1

Wenn ich eine Webanwendung von Visual Studio 2008 SP1 über den internen Webserver (nicht IIS) ausführe, wird der oben genannte Fehler angezeigt.

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

Compiler-Fehlermeldung: CS0433: Der Typ 'WebApplication3.Site1' ist in beiden 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2 vorhanden. 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.

Die Quelle der Warnhinweise verweist 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 Webanwendung (keine Website!) Hat eine Default.aspx und eine Site1.Master , keine Abhängigkeiten. Sie sind fast leer, mit einem asp:Labelauf der Seite. Zuvor funktionierte diese Webanwendung einwandfrei. Wenn ich in Default.aspx.cs Verweise auf den Master entferne, läuft alles gut. Der Master hat nur Code.

Es ist tatsächlich eine von vielen kleinen Test-Webanwendungen, bei denen es um Feuer und Vergessen geht, also könnte es mich nicht weniger interessieren. Aber ich hatte das vorher noch nicht gesehen und jetzt bin ich gespannt, was ich tun soll, außer Code in ein neues Projekt zu kopieren (Reinigungslösung hilft nicht).

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

Question 2

Theorie

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

Dieses Problem tritt anscheinend 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 zumindest ein Teil des Inhalts des Bin-Ordners Ihrer Anwendung veraltet ist.

Wenn dieses Problem auftritt, kann das Problem nicht allein durch Löschen des Ordners "Temporäre ASP.NET-Dateien" behoben werden. Das Problem kann nicht gelöst werden, 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. Beim nächsten Zugriff auf Ihre Anwendung werden die neuen Bin-Dateien in den Ordner "Temporäre ASP.NET-Dateien" kopiert.

Lösung

Schließen Sie Visual Studio
Führen Sie einen iisreset durch
Löschen Sie alle Ordner und Dateien im Ordner "Temporäre ASP.NET-Dateien" (auf den Pfad wird in der Fehlermeldung verwiesen).
Löschen Sie die Ordner "obj" und "bin" der betreffenden Anwendung
Starten Sie Visual Studio neu und öffnen Sie die Lösung
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

Question 3

Fahren Sie w3svc herunter und löschen Sie alles aus 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\
Auf IIS-Servern (64 Bit) kann dies ebenfalls auftreten. Suchen:

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

(Ersetzen Sie v4.0.30319 durch die Framework-Version, die Sie verwenden, wenn auf Ihrem Server eine neuere Version vorhanden ist.)

Question 4

Dies kann passieren, wenn Sie CS-Dateien in App_Code ablegen und deren Erstellungsaktion so ändern, dass sie in einem Webanwendungsprojekt kompiliert werden.

Führen Sie entweder die Erstellungsaktion für die CS-Dateien in App_Code als Inhalt aus oder ändern Sie den Namen von App_Code in einen anderen Namen. Ich habe den Namen geändert, da Intellisense keine als Inhalt markierten CS-Dateien repariert.

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

Question 5

Sehen Sie sich das Inherits-Tag aller Ihrer Aspx- und Masterseiten an. Möglicherweise gibt es zwei Teilklassen mit demselben Namen. Ändern Sie eine und kompilieren Sie neu.

Hier noch ein paar Infos:

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

Question 6

Nach all diesen Vorschlägen hatte ich immer noch das Problem. Eine Klasse in App_Code wurde in zwei DLLs kompiliert. So etwas (vereinfacht):

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

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.

Question 7

Das Entfernen der Klassendateien aus dem App_CodeOrdner und das direkte Platzieren unter der Website hat dieses Problem für mich behoben.

Question 8

Dies kann auch passieren, wenn Ihre ASPX-Datei ein doppeltes TagPrefix enthält.

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" %>

Question 9

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

Beim Erstellen eines ASP.NET-Projekts mit Visual Studio wird möglicherweise zufällig eine Fehlermeldung angezeigt, die der folgenden ähnelt:

Compiler-Fehlermeldung: CS0433: Der Typ 'ASP.summary_common_controls_notes_ascx' ist in beiden 'c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ Book_Details \ abc12345 \ def8910 \ App_Web_msftx123.dll' und 'vorhanden. c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ Book_Details \ abc12345 \ def8910 \ App_Web_msfty456.dll '

Beschreibung: Beim Kompilieren einer Ressource, die zur Bearbeitung dieser Anforderung erforderlich ist, ist ein Fehler aufgetreten. Bitte überprüfen Sie die folgenden spezifischen Fehlerdetails und ändern Sie Ihren Quellcode entsprechend.

Quellfehler: Zeile 100: Zeile 101:
Neue Notizen Zeile 102:
Zeile 103:
1450 Zeile 104:

Zusammenfassung.

Quelldatei: d: \ http \ post \ publisher \ default.aspx Zeile: 102

Häufige Szenarien, in denen dieser Fehler auftreten kann, werden unten erläutert

Szenario 1

Beschreibung: Eine häufige Ursache ist, dass sich zwei Assemblys im selben Ordner für Webanwendungsbereiche befinden, die zwei Klassendefinitionen enthalten, aber denselben Klassennamen haben. Dies kann passieren, wenn mehr als eine Default.aspx in einer einzelnen Assembly kompiliert wurde. Dies tritt normalerweise auf, wenn sowohl die Masterseite (Default.master) als auch die Standard-ASPX-Seite (Default.aspx) eine _Default-Klasse deklarieren. Lösung: Ändern Sie den Klassennamen der Masterseite (in den meisten Fällen von _Default) und erstellen Sie das Projekt neu. Es ist wichtig, Namenskonflikte zwischen Klassen zu lösen.

Szenario 2

Beschreibung: Die Referenzpfade in Visual Studio werden verwendet, um den Ordnerpfad für Assemblyreferenzen anzugeben, die vom Projekt verwendet werden. Möglicherweise enthält der Pfad eine Assembly, die denselben Klassennamen enthält. Möglicherweise werden derselben Assembly mehrere Verweise hinzugefügt (möglicherweise eine andere Version oder ein anderer Name), was zu einem Namenskonflikt führt.
Lösung: Entfernen Sie die alte Versionsreferenz. Klicken Sie dazu in Visual Studio mit der rechten Maustaste auf Ihre Website und überprüfen Sie die "Verweise" in den Eigenschaften.

Szenario 3

Beschreibung: Wenn eine ASP.NET-Webanwendung kompiliert wird, wird der kompilierte Code standardmäßig im Ordner Temporäre ASP.NET-Dateien abgelegt. Standardmäßig werden die Zugriffsberechtigungen an das lokale ASP.NET-Benutzerkonto vergeben, das über die für den Zugriff auf kompilierten Code erforderlichen Vertrauensstellungen verfügt. Es ist möglich, dass einige Änderungen an den Standardberechtigungen zu Versionskonflikten geführt haben. Eine andere Möglichkeit wäre, dass Antivirensoftware versehentlich eine Baugruppe sperrt. Lösung: Löschen Sie den Ordner Temporäre ASP.NET-Dateien von allen Inhalten.

Szenario 4

Beschreibung: Wenn das Batch-Attribut in der Datei web.config auf True gesetzt ist, wird die Verzögerung beseitigt, die durch die Kompilierung verursacht wird, die beim ersten Zugriff auf eine Datei erforderlich ist. ASP.NET kompiliert alle nicht kompilierten Dateien im Batch-Modus vor, was zu Verzögerungen beim ersten Kompilieren der Dateien führt. Durch Deaktivieren der Stapelkompilierung werden möglicherweise maskierte Kompilierungsfehler angezeigt, die möglicherweise in der Anwendung vorhanden sind, jedoch nicht gemeldet werden. Wichtiger für dieses Problem ist jedoch, dass ASP.NET einzelne .aspx / .ascx-Dateien dynamisch in separate Assemblys anstatt in eine einzelne Assembly kompilieren soll. Lösung: Setzen Sie batch = false im Abschnitt in web.config. Dies sollte als vorübergehende Lösung betrachtet werden, da das Festlegen von batch = false im Kompilierungsabschnitt erhebliche Auswirkungen auf die Erstellungszeiten der Anwendung in Visual Studio hat.

Szenario 5

Beschreibung: Durch Ändern der Datei web.config für eine ASP.NET-Anwendung oder Ändern einer Datei im Ordner bin (z. B. Hinzufügen, Löschen oder Umbenennen) wird die AppDomain neu gestartet. In diesem Fall geht der gesamte Sitzungsstatus verloren und zwischengespeicherte Elemente werden beim Neustart der Website aus dem Cache entfernt. Möglicherweise wird das Problem durch einen inkonsistenten Status in der Webanwendung verursacht. Lösung: Lösen Sie einen AppDomain-Neustart aus, indem Sie die Datei web.config berühren (bearbeiten).

Szenario 6

Beschreibung: Sie können den Quellcode im Ordner App_Code speichern und er wird zur Laufzeit automatisch kompiliert. Auf die resultierende Assembly kann jeder andere Code in der Webanwendung zugreifen. Der Ordner App_Code funktioniert daher ähnlich wie der Ordner Bin, außer dass Sie darin Quellcode anstelle von kompiliertem Code speichern können. Die Klasse wird neu kompiliert, wenn sich die Quelldatei ändert. Wenn aufgrund einer veralteten Assembly ein Konflikt auftritt, kann das Problem möglicherweise durch Erzwingen einer Neukompilierung behoben werden. Lösung: Berühren Sie eine Datei in den Ordnern Bin oder App_Code, um eine vollständige Neukompilierung auszulösen.

Question 10

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

<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"/>

Das Sytem.Web.Helperswurde auf 1.0.0.0 anstelle von 3.0.0.0 gezeigt (MVC 3 wird in diesem Projekt verwendet).

Da IIS die Referenz im lokalen Ordner nicht finden konnte, wurde im GAC nach zwei verschiedenen Versionen gesucht. Nachdem IIS auf die richtige Referenz gezeigt hatte, fand es die lokale DLL und verwendete diese, anstatt den GAC zu durchsuchen.

Question 11

Dies kann passieren, wenn derselbe Klassenname in mehreren .aspx.csDateien angegeben wird, dh wenn zwei Seiten mit unterschiedlichem Dateinamen erstellt werden, aber versehentlich denselben Klassennamen haben.

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

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

Während der Erstellung der Webanwendung wird eine Warnung ausgegeben, die Anwendung wird jedoch ausgeführt, nachdem sie veröffentlicht wurde. Die Anwendung funktioniert jedoch nicht mehr und löst die in der OP-Frage erwähnte Ausnahme aus.

Wenn Sie sicherstellen, dass sich zwei Klassennamen nicht überschneiden, wird das Problem behoben.

Question 12

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

Question 13

"Clean Solution" gefolgt von "Rebuild Solution" scheint das Problem ebenfalls zu beheben.

Question 14

Am Ende habe ich geändert, wie auf den MasterType in der Seitenmarkierung verwiesen wird.

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

Siehe hier für Details.

Hoffe das hilft jemandem.

Question 15

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

Question 16

In unserem Fall war der Grund ein Unterschied in den DLL-Versionen von Sites in IIS. Sie werden in IIS untereinander platziert, sodass Sie über eine Subdomain auf die anderen zugreifen können. Es erbt von der ersten web.config, und die Kombination mit der nächsten web.config schlug fehl, da verschiedene Versionen von mvc.dll vorhanden waren.

Question 17

Ich hatte das ähnliche Problem. Dies ist meine Lösung: isolierte Klassen Put , die erfordern Eigenschaft [Build Action]Satz als [Compile]in jedem anderen Ordner als App_Codewie Application_Codeda der App_CodeOrdner wird als separate Baugruppe kompiliert werden, die gleiche Klasse in 2 Baugruppen zusammengestellt hat.

Question 18

Ich hatte das gleiche Problem mit zwei ASCX-Steuerelementen mit demselben Klassennamen:

Control1: <% @ Control Language = "C #" ClassName = " myClassName " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName "AutoEventWireup =" true ...>

Ich habe es behoben, indem ich einfach den Klassennamen umbenannt habe:

Control1: <% @ Control Language = "C #" ClassName = " myClassName1 " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName2 "AutoEventWireup =" true ...>

Question 19

Schließen Sie die Lösung, öffnen Sie sie erneut und überprüfen Sie die Projektreferenzen auf Verdoppelung :

Dies kann passieren, wenn Sie NuGet verwendet und den Referenzspeicherort der DLLs geändert haben. Um dies zu beheben, müssen Sie die Projektdatei manuell bearbeiten und die Einträge entfernen, z.

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

Beachten Sie, dass diese "<Import" -Referenzen an verschiedenen Stellen in der Projektdatei angezeigt werden können.

Question 20

Eine superschnelle und praktische Lösung besteht darin, die unglaubliche Intelligenz von Visual Studio zu missbrauchen, indem vorübergehend auf die Klasse verwiesen wird.

Beispiel:

System.Runtime.CompilerServices.ExtensionAttribute x = null;

Wenn Sie den Cursor über die Linie erstellen oder bewegen, wird der folgende Fehler angezeigt:

'System.Runtime.CompilerServices.ExtensionAttribute' ist in beiden 'C: \ Programme \ Referenzassemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll' vorhanden.

Hier erfahren Sie sofort, welche beiden Quellen den Konflikt verursachen.

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

Ich fand meine im binVerzeichnis, aber es kann an anderer Stelle im Projekt sein.

In der Tat ist dies zu beachten, da das binVerzeichnis möglicherweise nicht als Teil des TFS-Änderungssatzes enthalten ist, kann dies erklären, warum das Einchecken Ihrer Änderungen das Problem für andere Mitglieder Ihres Teams nicht löst.

Question 21

Ich konvertiere eine alte asp.net-Website (Version 1 oder 2) so, dass sie unter .net 4.5 als Webanwendung ausgeführt wird.

Meine Lösung bestand darin, die Ereignisbehandlungsdelegierten der Benutzersteuerung, die das Problem verursacht hatten, 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)
    {

Question 22

Dafür gibt es eine Vielzahl von Gründen. Die meisten der oben genannten gelten für verschiedene Szenarien. Was ich bemerkt habe ist, dass der Fehler NUR auftritt, wenn die Authentifizierung auf etwas anderes als "Keine" eingestellt ist. Zu meinen Testzwecken werde ich dies auslösen und es funktioniert.

Question 23

Ich wurde hier umgeleitet, als ich auf den ersten Google-Treffer klickte, wenn ich auf die Fehler-URL für insbesondere CS0433klickte.

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

Anstatt all die Dinge zu skizzieren, die ich getan habe, um das Problem zu beheben, möchte ich Ihnen sagen, was ich getan habe, um es zu beschädigen. Ich habe die NuGet-Pakete für ein Repo aktualisiert, für das ein Code-Update erforderlich war. Die Pakete waren ziemlich alt (ca. 1 Jahr) und ich habe zunächst nur versucht, sie für ein C # -Projekt zu aktualisieren.

Irgendwann zwischen dem Starten dieses Prozesses und dem Auftreten dieses Fehlers habe ich die Version der C ++ - Projekte in diesem SLN auf das Ziel heruntergestuft 15063. Mir ist auch aufgefallen, dass das C # -Projekt sowohl das TargetPlatformMinVersionals auch das TargetPlatformVersionneu eingestellte hatte10.0.17134.0

Das einzige, was ich tun musste, um es zu "reparieren", war die Änderung TargetPlatformMinVersionauf eine höhere Version als die TargetPlatformMinVersionfür das C # -Projekt. Durch Ändern des C ++ - Projekts auf eine der beiden Versionen wurde das Verhalten nicht geändert. Ich bin mir nicht sicher, warum dies plötzlich nicht mehr funktioniert, aber hoffentlich kann jemand, der ähnlich blockiert ist, mit ähnlichen Strategien aus einer Gurke herauskommen.

Question 24

Zusätzlich zum Versuch der Antwort von 2Toad musste ich Visual Studio schließen und meinen .vs-Ordner löschen. Danach wurde alles richtig gebaut.

Übrigens hat der Fehler, auf den ich gestoßen bin, meinen Temp-Ordner überhaupt nicht angegeben, sondern auf etwas anderes verwiesen, das offensichtlich vom System generiert wurde. Ich habe es versäumt, den spezifischen Fehler zu speichern: \

Question 25

Wenn keine andere Lösung funktioniert hat, benennen Sie einfach die geerbte Klasse dieses Problems um, wodurch die aspx-Datei und die aspx.cs-Datei in einen neuen Namen umgewandelt werden, und erstellen Sie die Lösung neu. dann wird das Problem sicher gelöst. das hat nur bei mir funktioniert.

z.B :

Ändern Sie in der aspx-Datei wie folgt den Namen der geerbten Klasse in Defaultnew

<%@ Page Title="" Language="C#"  MasterPageFile="~/Main.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Defaultnew" %>

Benennen Sie die Klasse in der Datei aspx.cs in dieselbe um wie in der Datei aspx

using System;
using System.Collections.Generic;
using System.Web;

public partial class Defaultnew : System.Web.UI.Page
{

Answer 1

Wenn ich eine Webanwendung von Visual Studio 2008 SP1 über den internen Webserver (nicht IIS) ausführe, wird der oben genannte Fehler angezeigt.

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

Compiler-Fehlermeldung: CS0433: Der Typ 'WebApplication3.Site1' ist in beiden 'c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ root \ aa563bcf \ 59deedc0 \ App_Web_site1.master.cdcab7d2 vorhanden. 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.

Die Quelle der Warnhinweise verweist 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 Webanwendung (keine Website!) Hat eine Default.aspx und eine Site1.Master , keine Abhängigkeiten. Sie sind fast leer, mit einem asp:Labelauf der Seite. Zuvor funktionierte diese Webanwendung einwandfrei. Wenn ich in Default.aspx.cs Verweise auf den Master entferne, läuft alles gut. Der Master hat nur Code.

Es ist tatsächlich eine von vielen kleinen Test-Webanwendungen, bei denen es um Feuer und Vergessen geht, also könnte es mich nicht weniger interessieren. Aber ich hatte das vorher noch nicht gesehen und jetzt bin ich gespannt, was ich tun soll, außer Code in ein neues Projekt zu kopieren (Reinigungslösung hilft nicht).

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

Answer 2

PS: Mein Hauptgedanke ist: Etwas hat das temporäre Verzeichnis durcheinander gebracht, und mein Hauptweg hier draußen ist, das temporäre Verzeichnis einfach von Hand zu entfernen und neu aufzubauen. Noch nicht ausprobiert (würde die "Beweise" entfernen), falls jemand hier einen tieferen Einblick hat.

Abel

Answer 3

Theorie

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

Dieses Problem tritt anscheinend 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 zumindest ein Teil des Inhalts des Bin-Ordners Ihrer Anwendung veraltet ist.

Wenn dieses Problem auftritt, kann das Problem nicht allein durch Löschen des Ordners "Temporäre ASP.NET-Dateien" behoben werden. Das Problem kann nicht gelöst werden, 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. Beim nächsten Zugriff auf Ihre Anwendung werden die neuen Bin-Dateien in den Ordner "Temporäre ASP.NET-Dateien" kopiert.

Lösung

Schließen Sie Visual Studio
Führen Sie einen iisreset durch
Löschen Sie alle Ordner und Dateien im Ordner "Temporäre ASP.NET-Dateien" (auf den Pfad wird in der Fehlermeldung verwiesen).
Löschen Sie die Ordner "obj" und "bin" der betreffenden Anwendung
Starten Sie Visual Studio neu und öffnen Sie die Lösung
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

Answer 4

3

Dieser Beitrag ergänzt deutlich die ursprünglich akzeptierte Antwort. Gute Erklärung und klare Schritte, danke!

Abel

Answer 5

1

@Abel bitte überlegen Sie, dies zur Antwort zu machen. Weil nur das Bereinigen des temporären ASP.NET-Ordners nicht hilft!

Arin Ghazarian

Answer 6

2

Dies ist mir mit einem Nicht-Web-Projekt passiert. Durch einfaches Löschen der Ordner bin und obj wurde das Problem behoben.

Matt H

Answer 7

1

@ArinGhazarian, genau! Ich musste auch die Ordner objund löschen bin, um diesen Fehler zu beheben.

Santosh

Answer 8

Tolle Antwort mit einer tollen Erklärung. Vielen Dank!

Carlos Rodriguez

Answer 9

39

Fahren Sie w3svc herunter und löschen Sie alles aus 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\
Auf IIS-Servern (64 Bit) kann dies ebenfalls auftreten. Suchen:

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

(Ersetzen Sie v4.0.30319 durch die Framework-Version, die Sie verwenden, wenn auf Ihrem Server eine neuere Version vorhanden ist.)

Alex Polkhovsky
quelle

2

Ja, das wird wahrscheinlich funktionieren (siehe meinen eigenen Kommentar oben), aber ich hoffte auf ein bisschen mehr Einblick, woher das kommt und was zu tun ist, um es zu verhindern (oder sogar reproduzierbar zu machen). Ich bin nicht gegen die Lösung von Brute Force, aber bevor ich das tue, möchte ich verstehen, was los ist.

Abel

Das ist mir in der Vergangenheit passiert. Ich glaube, es ist ein Problem mit VS, bei dem es nach einer Debugging-Sitzung oder vor dem Starten einer neuen Sitzung nicht bereinigt wird. Das letzte Mal, dass mir das passiert ist, war vor ein paar Jahren mit VS2005.

Alex Polkhovsky

3

Akzeptierte dies als Antwort, weil es eine Lösung ist. Es erklärt jedoch nicht "warum". Wenn ich eine bessere Lösung oder einen tatsächlichen Grund finde, aktualisiere ich Lymans Antwort oder füge meine eigene hinzu.

Abel

Eigentlich funktioniert diese Antwort bei mir nicht. Mein Projekt hat vor ein paar Wochen gut funktioniert, aber ich habe es heute versucht und zeige das oben genannte Problem. Ich habe die temporären Dateien wie oben angegeben gelöscht (für Windows 7) und das gleiche Problem besteht weiterhin. Ich frage mich immer noch warum ...

Venugopal M

@VenugopalM haben Sie eine andere Lösung gefunden, die obige Lösung hat bei mir nicht

funktioniert

Answer 10

2

Ja, das wird wahrscheinlich funktionieren (siehe meinen eigenen Kommentar oben), aber ich hoffte auf ein bisschen mehr Einblick, woher das kommt und was zu tun ist, um es zu verhindern (oder sogar reproduzierbar zu machen). Ich bin nicht gegen die Lösung von Brute Force, aber bevor ich das tue, möchte ich verstehen, was los ist.

Abel

Answer 11

Das ist mir in der Vergangenheit passiert. Ich glaube, es ist ein Problem mit VS, bei dem es nach einer Debugging-Sitzung oder vor dem Starten einer neuen Sitzung nicht bereinigt wird. Das letzte Mal, dass mir das passiert ist, war vor ein paar Jahren mit VS2005.

Alex Polkhovsky

Answer 12

3

Akzeptierte dies als Antwort, weil es eine Lösung ist. Es erklärt jedoch nicht "warum". Wenn ich eine bessere Lösung oder einen tatsächlichen Grund finde, aktualisiere ich Lymans Antwort oder füge meine eigene hinzu.

Abel

Answer 13

Eigentlich funktioniert diese Antwort bei mir nicht. Mein Projekt hat vor ein paar Wochen gut funktioniert, aber ich habe es heute versucht und zeige das oben genannte Problem. Ich habe die temporären Dateien wie oben angegeben gelöscht (für Windows 7) und das gleiche Problem besteht weiterhin. Ich frage mich immer noch warum ...

Venugopal M

Answer 14

@VenugopalM haben Sie eine andere Lösung gefunden, die obige Lösung hat bei mir nicht

funktioniert

Answer 15

11

Dies kann passieren, wenn Sie CS-Dateien in App_Code ablegen und deren Erstellungsaktion so ändern, dass sie in einem Webanwendungsprojekt kompiliert werden.

Führen Sie entweder die Erstellungsaktion für die CS-Dateien in App_Code als Inhalt aus oder ändern Sie den Namen von App_Code in einen anderen Namen. Ich habe den Namen geändert, da Intellisense keine als Inhalt markierten CS-Dateien repariert.

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

Lilja
quelle

Der von Ihnen bereitgestellte Link war die Lösung für mich. Ich habe alle meine Klassen aus dem Ordner App_Code verschoben und in einen neuen Ordner mit dem Namen Classes verschoben. Benennen Sie dann die Namespaces der Klassen um (Ende des Namespace = .Classes anstelle von .App_Code). Aktualisieren Sie natürlich alle using-Anweisungen und Verweise auf den Ordner App_Code.

krlzlx

Vielen Dank. Das hat mich verrückt gemacht

Sperick

Das hat es auch für mich behoben. Vielen Dank.

JonH

Answer 16

Der von Ihnen bereitgestellte Link war die Lösung für mich. Ich habe alle meine Klassen aus dem Ordner App_Code verschoben und in einen neuen Ordner mit dem Namen Classes verschoben. Benennen Sie dann die Namespaces der Klassen um (Ende des Namespace = .Classes anstelle von .App_Code). Aktualisieren Sie natürlich alle using-Anweisungen und Verweise auf den Ordner App_Code.

krlzlx

Answer 17

Vielen Dank. Das hat mich verrückt gemacht

Sperick

Answer 18

Das hat es auch für mich behoben. Vielen Dank.

JonH

Answer 19

9

Sehen Sie sich das Inherits-Tag aller Ihrer Aspx- und Masterseiten an. Möglicherweise gibt es zwei Teilklassen mit demselben Namen. Ändern Sie eine und kompilieren Sie neu.

Hier noch ein paar Infos:

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

NitroxDM
quelle

Guter Punkt. Der Code von damals wurde neu geschrieben, daher kann ich nicht überprüfen, ob er geholfen hätte, aber für jeden, der diesen Fehler hat, könnte dies definitiv ein guter Hinweis sein, danke für das Teilen.

Abel

Answer 20

Guter Punkt. Der Code von damals wurde neu geschrieben, daher kann ich nicht überprüfen, ob er geholfen hätte, aber für jeden, der diesen Fehler hat, könnte dies definitiv ein guter Hinweis sein, danke für das Teilen.

Abel

Answer 21

Nach all diesen Vorschlägen hatte ich immer noch das Problem. Eine Klasse in App_Code wurde in zwei DLLs kompiliert. So etwas (vereinfacht):

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

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.

Answer 22

4

Das Entfernen der Klassendateien aus dem App_CodeOrdner und das direkte Platzieren unter der Website hat dieses Problem für mich behoben.

Naveen Q.
quelle

3

Ich fürchte, das ist keine Option. Das Platzieren der DLLs direkt unter dem Stammverzeichnis wird von vielen als Sicherheitsrisiko angesehen (App_Code oder bin sind speziell und über IIS / ASP.NET nicht zugänglich, während alle DLLs im Stammverzeichnis einfach heruntergeladen werden können und .NET-Assemblys leicht zerlegt werden können).

Abel

Ich habe die Klasse im Modellordner eines ASP.NET MVC4-Projekts abgelegt, um dies ebenfalls zu beheben.

DShook

Answer 23

3

Ich fürchte, das ist keine Option. Das Platzieren der DLLs direkt unter dem Stammverzeichnis wird von vielen als Sicherheitsrisiko angesehen (App_Code oder bin sind speziell und über IIS / ASP.NET nicht zugänglich, während alle DLLs im Stammverzeichnis einfach heruntergeladen werden können und .NET-Assemblys leicht zerlegt werden können).

Abel

Answer 24

Ich habe die Klasse im Modellordner eines ASP.NET MVC4-Projekts abgelegt, um dies ebenfalls zu beheben.

DShook

Answer 25

4

Dies kann auch passieren, wenn Ihre ASPX-Datei ein doppeltes TagPrefix enthält.

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" %>

Jason Geiger
quelle

1

Dies ist eigentlich kein Problem, Tagprefix kann für alle Steuerelemente gleich sein

Spyros

@Spyros Ich bin anderer Meinung, weil es das Problem für mich behoben hat. Es ist über ein Jahr her und ich erinnere mich nicht an alles, aber es würde sich lohnen, es hier zu lassen, damit andere es lesen können.

Jason Geiger

Diese Antwort hat mein Problem gelöst. Es war seltsam, weil der Fehler nicht immer auftrat, nur nach einigen Bereitstellungen. Wie Spyros glaubte ich nicht, dass dies das Problem lösen würde, ich sah den Zusammenhang nicht. Vielen Dank an Jason Geiger für die Veröffentlichung.

VFein

Für was es wert ist. Die Steuerelemente, die dies verursachten, befanden sich alle im selben Ordner, auf den aus mehreren virtuellen Anwendungen als virtuelles Verzeichnis verwiesen wurde.

VFein

Kratz meinen Kommentar. Der Fehler zeigte nur wieder seinen hässlichen Kopf. Zurück zum Zeichenbrett.

VFein

Answer 26

1

Dies ist eigentlich kein Problem, Tagprefix kann für alle Steuerelemente gleich sein

Spyros

Answer 27

@Spyros Ich bin anderer Meinung, weil es das Problem für mich behoben hat. Es ist über ein Jahr her und ich erinnere mich nicht an alles, aber es würde sich lohnen, es hier zu lassen, damit andere es lesen können.

Jason Geiger

Answer 28

Diese Antwort hat mein Problem gelöst. Es war seltsam, weil der Fehler nicht immer auftrat, nur nach einigen Bereitstellungen. Wie Spyros glaubte ich nicht, dass dies das Problem lösen würde, ich sah den Zusammenhang nicht. Vielen Dank an Jason Geiger für die Veröffentlichung.

VFein

Answer 29

Für was es wert ist. Die Steuerelemente, die dies verursachten, befanden sich alle im selben Ordner, auf den aus mehreren virtuellen Anwendungen als virtuelles Verzeichnis verwiesen wurde.

VFein

Answer 30

Kratz meinen Kommentar. Der Fehler zeigte nur wieder seinen hässlichen Kopf. Zurück zum Zeichenbrett.

VFein

Answer 31

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

Beim Erstellen eines ASP.NET-Projekts mit Visual Studio wird möglicherweise zufällig eine Fehlermeldung angezeigt, die der folgenden ähnelt:

Compiler-Fehlermeldung: CS0433: Der Typ 'ASP.summary_common_controls_notes_ascx' ist in beiden 'c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ Book_Details \ abc12345 \ def8910 \ App_Web_msftx123.dll' und 'vorhanden. c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Temporäre ASP.NET-Dateien \ Book_Details \ abc12345 \ def8910 \ App_Web_msfty456.dll '

Beschreibung: Beim Kompilieren einer Ressource, die zur Bearbeitung dieser Anforderung erforderlich ist, ist ein Fehler aufgetreten. Bitte überprüfen Sie die folgenden spezifischen Fehlerdetails und ändern Sie Ihren Quellcode entsprechend.

Quellfehler: Zeile 100: Zeile 101:
Neue Notizen Zeile 102:
Zeile 103:
1450 Zeile 104:

Zusammenfassung.

Quelldatei: d: \ http \ post \ publisher \ default.aspx Zeile: 102

Häufige Szenarien, in denen dieser Fehler auftreten kann, werden unten erläutert

Szenario 1

Beschreibung: Eine häufige Ursache ist, dass sich zwei Assemblys im selben Ordner für Webanwendungsbereiche befinden, die zwei Klassendefinitionen enthalten, aber denselben Klassennamen haben. Dies kann passieren, wenn mehr als eine Default.aspx in einer einzelnen Assembly kompiliert wurde. Dies tritt normalerweise auf, wenn sowohl die Masterseite (Default.master) als auch die Standard-ASPX-Seite (Default.aspx) eine _Default-Klasse deklarieren. Lösung: Ändern Sie den Klassennamen der Masterseite (in den meisten Fällen von _Default) und erstellen Sie das Projekt neu. Es ist wichtig, Namenskonflikte zwischen Klassen zu lösen.

Szenario 2

Beschreibung: Die Referenzpfade in Visual Studio werden verwendet, um den Ordnerpfad für Assemblyreferenzen anzugeben, die vom Projekt verwendet werden. Möglicherweise enthält der Pfad eine Assembly, die denselben Klassennamen enthält. Möglicherweise werden derselben Assembly mehrere Verweise hinzugefügt (möglicherweise eine andere Version oder ein anderer Name), was zu einem Namenskonflikt führt.
Lösung: Entfernen Sie die alte Versionsreferenz. Klicken Sie dazu in Visual Studio mit der rechten Maustaste auf Ihre Website und überprüfen Sie die "Verweise" in den Eigenschaften.

Szenario 3

Beschreibung: Wenn eine ASP.NET-Webanwendung kompiliert wird, wird der kompilierte Code standardmäßig im Ordner Temporäre ASP.NET-Dateien abgelegt. Standardmäßig werden die Zugriffsberechtigungen an das lokale ASP.NET-Benutzerkonto vergeben, das über die für den Zugriff auf kompilierten Code erforderlichen Vertrauensstellungen verfügt. Es ist möglich, dass einige Änderungen an den Standardberechtigungen zu Versionskonflikten geführt haben. Eine andere Möglichkeit wäre, dass Antivirensoftware versehentlich eine Baugruppe sperrt. Lösung: Löschen Sie den Ordner Temporäre ASP.NET-Dateien von allen Inhalten.

Szenario 4

Beschreibung: Wenn das Batch-Attribut in der Datei web.config auf True gesetzt ist, wird die Verzögerung beseitigt, die durch die Kompilierung verursacht wird, die beim ersten Zugriff auf eine Datei erforderlich ist. ASP.NET kompiliert alle nicht kompilierten Dateien im Batch-Modus vor, was zu Verzögerungen beim ersten Kompilieren der Dateien führt. Durch Deaktivieren der Stapelkompilierung werden möglicherweise maskierte Kompilierungsfehler angezeigt, die möglicherweise in der Anwendung vorhanden sind, jedoch nicht gemeldet werden. Wichtiger für dieses Problem ist jedoch, dass ASP.NET einzelne .aspx / .ascx-Dateien dynamisch in separate Assemblys anstatt in eine einzelne Assembly kompilieren soll. Lösung: Setzen Sie batch = false im Abschnitt in web.config. Dies sollte als vorübergehende Lösung betrachtet werden, da das Festlegen von batch = false im Kompilierungsabschnitt erhebliche Auswirkungen auf die Erstellungszeiten der Anwendung in Visual Studio hat.

Szenario 5

Beschreibung: Durch Ändern der Datei web.config für eine ASP.NET-Anwendung oder Ändern einer Datei im Ordner bin (z. B. Hinzufügen, Löschen oder Umbenennen) wird die AppDomain neu gestartet. In diesem Fall geht der gesamte Sitzungsstatus verloren und zwischengespeicherte Elemente werden beim Neustart der Website aus dem Cache entfernt. Möglicherweise wird das Problem durch einen inkonsistenten Status in der Webanwendung verursacht. Lösung: Lösen Sie einen AppDomain-Neustart aus, indem Sie die Datei web.config berühren (bearbeiten).

Szenario 6

Beschreibung: Sie können den Quellcode im Ordner App_Code speichern und er wird zur Laufzeit automatisch kompiliert. Auf die resultierende Assembly kann jeder andere Code in der Webanwendung zugreifen. Der Ordner App_Code funktioniert daher ähnlich wie der Ordner Bin, außer dass Sie darin Quellcode anstelle von kompiliertem Code speichern können. Die Klasse wird neu kompiliert, wenn sich die Quelldatei ändert. Wenn aufgrund einer veralteten Assembly ein Konflikt auftritt, kann das Problem möglicherweise durch Erzwingen einer Neukompilierung behoben werden. Lösung: Berühren Sie eine Datei in den Ordnern Bin oder App_Code, um eine vollständige Neukompilierung auszulösen.

Answer 32

Als Faustregel beginne ich normalerweise mit den einfachsten angebotenen Lösungen. Folgendes aus Szenario 6 oben hat das Problem für mich behoben: "Lösung: Berühren Sie eine Datei in den Ordnern Bin oder App_Code, um eine vollständige Neukompilierung auszulösen."

cjo30080

Answer 33

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

<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"/>

Das Sytem.Web.Helperswurde auf 1.0.0.0 anstelle von 3.0.0.0 gezeigt (MVC 3 wird in diesem Projekt verwendet).

Da IIS die Referenz im lokalen Ordner nicht finden konnte, wurde im GAC nach zwei verschiedenen Versionen gesucht. Nachdem IIS auf die richtige Referenz gezeigt hatte, fand es die lokale DLL und verwendete diese, anstatt den GAC zu durchsuchen.

Answer 34

2

Dies kann passieren, wenn derselbe Klassenname in mehreren .aspx.csDateien angegeben wird, dh wenn zwei Seiten mit unterschiedlichem Dateinamen erstellt werden, aber versehentlich denselben Klassennamen haben.

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

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

Während der Erstellung der Webanwendung wird eine Warnung ausgegeben, die Anwendung wird jedoch ausgeführt, nachdem sie veröffentlicht wurde. Die Anwendung funktioniert jedoch nicht mehr und löst die in der OP-Frage erwähnte Ausnahme aus.

Wenn Sie sicherstellen, dass sich zwei Klassennamen nicht überschneiden, wird das Problem behoben.

Deepak
quelle

Tx für die Prüfung. In Ihrem Beispiel verwenden Sie partial classjedoch eine übliche Methode (die einzige Möglichkeit), um eine Klasse auf mehrere Dateien aufzuteilen. In diesem Fall müssen Sie denselben Namen verwenden.

Abel

Dies kam meinem Problem auf einer Website (nicht einer Anwendung) sehr nahe. Das Löschen der temporären Ordner, das Verschieben von Objekten aus App_Code und andere Vorschläge funktionierten nicht. Erst als ich mir die .cs-CodeBehind-Datei für meine Masterseite ansah, bemerkte ich, dass der Dateiname nicht mit dem Klassennamen übereinstimmte, der immer noch der Standard war MasterPage. Nachdem ich im Kontextmenü eine Umbenennung der Klasse vorgenommen hatte (damit auch alle Referenzen aktualisiert wurden), verschwand der Fehler schließlich. Ich kann nur vermuten, dass meine Masterseite mit der System.Web.UI.MasterPageKlasse in Konflikt stand .

Andrew S

Answer 35

Tx für die Prüfung. In Ihrem Beispiel verwenden Sie partial classjedoch eine übliche Methode (die einzige Möglichkeit), um eine Klasse auf mehrere Dateien aufzuteilen. In diesem Fall müssen Sie denselben Namen verwenden.

Abel

Answer 36

Dies kam meinem Problem auf einer Website (nicht einer Anwendung) sehr nahe. Das Löschen der temporären Ordner, das Verschieben von Objekten aus App_Code und andere Vorschläge funktionierten nicht. Erst als ich mir die .cs-CodeBehind-Datei für meine Masterseite ansah, bemerkte ich, dass der Dateiname nicht mit dem Klassennamen übereinstimmte, der immer noch der Standard war MasterPage. Nachdem ich im Kontextmenü eine Umbenennung der Klasse vorgenommen hatte (damit auch alle Referenzen aktualisiert wurden), verschwand der Fehler schließlich. Ich kann nur vermuten, dass meine Masterseite mit der System.Web.UI.MasterPageKlasse in Konflikt stand .

Andrew S

Answer 37

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

Answer 38

1

"Clean Solution" gefolgt von "Rebuild Solution" scheint das Problem ebenfalls zu beheben.

römisch
quelle

Wie ich in der Frage erklärt habe, hat das Reinigen der Lösung zumindest in meiner Situation nicht geholfen. Der Grund, warum es nicht hilft, ist, dass der Fehler durch temporäre ASP.NET-Dateien (wie in der 1. und 2. Antwort erläutert) verursacht wird, die beim Ausführen von "Clean Solution" nicht bereinigt werden.

Abel

Answer 39

Wie ich in der Frage erklärt habe, hat das Reinigen der Lösung zumindest in meiner Situation nicht geholfen. Der Grund, warum es nicht hilft, ist, dass der Fehler durch temporäre ASP.NET-Dateien (wie in der 1. und 2. Antwort erläutert) verursacht wird, die beim Ausführen von "Clean Solution" nicht bereinigt werden.

Abel

Answer 40

Am Ende habe ich geändert, wie auf den MasterType in der Seitenmarkierung verwiesen wird.

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

Siehe hier für Details.

Hoffe das hilft jemandem.

Answer 41

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

Answer 42

In unserem Fall war der Grund ein Unterschied in den DLL-Versionen von Sites in IIS. Sie werden in IIS untereinander platziert, sodass Sie über eine Subdomain auf die anderen zugreifen können. Es erbt von der ersten web.config, und die Kombination mit der nächsten web.config schlug fehl, da verschiedene Versionen von mvc.dll vorhanden waren.

Answer 43

Ich hatte das ähnliche Problem. Dies ist meine Lösung: isolierte Klassen Put , die erfordern Eigenschaft [Build Action]Satz als [Compile]in jedem anderen Ordner als App_Codewie Application_Codeda der App_CodeOrdner wird als separate Baugruppe kompiliert werden, die gleiche Klasse in 2 Baugruppen zusammengestellt hat.

Answer 44

Ich hatte das gleiche Problem mit zwei ASCX-Steuerelementen mit demselben Klassennamen:

Control1: <% @ Control Language = "C #" ClassName = " myClassName " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName "AutoEventWireup =" true ...>

Ich habe es behoben, indem ich einfach den Klassennamen umbenannt habe:

Control1: <% @ Control Language = "C #" ClassName = " myClassName1 " AutoEventWireup = "true ...> Control2: <% @ Control Language =" C # "ClassName =" myClassName2 "AutoEventWireup =" true ...>

Answer 45

Schließen Sie die Lösung, öffnen Sie sie erneut und überprüfen Sie die Projektreferenzen auf Verdoppelung :

Dies kann passieren, wenn Sie NuGet verwendet und den Referenzspeicherort der DLLs geändert haben. Um dies zu beheben, müssen Sie die Projektdatei manuell bearbeiten und die Einträge entfernen, z.

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

Beachten Sie, dass diese "<Import" -Referenzen an verschiedenen Stellen in der Projektdatei angezeigt werden können.

Answer 46

Eine superschnelle und praktische Lösung besteht darin, die unglaubliche Intelligenz von Visual Studio zu missbrauchen, indem vorübergehend auf die Klasse verwiesen wird.

Beispiel:

System.Runtime.CompilerServices.ExtensionAttribute x = null;

Wenn Sie den Cursor über die Linie erstellen oder bewegen, wird der folgende Fehler angezeigt:

'System.Runtime.CompilerServices.ExtensionAttribute' ist in beiden 'C: \ Programme \ Referenzassemblies \ Microsoft \ Framework \ v3.5 \ System.Core.dll' vorhanden.

Hier erfahren Sie sofort, welche beiden Quellen den Konflikt verursachen.

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

Ich fand meine im binVerzeichnis, aber es kann an anderer Stelle im Projekt sein.

In der Tat ist dies zu beachten, da das binVerzeichnis möglicherweise nicht als Teil des TFS-Änderungssatzes enthalten ist, kann dies erklären, warum das Einchecken Ihrer Änderungen das Problem für andere Mitglieder Ihres Teams nicht löst.

Answer 47

Ich konvertiere eine alte asp.net-Website (Version 1 oder 2) so, dass sie unter .net 4.5 als Webanwendung ausgeführt wird.

Meine Lösung bestand darin, die Ereignisbehandlungsdelegierten der Benutzersteuerung, die das Problem verursacht hatten, 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)
    {

Answer 48

Dafür gibt es eine Vielzahl von Gründen. Die meisten der oben genannten gelten für verschiedene Szenarien. Was ich bemerkt habe ist, dass der Fehler NUR auftritt, wenn die Authentifizierung auf etwas anderes als "Keine" eingestellt ist. Zu meinen Testzwecken werde ich dies auslösen und es funktioniert.

Answer 49

Ich wurde hier umgeleitet, als ich auf den ersten Google-Treffer klickte, wenn ich auf die Fehler-URL für insbesondere CS0433klickte.

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

Anstatt all die Dinge zu skizzieren, die ich getan habe, um das Problem zu beheben, möchte ich Ihnen sagen, was ich getan habe, um es zu beschädigen. Ich habe die NuGet-Pakete für ein Repo aktualisiert, für das ein Code-Update erforderlich war. Die Pakete waren ziemlich alt (ca. 1 Jahr) und ich habe zunächst nur versucht, sie für ein C # -Projekt zu aktualisieren.

Irgendwann zwischen dem Starten dieses Prozesses und dem Auftreten dieses Fehlers habe ich die Version der C ++ - Projekte in diesem SLN auf das Ziel heruntergestuft 15063. Mir ist auch aufgefallen, dass das C # -Projekt sowohl das TargetPlatformMinVersionals auch das TargetPlatformVersionneu eingestellte hatte10.0.17134.0

Das einzige, was ich tun musste, um es zu "reparieren", war die Änderung TargetPlatformMinVersionauf eine höhere Version als die TargetPlatformMinVersionfür das C # -Projekt. Durch Ändern des C ++ - Projekts auf eine der beiden Versionen wurde das Verhalten nicht geändert. Ich bin mir nicht sicher, warum dies plötzlich nicht mehr funktioniert, aber hoffentlich kann jemand, der ähnlich blockiert ist, mit ähnlichen Strategien aus einer Gurke herauskommen.

Answer 50

Zusätzlich zum Versuch der Antwort von 2Toad musste ich Visual Studio schließen und meinen .vs-Ordner löschen. Danach wurde alles richtig gebaut.

Übrigens hat der Fehler, auf den ich gestoßen bin, meinen Temp-Ordner überhaupt nicht angegeben, sondern auf etwas anderes verwiesen, das offensichtlich vom System generiert wurde. Ich habe es versäumt, den spezifischen Fehler zu speichern: \

Answer 51

Wenn keine andere Lösung funktioniert hat, benennen Sie einfach die geerbte Klasse dieses Problems um, wodurch die aspx-Datei und die aspx.cs-Datei in einen neuen Namen umgewandelt werden, und erstellen Sie die Lösung neu. dann wird das Problem sicher gelöst. das hat nur bei mir funktioniert.

z.B :

Ändern Sie in der aspx-Datei wie folgt den Namen der geerbten Klasse in Defaultnew

<%@ Page Title="" Language="C#"  MasterPageFile="~/Main.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="Defaultnew" %>

Benennen Sie die Klasse in der Datei aspx.cs in dieselbe um wie in der Datei aspx

using System;
using System.Collections.Generic;
using System.Web;

public partial class Defaultnew : System.Web.UI.Page
{

Woher kommt der Fehler CS0433 "Typ 'X' existiert bereits in A.dll und B.dll"?

Antworten: