Debuggen von Anwendungen in Blend

Artikel
10/15/2014

Falls die Blend for Visual Studio-Anwendung nicht das gewünschte Verhalten zeigt oder falls beim Erstellen der Anwendung Fehler gemeldet werden, enthält die Anwendung möglicherweise einen Fehler. Das Finden der Ursache oder der genauen Position eines Fehlers in der Anwendung kann Probleme bereiten. Es kann hierbei jedoch hilfreich sein, wenn Sie wissen, welche Arten von Fehlern auftreten können.

Syntaxfehler

Beim Erstellen der Anwendung werden alle Syntaxfehler im Ergebnispanel auf der Registerkarte Fehler in Blend oder im Bereich Fehlerliste in Visual Studio angezeigt.

Syntaxfehler treten auf, wenn in Extensible Application Markup Language (XAML) oder im Code die Formatierungsregeln der Sprache nicht befolgt werden. Die Beschreibung des Fehlers kann bei seiner Behebung hilfreich sein. In der Beschreibung wird auch der Name der Datei und die Zeilennummer angegeben, in der der Fehler auftritt. Es folgen einige häufige Ursachen für Syntaxfehler:

Ein Schlüsselwort wurde falsch geschrieben, oder die Groß-/Kleinschreibung ist falsch.
Um Zeichenfolgen mit Text fehlen Anführungszeichen.
Für ein XAML-Element fehlt ein Endtag.
Ein XAML-Element ist an einer Position vorhanden, an der es nicht zulässig ist. Sie können diese Fehler vermeiden, indem Sie die Dokumente in der Designansicht von Blend oder in Visual Studio bearbeiten.
In einer Codedatei enthält ein Funktions- oder Methodenaufruf nicht die erforderlichen Parameter. Die MessageBox.Show()-Methode (Meldungsfeld anzeigen) muss z. B. mindestens einen Parameter besitzen, beispielsweise eine Zeichenfolge in MessageBox.Show("Hello").
In einer Codedatei ist eine Variable eines Typs einem anderen Typ zugewiesen. Die MessageBox.Show()-Methode (Meldungsfeld anzeigen) kann z. B. ein Zeichenfolgenargument, nicht jedoch ein Ganzzahlargument besitzen.
In C# darf eine Methode, die keine Argumente benötigt, keine Klammern am Ende besitzen. this.InitializeComponent; verursacht z. B. einen Syntaxfehler, da die korrekte Zeile this.InitializeComponent(); lautet.

Weitere Informationen zur XAML-Syntax finden Sie in den Übersichtsthemen der einzelnen Steuerelemente in der Windows Presentation Foundations-Steuerelementbibliothek und in der Silverlight Steuerelementgalerie (möglicherweise in englischer Sprache) auf MSDN. Informationen zur Programmiersyntax finden Sie, wenn Sie in MSDN nach Schlüsselwörtern im Code suchen.

Kompilierungsfehler

Beim Erstellen der Anwendung werden alle Kompilierungsfehler im Ergebnispanel auf der Registerkarte Fehler in Blend oder im Bereich Fehlerliste in Visual Studio angezeigt.

Kompilierungsfehler treten auf, wenn einige der für das Projekt erforderlichen Daten vom Kompilierungssystem von Blend oder Visual Studio nicht gefunden werden können. Wenn in Ihrem WPF-Projekt (Windows Presentation Foundation) z. B. ein Verweis auf die WPF-Assemblys fehlt, wird möglicherweise ein Fehler wie "Der Name 'Window' ist im Namespace https://schemas.microsoft.com/winfx/2006/xaml/presentation (möglicherweise in englischer Sprache) nicht vorhanden" ausgegeben. Falls dieser Fehler ausgegeben wird, können Sie im Menü Projekt auf Verweis hinzufügen klicken, um Verweise auf die folgenden WPF-Assemblys im Ordner "C:\Programme\Reference Assemblies\Microsoft\Framework\" hinzuzufügen:

PresentationCore.dll
PresentationFramework.dll
WindowsBase.dll

