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

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.

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

1. Schließen Sie Visual Studio
2. Führen Sie einen iisreset durch
3. Löschen Sie alle Ordner und Dateien im Ordner "Temporäre ASP.NET-Dateien" (auf den 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 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.)

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

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

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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: \

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
{