Kompilieren Sie den Fehler CS0433 auf der vorkompilierten ASP.NET 2.0-Site

8

Ich erhalte diesen Fehler immer wieder, wenn ich den Debugger starte, um meine Site zu debuggen. Ich verwende die Telerik-Steuerelemente und normalerweise ist der Fehler in meiner Tableiste. Hier ist ein Beispiel für den Fehler, den ich gerade sehe:

%Vor%

Die Sache, die mich am meisten stört, ist, wenn ich einfach weiterhin F5 drücke, wird die Seite aktualisiert und funktioniert wie es sollte. Manchmal dauert es einige Aktualisierungen, andere schnell. Ich konnte keine Lösung im Internet finden, da die meisten Leute mit diesem Fehler von VS2005 auf Web Application upgraden, und daher scheint der Fix "Entfernen Sie Ihr app_code-Verzeichnis und ändern Sie die CodeFile = zu CodeBehind = Aber der CodeBehind ist alt und wird nicht mehr benutzt.

In diesem Fall erhalte ich den Fehler auf meiner Registerkarte "Allgemein", aber dies kann bei jedem meiner Benutzersteuerelemente passieren, wenn dies geschieht.

Hat jemand anderes dies mit vorkompilierten Seiten gesehen? Ich verwende VS2008 SP1.

Der andere Effekt, den ich gesehen habe, ist, wenn ich ein GridView-Setup mit einer Datenquelle habe und die Datenquelle sich ändert, aber die Seite erst nach mehreren anderen Operationen aktualisiert wird, dann sind alle Daten auf einmal ausgefüllt ... Das lässt mich denken, dass es ein Cache-Problem oder eine Kompilierzeit, eine Zeitüberschreitung oder etwas anderes gibt ...

Ich benutze eine site.master-Seite und habe die @ Page und @ Master-Direktiven überprüft ... Nur zum Zweck des Arguments, hier sind die Compiler-Optionen, die es verwendet ...

%Vor%

Hat jemand Ideen, wo ich überhaupt anfangen kann?

    
LarryF 13.01.2009, 20:31
quelle

10 Antworten

7

Cassini Instanzen wie oben zu töten, funktionierte nicht für mich. ScottGu hat über dieses Problem berichtet

Das Attribut charge="false" im Kompilierungsabschnitt von web.config wurde für mich verwendet.

%Vor%
  

Dies teilt ASP.NET dynamisch mit   Kompilieren Sie einzelne .aspx / .ascx-Dateien   in separate Baugruppen. Dies vermeidet   das Rundschreiben Frage, dass   löst die Ausnahme aus.

    
Justin Moore 20.05.2010, 22:47
quelle
1

Für mich schließt das Schließen der IDE, das Schließen der Website (IIS oder Cassini), das Löschen aller temporären asp.net-Dateien, das Starten der IDE und das Ausführen einer vollständigen Kompilierung den Trick.

    
domus.vita 14.01.2009 13:42
quelle
1

in IIS müssen Sie es neu starten, indem Sie die Eingabeaufforderung öffnen und iisreset eingeben und dann die Eingabetaste drücken. Wenn Sie jedoch den Build in Visual Studio-Webserver (Cassini) verwenden, wird das Ihr Problem nicht lösen. Sie können alle laufenden Cassini-Instanzen beenden, indem Sie (genau so, weil Groß- / Kleinschreibung beachten) eingeben: taskkill /f /im "WebDev.WebServer.exe" und drücken Sie die Eingabetaste. Sie sehen dann die folgende Nachricht: SUCCESS: The Process "WebDev.WebServer.EXE" with PID <some #> has been terminated.

    
mknopf 02.03.2009 16:18
quelle
1

Wenn Sie VS2008 und eine WEB-Anwendung (nicht WEB-Site) haben, können Sie nicht das Verzeichnis App_Code haben (Sie müssen alle Dateien daraus entfernen und in den Root-Ordner verschieben) und den Projektordner löschen ( App_Code). Jede Datei, die Sie in App_Code haben, wird während DEBUG / Publish kompiliert. - Das hat mein Problem mit CS0433 gelöst.

    
CyNETT 15.12.2010 14:23
quelle
1

Ich habe diesen Fehler kürzlich behoben. Die Ursache liegt darin, dass einige Dateien oder Klassen mehr als einmal im Projekt deklariert sind. In meinem Fall

%Vor%

weil es in meinem Projekt zwei Ordner gibt, die die Datei ucManageNews.ascx enthalten

    
dangle1107 08.12.2011 00:28
quelle
0

