Das Erstellen eines ASP.NET Projekts in Visual Studio führt zu einer Compilerfehlermeldung CS0433

Originalversion des Produkts:   Visual C++
Ursprüngliche KB-Nummer:   2028526

Zusammenfassung

Beim Erstellen eines ASP.NET Projekts mithilfe von Microsoft Visual Studio wird möglicherweise nach dem Zufallsprinzip eine Fehlermeldung wie die folgende angezeigt:

Compilerfehlermeldung: CS0433: Der Typ "ASP.summary_common_controls_notes_ascx" ist sowohl in "c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msftx123.dll" als auch in "c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\Book_Details\abc12345\def8910\App_Web_msfty456.dll" vorhanden.

Beschreibung: Fehler bei der Kompilierung einer Ressource, die für die Wartung dieser Anforderung erforderlich ist. Bitte überprüfen Sie die folgenden spezifischen Fehlerdetails, und ändern Sie Ihren Quellcode entsprechend.

Quellfehler: Zeile 100: </div>

Zeile 101: <h3 class="entry">Neue Notizen</h3>

Zeile 102: <bni:details id="details" runat="server" />

Linie 103: <span class="RedZone">1450</span>

Zeile 104: <p>Zusammenfassung.</p>

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

Häufige Szenarien, in denen dieser Fehler auftreten kann, werden in den folgenden Abschnitten erläutert.

Szenario 1: Zwei Assemblys im selben Containerordner

Beschreibung: Eine häufige Ursache für diesen Fehler ist, wenn sich zwei Assemblys im selben Webanwendungscontainerordner befinden, die zwei Klassendefinitionen enthalten, aber denselben Klassennamen aufweisen. Dies kann passieren, wenn mehrere Default.aspx zu einer einzigen Assembly kompiliert wurden. In der Regel tritt dies auf, wenn die Gestaltungsvorlage (Default.master) und die Standard-ASPX-Seite (Default.aspx) beide eine _Standardklasse deklarieren.

Lösung: Ändern Sie den Klassennamen der Gestaltungsvorlage (in den meisten Fällen von _Standard), und erstellen Sie das Projekt neu. Es ist wichtig, alle Namenskonflikte zwischen Klassen zu lösen.

Szenario 2: Mehrere Verweise auf dieselbe Assembly

Beschreibung: Die Referenzpfade in Visual Studio wird verwendet, um den Ordnerpfad für Assemblyverweise anzugeben, die vom Projekt verwendet werden. Es ist möglich, dass der Pfad eine Assembly enthält und dass die Assembly denselben Klassennamen enthält. Möglicherweise gibt es mehrere Verweise, die derselben Assembly hinzugefügt wurden (möglicherweise anders in Version oder Name), was zu einem Namenskonflikt führt.

Lösung: Entfernen Sie den Verweis auf die alte Version. Klicken Sie in Visual Studio mit der rechten Maustaste auf Ihre Website, und überprüfen Sie die Verweise in den Eigenschaften.

Szenario 3: Änderungen an Standardberechtigungen

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 dem ASP.NET lokalen Benutzerkontos erteilt. Das Konto verfügt über die berechtigungen mit hoher Vertrauenswürdigkeit, die für den Zugriff auf kompilierten Code erforderlich sind. Es ist möglich, dass es einige Änderungen in den Standardberechtigungen gab, und die Änderungen können Versionskonflikte verursachen. Eine weitere Möglichkeit besteht darin, dass Antivirensoftware versehentlich eine Assembly sperrt.

Lösung: Löschen Sie den Ordner "Temporäre ASP.NET Dateien" aller Inhalte.

Szenario 4: Batchkompilierung

Beschreibung: Wenn das Batchattribut in der web.config Datei auf "True" festgelegt ist, wird die verzögerung, die durch die Kompilierung verursacht wird, beseitigt, die erforderlich ist, wenn Sie zum ersten Mal auf eine Datei zugreifen. ASP.NET alle nicht kompilierten Dateien im Batchmodus vorkompiliert. Dieser Batchmodus führt bei der ersten Kompilierung der Dateien zu Verzögerungen.

Wenn Sie das Batchattribut auf "False" festlegen, werden möglicherweise alle maskierten Kompilierungsfehler verfügbar gemacht, die in der Anwendung vorhanden sind, aber nicht gemeldet werden. Noch wichtiger ist, dass ASP.NET aufgefordert werden, einzelne ASPX/ASCX-Dateien dynamisch in separaten Assemblys und nicht in einer einzigen Assembly zu kompilieren.

Lösung: Legen Sie batch=False im <compilation> Abschnitt in web.config fest. Diese Aktion sollte als temporäre Lösung betrachtet werden. Batch=False im Kompilierungsabschnitt hat erhebliche Auswirkungen auf die Buildzeiten für die Anwendung in Visual Studio.

Szenario 5: Bearbeiten von web.config startet die AppDomain neu.

Beschreibung: Wenn Sie die web.config Datei für eine ASP.NET Anwendung ändern oder eine Datei im Ordner "Bin" ändern (z. B. hinzufügen, löschen oder umbenennen), wird die AppDomain neu gestartet. Wenn diese Aktionen ausgeführt werden, gehen alle Sitzungszustände verloren, und zwischengespeicherte Elemente werden beim Neustart der Website aus dem Cache entfernt. Das Problem kann durch einen inkonsistenten Zustand in der Webanwendung verursacht werden.

Lösung: Lösen Sie einen AppDomain-Neustart aus, indem Sie die web.config Datei berühren (bearbeiten).

Szenario 6: Geänderter Quellcode wurde noch nicht dynamisch neu kompiliert

Beschreibung: Sie können Quellcode im Ordner App_Code speichern, und der Code wird zur Laufzeit automatisch kompiliert. Auf die resultierende Assembly kann auf jeden anderen Code in der Webanwendung zugegriffen werden. Der App_Code Ordner funktioniert daher ähnlich wie der Ordner "Bin", mit der Ausnahme, dass Sie darin Quellcode statt kompilierten Code speichern können. Die Klasse wird neu kompiliert, wenn die Quelldatei geändert wird. Wenn ein Konflikt aufgrund einer veralteten Assembly vorliegt, kann das Problem durch Erzwingen einer erneuten Kompilierung behoben werden.

Lösung: Tippen Sie auf eine Datei im Container oder App_Code Ordner, um eine vollständige Neukompilierung auszulösen.