This post originated from an RSS feed registered with .NET Buzz
by -.
Original Post: Code Analysis und von WPF generierter Code
Feed Title: Norbert Eder - Living .NET
Feed URL: http://feeds.feedburner.com/NorbertEder-Livingnet
Feed Description: Copyright (c)2005, 2006 by Norbert Eder
Die lokale Code Analyse durch Visual Studio 2008 ist eine sehr hilfreiche Sache, um oft gemachte Unschönheiten, eventuelle Performance- und/oder Security-Probleme früh zu erkennen oder auch nur, um die korrekte Namensgebung zu beachten.
Werden die Richtlinien aktiviert (unter den Projekteigenschaften) und zudem einige dieser Richtlinien auf Error gestellt (standardmäßig sind alle als Warnings eingetragen), dann ist man gezwungen, eben diese auch tatsächlich zu beheben. Kein schlechter Weg, um die Qualität des Codes früh auf einen entsprechenden Standard zu heben.
Allerdings gibt es dabei auch einen Haken:
Es gibt die Möglichkeit, generierten Code von der Überprüfung auszunehmen. Dies ist sehr sinnvoll, wenn Code von 3rd-Party-Tools generiert wird und es keine Möglichkeit gibt, die Generierung zu beeinflussen d.h. etwaige Warnings oder Errors los zu werden. Dies kann in den Projekt-Eigenschaften eingestellt werden:
Die WPF selbst generiert ja aus dem definierten XAML im Hintergrund den notwendigen Sourcecode. Wird ein neues Fenster angelegt, besteht dieses aus zwei Dateien:
- Window1.xaml
- Window1.xaml.cs
In der Window1.xaml kann nun per XAML Markup die einzelnen Elemente definiert werden. WIndow1.xaml.cs ist die Codebehind-Datei und enthält den notwendigen Sourcecode (Eventhandler etc.). Nun muss aus der XAML-Datei einiges an Code generiert werden:
Deklaration der einzelnen Elemente, damit via Sourcecode darauf zugegriffen werden kann.
Methode InitializComponent
Methode Connect
All das landet in der Datei Window1.g.cs. Wird also im Hintergrund für uns generiert. (Daher das g in der Endung). Blöderweise erhält diese Datei kein GeneratedCodeAttribute, wodurch die Prüfung auf die Richtlinien hin unterdrückt werden würde.
Im zu Grunde liegenden MSDN-Beitrag findet sich auch kein Hinweis darauf, schließlich wird WPF dort auch noch gar nicht behandelt.
Der einzige Ausweg daraus ist, den erhaltenden Fehler per SuppressMessage auszuklammern und zwar global für den gesamten Namespace. Eine Ausklammerung direkt im Source würde keine dauerhafte Änderung bringen, da das SuppressMessage-Attribute bei der nächsten Generierung überschrieben werden würde.
Previous Topic
;)