Falls weiterhin Fehler wie z. B. "Der Name '<member>' ist im aktuellen Kontext nicht vorhanden" ausgegeben werden, fehlt eventuell ein weiterer Assemblyverweis, oder Sie müssen dem Code möglicherweise für den fehlenden Namespace eine Anweisung vom Typ using (C#) oder Imports (Visual Basic .NET) hinzufügen. Sie können ermitteln, welche Assembly oder welcher Namespace erforderlich ist, wenn Sie das MSDN-Referenzthema für den Member anzeigen, der den Fehler verursacht.

Es folgen weitere häufige Ursachen für Kompilierungsfehler:

Ein Schlüsselwort wurde falsch geschrieben, oder die Groß-/Kleinschreibung ist falsch.
Auf eine Klasse wird in der Anwendung nicht ordnungsgemäß verwiesen. Wenn die Anwendung z. B. eine benutzerdefinierte Klasse verwendet, die in einer separaten CS- oder VB-Codedatei mit einem eigenen Namespace implementiert ist, muss jedes Dokument in der Anwendung, das die benutzerdefinierte Klasse verwendet, eine Zeile wie die folgende einschließen. FullyQualifiedNamespace entspricht hierbei dem Namespace in der Codedatei:
```
xmlns:SampleNamespace="clr-namespace:FullyQualifiedNamespace"
```
Die Compileroptionen sind nicht ordnungsgemäß festgelegt, oder vom System können keine Microsoft .NET Framework-basierten Anwendungen erstellt werden. Falls Sie über Microsoft .NET Framework verfügen und Sie die Anwendung mit Blend oder Visual Studio erstellen, sollte dieses Problem nicht auftreten.
Das Projekt soll erstellt werden, eine Datei wurde jedoch noch nicht gespeichert. Wenn Sie z. B. das Ereignispanel von Blend zum Generieren einer neuen Ereignishandlermethode in der CodeBehind-Datei verwenden (und die CodeBehind-Datei in Visual Studio öffnen) und dann das Projekt in Blend erstellen möchten, ohne die CodeBehind-Datei vorher zu speichern, wird eine Fehlermeldung ausgegeben, dass das Projekt keine Definition für den Ereignishandler enthält.

Laufzeitfehler

Laufzeitfehler können auftreten, wenn die Anwendung zwar erstellt wird, bei der Ausführung (durch Drücken von F5 in Blend) jedoch nicht das erwartete Verhalten zeigt. Laufzeitfehler sind sehr schwer zu finden, da Fehler in der Logik vorhanden sind. Manchmal können Laufzeitfehler behoben werden, indem Sie verschiedene Änderungen in XAML oder Code ausprobieren, bis Sie die Abläufe im Hintergrund erkennen. Die schnellere Möglichkeit besteht jedoch darin, die im Hintergrund stattfindenden Abläufe direkt zu beobachten, indem Sie den Code während der Programmausführung zeilenweise durchgehen.

Weitere Informationen finden Sie unter Debuggen von Blend-Anwendungen in Visual Studio.

Es folgen einige häufige Ursachen für Laufzeitfehler:

Das Layout von XAML-Elementen ist fehlerhaft, oder es wird ein falsches Panelobjekt für andere Objekte verwendet.

Informationen zum Layout finden Sie unter Organisieren von Objekten in Layoutcontainern in Blend oder unter Das Layoutsystem (möglicherweise in englischer Sprache) und Übersicht zu Ausrichtung, Rändern und Abständen (möglicherweise in englischer Sprache) im WPF-Abschnitt auf MSDN..

Ein XAML-Element ist nicht in den korrekten Ereignishandler eingebunden. Dies kann vorkommen, wenn Sie zahlreiche Ereignishandlermethoden erstellen und dann dem XAML-Element die falsche Methode zuweisen. Sie können anzeigen, welche Ereignishandler einem XAML-Element in einem in Blend geöffneten WPF-Projekt zugewiesen sind, indem Sie im Panel Objekte und Zeitachsen das Objekt auswählen und dann im Eigenschaftenpanel auf die Schaltfläche Ereignisse klicken.
Ein Animationstrigger ist in Blend nicht ordnungsgemäß festgelegt. Animationsstoryboards müssen z. B. in einem Trigger gestartet werden, wenn sie nach dem Laden der Anwendung angehalten werden sollen. (Standardmäßig werden alle Animationsstoryboards im Trigger Window.Loaded gestartet, diese Einstellung kann jedoch geändert werden.)

Weitere Informationen finden Sie unter Animieren von Objekten. Ein Beispiel für Animationstrigger finden Sie unter Erstellen einer einfachen Animation.
In einer Codedatei verweist eine Variable auf ein noch nicht vorhandenes Objekt. Beispielsweise wird in einer CodeBehind-Datei, wenn Sie vor der Zeile this.InitializeComponent() auf ein XAML-Objekt verweisen, ein XamlParseException-Fehler ausgegeben.
In einer Codedatei verwendet die Anwendung einen unerwarteten Codepfad. Dieses Problem kann am besten durch eine schrittweise Überprüfung des Codes beim Debuggen der Anwendung in Visual Studio 2010 behoben werden.

Weitere Informationen finden Sie unter Debuggen von Blend-Anwendungen in Visual Studio.
In einer CodeBehind-Datei werden Aktualisierungen der Benutzeroberfläche (User Interface, UI) in demselben Thread verarbeitet wie andere Programmlogik, die in einem separaten Thread ausgeführt werden sollte. Wenn Sie z. B. eine Ereignishandlermethode erstellen, die den in einem Label-Feld angezeigten Text aktualisiert, einige andere Berechnungen durchführt und dann erneut den Text im Label-Feld aktualisiert, bevor die Ereignishandlermethode beendet wird, wird nur die letzte Aktualisierung angezeigt. Der Grund hierfür liegt darin, dass die Benutzeroberfläche am Ende der Ereignishandlermethode und nach Abschluss der gesamten Verarbeitung in demselben Thread gerendert wird. Daher kann während der Ausführung der Methode keine Zeit für die Aktualisierung der Benutzeroberfläche aufgebracht werden.

Informationen zum Schreiben von WPF-Anwendungen mit mehreren Aktualisierungen der Benutzeroberfläche und Berechnungen finden Sie im Thema Threading-Modell im WPF-Abschnitt auf MSDN.
In einer Ereignishandlermethode in einer CodeBehind-Datei wird auf Benutzeroberflächenelemente oder ihre Eigenschaften verwiesen, bevor diese verfügbar sind. In einer Window1()-Konstruktormethode können Sie z. B. noch nicht auf Benutzeroberflächenelemente zugreifen. In einer OnInitialized()-Ereignishandlermethode können Sie zwar auf Benutzeroberflächenelemente zugreifen, Sie können jedoch die Eigenschaften wie ActualWidth nicht überprüfen, da das Layout für die Benutzeroberflächenelemente noch nicht beendet wurde. In einer OnLoaded()-Ereignishandlermethode können Sie alle beliebigen Aktionen für Benutzeroberflächenelemente ausführen, die im XAML-Dokument vorhanden sind.

Weitere Informationen finden Sie unter Objektlebensdauer-Ereignisse im WPF-Abschnitt auf MSDN.

Debuggen in Visual Studio

Blend ist ein Designwerkzeug zum Erstellen umfassender Benutzeroberflächen für WPF-basierte Anwendungen und Microsoft Silverlight-Anwendungen. Sie können Visual Studio verwenden, um Blend-Projekte zu öffnen, zu erstellen und zu debuggen. Falls beim Debuggen der Anwendung mithilfe der Funktion Projekt ausführen (F5) von Blend Probleme auftreten, können Sie mit Visual Studio detaillierte Fehlermeldungen zu Laufzeitfehlern abrufen.

Weitere Informationen finden Sie unter Debuggen von Blend-Anwendungen in Visual Studio.

Leistungsprobleme beim Debuggen

Von WPF wird eine Suite von Tools zur Leistungsbewertung bereitgestellt, mit deren Hilfe Sie das Laufzeitverhalten der Anwendung analysieren und Maßnahmen zur Leistungsverbesserung bestimmen können.

Weitere Informationen finden Sie unter Leistungsprofilerstellungstools für WPF und Optimieren der WPF-Anwendungsleistung (möglicherweise in englischer Sprache) im WPF-Abschnitt auf MSDN.

Ereignisablaufverfolgung

Erfahrene .NET-Programmierer können ihren WPF-Anwendungen Code hinzufügen, um benutzerdefinierte Debugereignisse auszulösen, die beim Debuggen komplexerer Fehler hilfreich sind. Diese Funktion wird als Ereignisablaufverfolgung für Windows (Event Tracing for Windows, ETW) bezeichnet. Das Werkzeug zur Profilerstellung in der WPF-Ereignisablaufverfolgung verwendet ETW zur Ereignisprotokollierung.

Weitere Informationen finden Sie unter "Event Tracing" und "PresentationTraceSources" unter Tools für das Erstellen von WPF-Leistungsprofilen (möglicherweise in englischer Sprache) auf MSDN.

Debuggen von Hybridanwendungen

Falls in einer Anwendung sowohl WPF als auch eine andere Technologie wie Windows Forms-Programmierung verwendet wird, können Probleme wie unerwartete Überlappungen, unerwartetes Skalierungsverhalten, Probleme beim Steuern des Fokus usw. auftreten.

Informationen zum Debuggen von Hybridanwendungen finden Sie unter Problembehandlung für Hybridanwendungen (möglicherweise in englischer Sprache) im WPF-Abschnitt auf MSDN.

Sicherheit

Während des Debuggens besitzt die Anwendung dieselben Sicherheitsberechtigungen wie bei Verwendung durch eine andere Person.

Weitere Informationen finden Sie unter Bereitstellen und Veröffentlichen von in Blend entwickelten Anwendungen.

Weitere Informationen zur WPF-Anwendungssicherheit, finden Sie im WPF-Abschnitt Sicherheit auf MSDN.

Anzeigen der Hilfe

Wenn Sie weitere Unterstützung zum Debuggen einer Blend-Anwendung benötigen, können Sie im Windows Presentation Foundation Forum (Windows Presentation Foundation-Forum) oder im Silverlight learning center (Silverlight-Informationscenter) (möglicherweise in englischer Sprache) nach Beiträgen zu einem konkreten Problem suchen oder selbst eine Frage bereitstellen.