Die Ursache könnte sein, dass einige andere DLLs, auf die Sie verweisen, auf die ältere / neuere Version der angegebenen Assembly verweisen. Daher verweisen verschiedene Teile der App auf verschiedene Versionen der Assembly. Ich bin auf ein Problem wie dieses gestoßen. Um es zu lösen, zwang ich die App, die neue Version zu verwenden:

Ich habe alle meine Referenzen in der web.config geändert, um auf die neuere Version zu verweisen. In meinem Fall war es die System.Web.Extensions-Assembly, die Probleme verursachte. Ich habe alle von 1.0.60125.0 zu 3.5.0.0

geändert

Als nächstes Ich habe diese Zeilen zu meinem web.config hinzugefügt , das Ihrer Anwendung im Grunde sagt, dass sie alle Verweise auf die alte Version der Assembly an die neue weiterleiten soll:

%Vor%

Ich habe diese Lösung nicht gefunden, aber ich habe sie irgendwo gefunden, an die ich mich nicht erinnern kann. Ich glaube aber nicht, dass ich jemals eine Erklärung dafür gefunden habe, warum dies auch passiert!

    
John Bubriski 13.02.2009 14:45
quelle
0

Ich hatte gerade dieses Problem. Es stellt sich heraus, dass ich versehentlich Dateien von einem Projekt in ein anderes gezogen habe, was ein Duplikat erzeugte. Es hat eine Weile gedauert, bis ich das Problem gefunden habe, weil die Dateien im Ordner Eigenschaften verborgen waren (in dem ich nie nachschaue).

In jedem Fall half mir die Lösung des Problems, in die Datei zu gehen, die den Fehler ausgelöst hat, indem ich auf die fehlerhafte Zeile klickte und zur Definition ging. Wenn Sie in der Definition sind, können Sie sehen, welche physische Datei Sie betrachten. Wenn es nicht das ist, was es sein soll, dann hast du dein Problem gefunden.

Ich weiß, dass das trivial ist, aber es hat mich ungefähr 1 Stunde Zeit verschwendet, also hoffe, dass diese Information für jeden nützlich ist.

    
niaher 21.11.2009 06:51
quelle
0

Um diesen Fehler zu beheben, ist es ziemlich einfach, erfordert aber einige selten verwendete Deklarationen (ein schwerer Teil war das Durchgraben der richtigen Dokumentation;).

Siehe ECMA-334 , Abschnitt 16.3 " Externe Alias-Anweisungen "

Wenn Sie "Ihre" Quelle kontrollieren und zu einer anderen Assembly "ihre" Binärdatei verknüpfen, können Sie die Namespace- / Typspezifizierer (zB BEIDE ) nicht ändern (oder nicht ändern) von Ihnen deklarieren System ). Ich habe in letzter Zeit tatsächlich eine Menge davon erlebt, mit all den Beta / Alpha / Version Updates für die CLR / DLR, MS hat viel in ihren veröffentlichten Namespaces gestampft.

Wenn Sie die Assembly "ihre" importieren, wird der Compiler normalerweise den globalen (reservierten) Namespace einrichten. In MSVC gehen Sie zu Eigenschaften in der Assembly-Referenz, gehen Sie zu der Stelle, wo es heißt " Aliase ", Sie können dann einen neuen Namen angeben, anderen als global. Oder eigentlich ein paar Namen.

Nehmen wir an, Sie verwenden den imaginären Namen " global2 ".

Sie gehen dann zu Ihren Quelldateien und bei TOP vor alle Namespace-Deklarationen, die Sie platzieren;

%Vor%

Ihr Code kann dann die Typen von global2 verwenden, wie "Int32" oder was auch immer, Sie können es immer noch umbenennen über;

%Vor%     
RandomNickName42 31.05.2009 20:54
quelle
0

Übrigens, CodeBehind ist nicht alt und wird nicht benutzt!

CodeBehind= ist für Seiten in der Web Application (mit .Designer.cs files) und CodeFile= ist für die Seite in der Website (dynamisch kompilierte Assemblies also ohne .Designer.cs files)

    
abatishchev 20.05.2010 22:51
quelle
0

Ich hatte dieses Problem heute mit einem Web-Benutzer-Steuerelement, aber entdeckte, dass die Änderung von CodeBehind="..." zu Src="..." die Ursache des Fehlers ist. [link] http://stevenoderayi.blogspot.com/2011/04/resolved-cs0433-type-user-control.html [/ link]

    
Steven 02.04.2011 13:00
quelle