In meiner Badewanne bin ich der Käpt'n!

Am 22.03.2010 erscheint die neue Mutter aller IDEs: Visual Studio 2010. Und um es vorwegzunehmen: Natürlich will ich die neue Version haben. Visual Studio ist für mich ein unverzichtbares Werkzeug, mit VS.PHP von JCX Software als Add-In nutze ich es für die Entwicklung all meiner Webapplikationen. Und ich halte das Studio für die ausgereifteste IDE, die man am Markt kriegen kann. So weit zu den Voraussetzungen.

Bei der Veröffentlichung von VS 2010 wird aber auch die Vielfalt der verfügbaren Editionen von Microsoft eingebremst. Im Grunde genommen wird es nur noch noch drei geben – Professional, Premium und Ultimate. Die Professional scheidet dabei für mich aus; kein Profiler, keine Code Coverage, keine Test Impact Analysis, kein UML-Viewer. Außerdem fehlen in der zugehörigen MSDN – Subscription unter anderem Office, Office Professional, Visio Premium, Project Professional und das Expression Studio 3. Tools für die Entwicklung von Datenbanken sind darüber hinaus ebenfalls nicht enthalten.

Da durch das Zusammenstreichen der Editionen jetzt aber überall u.a. ein kompletter Team Foundation Server dabei ist, haben wir gleich den Haken an der Sache: Ersten Aussagen von Microsoft zufolge wird VS 2010 Premium mit MSDN-Subscription etwa dreimal soviel kosten, wie das bisherige VS 2008 mit MSDN Premium. Für einen Einzelentwickler ist das eine Menge Geld, sicher auch für einige Unternehmen, die darauf angewiesen sind.

Um das Volk der Developer nicht zu verbittern, haben sich die Marketing-Freaks bei Microsoft aber noch etwas einfallen lassen:

• Wer zum Zeitpunkt der Veröffentlichung von VS 2010 ein VS 2008 Professional mit MSDN Premium – Subscription besitzt, wird automatisch auf VS 2010 Premium hochgestuft! VS 2010 Premium ist in der Subscription dann bereits enthalten. Achtung: Besitzer der alten MSDN Professional – Subscription werden nicht hochgestuft, sondern bekommen nur VS 2010 Professional.
• Wer zum Zeitpunkt der Veröffentlichung von VS 2010 ein VS 2008 Team System in der Architect-, Test-, Developer- oder Database-Edition besitzt, wird automatisch auf VS 2010 Ultimate hochgestuft – mehr geht nicht. Das ist die gleiche Edition, die es dann auch für alle gibt, denen jetzt eine komplette Team Suite gehört, was wohl eher nur in größeren Unternehmen der Fall sein dürfte.
• Außerdem bietet Microsoft seit dem 01.10.2009 und noch bis 31.03.2010 eine sogenannte Attach-Promotion an. Damit lässt sich Visual Studio 2008 Professional ohne MSDN mit einer MSDN Premium – Subscription aufrüsten, womit man wieder in den Genuss der oben beschrieben Hochstufung kommt.

Mehr Infos:

Produktvergleich der VS 2010 – Editionen

Infos zur Hochstufung

Infos zur Attach-Promotion

Gleich nochmal XDebug – weil’s so schön war. Wenn man den eingebauten Profiler verwendet, dann erzeugt dieser cachegrind.out-Dateien, die sich mit einem Programm wie z.B. WinCacheGrind sehr komfortabel analysieren lassen. Der Haken dabei: Per Default benennt XDebug die Dateien nach dem Schema cachegrind.out.%p, was bedeutet, dass jede Datei als Dateiendung eine pid hat, beispielsweise cachegrind.out.5174. Das ist nicht besonders komfortabel, weil sich die Profiler-Dateien so nicht auf herkömmlichem Wege mit WinCacheGrind verknüpfen lassen. Glücklicherweise kann man das Pattern für die Dateibenennung in der php.ini vorgeben:

[xdebug]
xdebug.profiler_output_dir="C:/xampp/htdocs/xdebug"
xdebug.profiler_output_name=xdebug.profiler.%t.out

In diesem Beispiel wird bei der Erzeugung der Datei durch XDebug ein Timestamp (in Sekunden) in den Dateinamen gesetzt – und zwar vor dem .out! Die Dateien sind damit eindeutig voneinander unterscheidbar und zusätzlich im Dateinamen gleich nach Zeit sortiert. Ein Beispiel wäre xdebug.profiler.119427223256.out. Die Dateiendung .out lässt sich wie gewohnt mit WinCacheGrind oder einem anderen geeigneten Programm verknüpfen – fertig. XDebug stellt derzeit noch neun weitere sog. format specifier zur Verfügung, eine vollständige Liste findet sich hier.

