Oft, wenn Sie Änderungen an einem VS2008 ASP.net Projekt vornehmen, erhalten wir eine Nachricht wie:Warum erscheint die Meldung BC30560 'mymodule_ascx' mehrdeutig im Namespace 'ASP' kommt manchmal auf, dann geh weg?
BC30560: 'mymodule_ascx' ist mehrdeutig im Namespace 'ASP'.
Dies geht nach einer Neukompilierung oder manchmal nur 10 Sekunden warten und aktualisieren Sie die Seite.
Jeder Weg, um es loszuwerden?
Eine andere Möglichkeit:
Schien etwas Erfolg zu haben, mit wechselnden
src="mycontrol.ascx.cs"
zu
CodeBehind="mycontrol.ascx.cs"
Früher hatte ich dieses Problem manchmal auch. Wenn ich mich richtig erinnere war es durch so etwas wie die folgenden Ursachen haben:
<%@ Page Inherits="_Default" %>
oder vielleicht
<%@ Page ClassName="_Default" %>
Oder so ähnlich. Ich bin mir nicht 100% sicher, welches Attribut es war (es ist eine Weile her).
Aber suchen Sie in Ihrer Page-Direktive nach etwas wie _Default und ersetzen Sie sie durch tatsächliche Klassennamen in all Ihren Dateien. Aus irgendeinem Grund interpretiert ASP.Net den _Default nicht immer korrekt, was zu mehrdeutigen temporären Referenzen führt.
Ähnlich wie bei den beiden vorherigen Antworten, werden Sie höchstwahrscheinlich habe eine kopierte und kopierte Kopie einer bestehenden Seite in die gleiche Site, und diese enthält dann die gleichen @ Page-Direktiven, die zu einer Kollision von Funktionen führen werden (insbesondere weil alles in .Net standardmäßig auf Partial Classes verweist). Dieses kleine Juwel hat mich nur allzu oft gebissen.
Aktualisieren Sie einfach die "Inherits", um auf etwas Bestimmtes zu Ihrer Seite zu zeigen (dh Ihr Seitenname wird mit einem Unterstrich vorangestellt - da es häufiger als nicht garantiert eindeutig ist) und sichergestellt, dass Sie Port haben ‚t hat zwei öffentliche Teilklassen gleich in verschiedenen Code-Behind-Dateien mit dem Namen (sonst Page_Load in _Default [default.aspx], wird mit Page_Load in _Default kollidieren [Kopie default.aspx])
ich löse gerade dieses Problem mit der Hilfe folgenden Link: http://www.netomatix.com/development/usercontrols2.aspx
Kurz gesagt heißt Ihre Klasse MyModule. Wenn Sie jedoch die ClassName-Eigenschaft in der @Control-Direktive nicht angeben, kann der Compiler _ascx an die Klasse des Steuerelements anhängen, was zu MyModule_ascx führt. Da die Seite MyModule_ascx nicht finden kann, explodiert sie in Ihrem Gesicht. Sie müssen es explizit dem Klassennamen mitteilen ...
<%@ Control Language="vb" AutoEventWireup="false" CodeBehind="MyModule.ascx.vb" ClassName="MyModule" %>
Ich habe gerade dies erlitten. Dinge, die gut funktionierten und monatelang unberührt waren, fingen nach einigen nicht zusammenhängenden Updates zufällig an zu scheitern. Ich würde neu kompilieren und das Problem würde verschwinden, nur um wieder woanders zu erscheinen.
Ich habe es durch das Löschen des ASP.NET-temporären Ordners, z.C: \ Windows \ Microsoft.NET \ Framework \ v2.0.xxxxx \ Temporäre ASP.NET-Dateien. Dies erforderte einen IIS-Neustart, um es wirklich zu bereinigen.
Update: Ich versuchte tempDirectory="e:\someotherfolder" zum compilation Element der web.config das Hinzufügen und das scheint einen gewissen Erfolg gehabt zu haben. Auch hinzugefügt batch="false" aber nicht sicher, ob das eine Wirkung hatte.
Ich bin kürzlich auf dieses Problem gestoßen und es geschah nur auf einem Server, obwohl alle denselben Code hatten. Ich untersuchte das Problem gründlich, um sicherzustellen, dass andere Benutzersteuerelemente mit kollidierenden Namen vorhanden waren, temporäre Dateien gelöscht wurden usw.
Das einzige, was die Probleme löste (es scheint dauerhaft) ist die Änderung des Batch-Attributs des Kompilierungselements in der web.config falsch, wie auf dem folgenden Link vorgeschlagen:
http://personalinertia.blogspot.com/2007/06/there-bug-in-compiler.html
<compilation debug="true" batch="false">
ich glaube fest daran, dass dies in der Tat ist ein Fehler in dem Compiler als auf dieser Website vorgeschlagen.
IMO sollte dies die akzeptierte Lösung sein. die aktuell akzeptierte Lösung hat den Fehler für mich nicht gelöst (und, angesichts der Anzahl der Upvotes hier, auch für andere) – dlatikay
Nichts auf dieser Seite funktionierte für mich außer dieser Antwort. Diese Frage sollte aktualisiert werden und jemand sollte dies zur akzeptierten Antwort machen. Es würde den Leuten viel Zeit ersparen, falsche Antworten zu finden. – Andy
Für mich war die Wirkung dieses Attributs, dass das Projekt in VS erstellt wurde, aber immer noch den gleichen Fehler beim Ausführen in IIS warf. – ajeh
Auch lief dies mit MasterPages auf Projekte, die ursprünglich .net 1.1 und 2.0 Projekte und später konvertiert wurden. In beiden Fällen referenzierte die @ MasterType-Direktive den virtuellen Pfad. Ich wechselte zu <% @ MasterType TypeName = "MasterPages_MasterPage"%>, löschte die Lösung und das Problem ging weg. HTH
Try web.config gesetzt Batch auf false
<compilation batch="false">
</compilation>
Für mich ist dieser Fehler war eine falsche Fährte zu ändern. In der Realität hatte eine der Benutzersteuerelementen Fehler, die durch .NET 2., 0 bis 4.5 Migration verursacht wurden, die im Code behoben werden musste, aber VS warf diese irreführenden Fehlermeldungen. Nach mehreren Versuchen, die Projekte zu aktualisieren, fing es schließlich an, die tatsächlichen Codezeilen zu aktualisieren, aber ich weiß nicht, wie ich dies nach Stunden der Frustration und fruchtlosen Versuche, Lösungen aus dem ganzen Internet anzuwenden, reproduzieren kann.
Das hat den Trick für mich getan. Vielen Dank! – Anthony
Ich hatte das gleiche Problem und nutzte dies als Fix. Ich kann nicht bestätigen, ob es funktioniert, da das Problem zufällig auftritt, aber es scheint die vernünftigste Erklärung dafür zu sein, warum ich diese Fehler erhalten habe. Vielen Dank!! –