Es ist darauf zu achten, dass das in der php.ini festgelegte Ausgabeverzeichnis auch wirklich real existiert. Sollte der spezifizierte Ordner im Dateisystem zum Zeitpunkt der Ausführung des Profilers wider erwarten nicht vorhanden sein, wird er von XDebug nicht angelegt! Statt dessen wird die gewünschte Profiler-Datei einfach nicht erzeugt!

Das gleiche Benennungsschema gilt für Trace-Dateien, die XDebug ebenso anlegen kann:

[xdebug]
xdebug.trace_output_dir="C:/xampp/htdocs/xdebug"
xdebug.trace_output_name=xdebug.trace.%t

Hier gibt es allerdings den Unterschied, dass Trace-Dateien automatisch mit der Endung .xt versehen werden, ohne dass man diese vorher explizit angeben muss.

Wenn es um die (grafische) Auswertung von Trace Files geht, beißt man mit WinCacheGrind natürlich auf Granit. Da geht nix. Mir ist bislang kein wirklich brauchbares Programm bekannt, um Trace Files vernünftig darzustellen. Vielleicht hat ja ein Leser einen Tipp für mich. Drupal bietet mit Visualize Backtrace ein Modul, welches in der Lage ist, von XDebug erzeugte Trace Files in GraphViz-Graphen umzuwandeln und diese als Tabelle bzw. als hierarchische Baumstrukturen auszugeben. Detailliert beurteilen kann ich das nicht – hab’s noch nicht ausprobiert. Die im Netz kursierenden Screenshots der Graphen sehen aber ganz manierlich aus.

XDebug ist ein hervorragender Debugger / Profiler / Tracer, wenn man Webanwendungen mit PHP erstellt. Dummerweise gibt es hin und wieder das Problem, dass XDebug in manchen Konfigurationen abstürzt und den Apache gleich mit in die ewigen Jagdgründe reißt. Mir ist das auch passiert, und zwar mit XAMPP 1.7.2, wobei meine Settings eigentlich nicht besonders verhaltensauffällig waren. Werfen wir mal einen Blick auf meine XDebug-Konfiguration in der php.ini:

[xdebug]
xdebug.remote_enable=1
xdebug.remote_host="stefan"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
xdebug.remote_mode=req
xdebug.profiler_enable=1
xdebug.profiler_output_dir="C:/xampp/htdocs/xdebug"
xdebug.profiler_output_name=xdebug.profiler.%t.out
xdebug.auto_trace=1
xdebug.trace_format=0
xdebug.trace_output_dir="C:/xampp/htdocs/xdebug"
xdebug.trace_output_name=xdebug.trace.%t
xdebug.collect_params=4
xdebug.collect_return=1

Eine einfache und erfahrungsgemäß auch meistens funktionierende Lösung, um das Absturzproblem in den Griff zu bekommen, ist es, den Profiler von XDebug zu deaktivieren. Dazu gibt es drei verschiedene Möglichkeiten:

1. Man kommentiert die entsprechende Zeile mit Hilfe eines Semikolons aus:

;xdebug.profiler_enable=1

2. Man setzt den entsprechenden Wert auf 0:

xdebug.profiler_enable=0

3. Man löscht einfach die gesamte Zeile aus der php.ini.

Nun ist der Profiler natürlich ein sehr wichtiges Werkzeug bei der Entwicklung und beim Testen. In vielen Projekten wäre man daher schön doof, auf seine Dienste zu verzichten. Ich habe das Problem in den Griff bekommen, indem ich beim Laden der entsprechenden Zend Extension in der php.ini den Bereich

[zend]
zend_extension_ts = "C:/xampp/php/ext/php_xdebug.dll"

in

[zend]
 zend_extension = "C:/xampp/php/ext/php_xdebug.dll"

abgeändert habe. Ab diesem Zeitpunkt lief XDebug bei mir auch mit Profiler wie am Schnürchen.

Warum das so ist, ob es sich dabei um ein deterministisches Verhalten handelt und ob diese Lösung für beliebige Versionen von Apache, PHP und XDebug funktioniert, kann ich (noch) nicht mit Sicherheit sagen. Ich habe die DLL mal durch die letzte Version von xdebug.org ersetzt:

zend_extension="c:/xampp/php/ext/php_xdebug-2.0.5-5.3-vc6.dll"

Und das hat auch geklappt, wie oben beschrieben. Für Windows-User, die eine vorkompilierte DLL verwenden wollen, ist dabei wichtig, dass man die VC6-Version von XDebug (z.B. php_xdebug-2.0.5-5.3-vc6.dll) verwenden muss, wenn der HTTPD-Server von Apache zum Einsatz kommt. Die VC9-Version (z.B. php_xdebug-2.0.5-5.3-vc9.dll) ist für den Betrieb mit dem IIS gedacht. Der Unterschied liegt im verwendeten Compiler bei der Erstellung der Binaries.