Ein Lob für das Visual-Studio-Debugger-Team

Vor einiger Zeit hatte ich eine Beta von Visual Studio 2012 ausprobiert und versucht, damit unsere C++-basierten Applikationen zu debuggen. Mit VS2005 bis VS2010 hatte das jahrelang prima geklappt. Mit VS2012 hingegen ging es hochkannt schief: Der Versuch, die Applikation zu starten, führte zu einem Total-Crash von VS2012 selbst, noch bevor die erste Zeile unseres Programm-Codes überhaupt zur Ausführung kam. Mehr oder weniger das selbe Phänomen bei einem Attach to process: Unser EXE war toxisch, bei der ersten Berührung damit fiel VS2012 tot um.

Als sich das auch mit der RTM-Version von VS2012 nicht geändert hatte, und weit und breit keine gute Idee zu sehen war, was der Grund sein könnte für das Problem, wurde ich langsam nervös und rang mich dazu durch, bei Microsoft Hilfe zu suchen, obwohl ich recht skeptisch war: Würde sich ein Weltkonzern wie Microsoft interessieren für ein Problem einer kleinen IT-Bude in der Schweiz?

Ich machte also ein Posting im Forum des Visual Studio Developer Center. Das Resultat war mittelprächtig: Ein Microsoft-Mitarbeiter, der da wohl so etwas wie „Dienst tut“, schaute sich die Sache an, war aber bald mit seinem Latein am Ende, und machte schliesslich den Vorschlag, ich solle direkt einen Bug-Report erstellen, auf connect.microsoft.com.

Das tat ich auch – den Bug Report find man hier – und wartete gespannt, wie es weitergehen würde.

Das Resultat übertraf meine Erwartungen deutlich: Nach nur etwa 2 Wochen hatte jemand im Debugger-Team den Grund für die Crashes gefunden, die Sache für die nächste Version von Visual Studio korrigiert, und erst noch eine Umgehungs-Lösung geliefert, wie es auch mit dem bestehenden VS2012 klappt.

Allein diese Umgehungslösung ist sehr interessant: Offenbar hat Microsoft, ohne das an die grosse Glocke zu hängen, wesentliche Teile der „debugging engine“ für die 2012er-Version von Visual Studio überarbeitet, und es war dieser neue Code, welcher an einer Seltsamkeit in den VERSIONINFO-Daten in unserem EXE gar keine Freude hatte. Es gibt einen Trick, wie man die „legacy debug engine“ aktivieren kann, den alten Code, welcher damit klarkommt und der noch da ist: Man schaltet die Option Enable Edit and Continue in den Debugging-Options ein:

Legacy Debugger

Legacy Debugger aktivieren

Das ganze war für mich ein voller Erfolg. Auch wenn es natürlich keinerlei Garantien auf Erfolg gibt, möchte ich doch jeden ermuntern, der ein ernstes Problem hat mit Visual Studio, den Weg über einen Bug-Report auch zu versuchen. Es kann sein, dass man erhört wird.

Veröffentlicht in Keine Kategorie. Schlagwörter: , . Leave a Comment »

Debugging von ASP.NET-MVC2-Applikationen

Irgendwie ging immer alles schief, wenn ich Fehler aufspüren wollte in der Applikation, die ich gerade mit ASP.NET MVC2 entwickle: Z.B. bei der Verwendung eines Objekts, das fehlerhafterweise null war, stoppte der Debugger nicht am Ort des Fehlers, sondern irgendwo im MVC2-Code, dort nämlich, wo ein „hoch oben“ angesiedelter Handler per catch die resultierende Exception abfing.

Um noch eins draufzusetzen, hatte Visual Studio zudem etwas am entsprechenden MVC2-Source-File mit dem catch drin zu meckern, das es vom Microsoft-Source-Code-Server heruntergeladen hatte, irgendetwas mit Some bytes have been replaced with the Unicode substitution character while loading file, so wie bei StackOverflow hier beschrieben, notabene ohne Tipps zur Abhilfe.

Es gibt in Visual Studio eine Einstellung, mit der der Debugger gleich stoppt, sobald irgendeine Exception auftritt, unabhängig davon, ob ein catch dafür zuständig ist oder nicht, so wie hier beschrieben, aber dieser Mechanismus hat auch so seine Probleme:

Mit Debugging-Option Enable Just My Code nicht gesetzt gibt’s viel zu viele Exceptions, weil in MVC2 vieles über Exceptions abgehandelt wird, die man dann alle erst „wegklicken“ muss, bis schliesslich die eigene Exception drankommt, um die es eigentlich geht. Und mit Option gesetzt klappt’s mit Exceptions innerhalb von MVC2 nicht, die auftreten, weil man z.B. einer Methode einen Parameter als null übergeben hat, der definiert sein muss.

Die Rettung war schliesslich folgendes Vorgehen:

Man kann dankenswerterweise den Source Code von ASP.NET MVC2 bei Microsoft CodePlex hier herunterladen, in einer Form, über die Visual Studio nichts zu meckern hat. Und es ist überraschend einfach, diesen Code quasi als „eigenen“ Code in sein Projekt einzubinden, so wie hier beschrieben. (Die Beschreibung ist zwar noch für MVC1, es klappt aber auch mit MVC2.)

Für die Zeit der Entwicklung meiner Applikation habe ich nun an zwei Orten in diesem MVC2-Source-Code catch-Anweisungen auskommentiert, so dass der Debugger die meisten auftretenden Exceptions als unhandled taxiert und gleich stoppt. (So komme ich jetzt ohne die erwähnte untaugliche Option aus, die den Debugger bei jeder Exception stoppen lässt.)

Auch sonst ist es natürlich ganz interessant, ein paar Blicke auf diesen Source-Code zu werfen, und man findet im Netz etliche Kommentare von Leuten, die schwierige Probleme in ihren Web-Applikationen nur dadurch lösen konnten, indem sie anhand dieser Sourcen im Debugger verfolgten, was innerhalb ASP.NET MVC2 genau passierte.

Veröffentlicht in Allgemein. Schlagwörter: , , . Leave a Comment »

Visual Studio Refactoring und Code in .aspx

Als ich vor ein paar Jahren die Refactoring-Befehle in Visual Studio kennenlernte, insbesondere das Rename-Kommando, hatte ich irgendwie das Gefühl, nach einem langem Aufenthalt in der Tool-Steinzeit endlich in der Moderne angekommen zu sein: Nie wieder der Horror von rein textuellem Search & Replace, wenn 2 ganz verschiedene Dinge gleich heissen und man nur eines davon umbenennen will.

Mit der Zeit denkt man gar nicht mehr so darüber nach: Ist doch selbstverständlich, den Texteditor mit dem Compiler zusammenzuschalten, der schliesslich ganz genau weiss, welche Referenz auf welches Objekt zeigt, ganz egal, wie viele Dinge rein textuell gesehen gleich heissen.

Als vor kurzem ein ASP.NET-MVC2-Projekt nach einem Refactoring mit Fehlern in .aspx-Files nicht mehr kompilieren wollte, dachte ich zuerst an eine Fehlbedienung meinerseits oder an einen nur sporadisch auftretenden Bug in Visual Studio 2010, aber eine Recherche heute brachte schliesslich Klarheit: Es herrscht wieder Steinzeit. Das Refactoring in VS2010 ist nicht schlau genug, bei Rename auch Code-Stücke in .aspx-Files zu erfassen.

Man findet dieses Problem im Internet, z.B. in dieser Frage auf Stack Overflow, aber eine eigentliche Empörung über dieses klaffende Loch im System scheint es interessanterweise nicht zu geben. (Intellisense funktioniert auch in .aspx-Files, irgendwie, aber mit einem Fehlen jenes Features wäre Microsoft wahrscheinlich nicht durchgekommen bei der Entwickler-Gemeinde.)

Zum Glück gibt es Leute, welche sich solcher Probleme annehmen, und Tools wie ReSharper programmieren, welche die Welt sozusagen wieder geraderücken.

Allerdings droht bereits neues Ungemach: Leute scheinen sich immer wieder neue Spielarten von Syntax auszudenken, wie man am besten und elegantesten C#-Code mit HTML mischt, nicht zuletzt Microsoft selbst mit der neuen Razor View Engine für ASP.NET MVC3. Und diese neuen Spielarten überfordern dann Tools wie den erwähnten ReSharper zunächst wieder, wie man etwa im Blog der Hersteller-Firma nachlesen kann.

Das ist wohl ein nicht zu vermeidendes Problem im Zuge der rasanten Weiterentwicklung, welche die ganze .NET-Welt mitmacht…

Veröffentlicht in Keine Kategorie. Schlagwörter: , . Leave a Comment »

Visual Studio Gallery

Unter dem Titel Visual Studio Gallery betreibt Microsoft ein Repository für verschiedenste Tools, Controls und Templates, mit deren Hilfe man Visual Studio erweitern kann. Vielleicht ja kalter Kaffee für Sie, aber wenn Sie sich da noch nie umgeschaut haben, könnte es sich lohnen, das nachzuholen.

Die Vielfalt der angebotenen Dinge täuscht ein wenig: Wenn man links in der Sektion Visual Studio Versions diejenige Version anklickt, die man selbst konkret in Betrieb hat und die Anzeige damit filtert, fällt einiges weg. Und wenn man gleich darunter in der Sektion Cost Categories mit der Wahl von Free alles verschwinden lässt, was Geld kostet oder eine limitierte Probeversion darstellt, bleiben z.B. von total fast 500 Tools nur noch etwa 160 freie Tools für VS2008 übrig. Aber das ist allemal noch eine interessante Menge.

Als ich selbst heute diese Liste der kostenlosen Tools für VS2008 durchging, bin ich beim HyperAddin hängengeblieben. Damit ist es unter anderem möglich, in Kommentaren Links zu schreiben, die zu irgendeinem Symbol des Projekts führen, denen man folgen kann wie den „eingebauten“ URL-Links mit Hilfe von Ctrl + Mausklick.

Konkret sieht das so aus:

  public class HyperAddinDemo {
    public void Method1() {
    }

    public void Method2() {
      // Hinweis: macht nicht dasselbe wie code:HyperAddinDemo.Method1
    }
  }

Links zu beliebig setzbaren Ankerpunkten in irgendeinem File des Projekts statt zu Symbolen sind ebenso möglich.

Ich denke, ich werde das in Betrieb nehmen und schauen, ob solche Links wirklich so nützlich sind, wie ich nach ersten Tests vermute.

Eine Frage steht bei solchen Erweiterungen natürlich immer im Raum: Was passiert, wenn ich auf eine neue Version von Visual Studio wechsle? Wie die Visual Studio Gallery selbst demonstriert, können Addins durchaus spezifisch sein für bestimmte Versionen von Visual Studio; damit besteht die Gefahr, dass ich z.B. beim bevorstehenden Schritt auf VS2010 das gerade liebgewonnene HyperAddin bereits wieder verliere, falls der Autor nicht mitzieht.

Es muss wohl jeder selbst für sich entscheiden, wie er mit diesem Risiko umgehen will und wie er Nutzen jetzt gegen möglichen Verlust bei einem Wechsel von Visual Studio in der Zukunft gegeneinander verrechnet. Konkret bei diesem Addin hat mir in dieser Hinsicht gefallen, dass der Sourcecode zur Verfügung steht und ich mich damit wahrscheinlich selbst durchschlagen könnte bei einem Problem auf einer neuen Plattform.

Veröffentlicht in Keine Kategorie. Schlagwörter: . Leave a Comment »

Der Historical Debugger in VS2010

Schon vor einiger Zeit hat Microsoft angekündigt, dass Visual Studio 2010 einen neuen, speziellen Debugger namens Historical Debugger enthalten wird. Man findet z.B. hier eine Ankündigung aus dem Oktober 2008:

Are you tired of constantly setting breakpoints to hone in on a pesky bug? How would you like to be able to step „back in time“ through your debugger? The Historical Debugger in Visual Studio Team System 2010 promises to revolutionize your debugging experience.

Ich sagte mir, na das ist doch mal was Interessantes: Irgendwie rückwärts durch ein Programm debuggen? Weil ich für Revolutionen immer zu haben bin und als „Systemprogrammierer“ einfach wissen muss, wie man einen Debugger implementiert, der so etwas leistet, bin ich der Sache heute auf den Grund gegangen und kann nun berichten, worum es geht.

Zunächst musste ich eine Hürde aus dem Weg räumen: Der Historical Debugger ist tatsächlich nur im Visual Studio Team System 2010 verfügbar, das „normale“ Visual Studio ohne TS, das ich mir zuerst testweise installiert hatte, enthält ihn nicht. Man findet die VS2010-TS-Preview als ISO-Download hier.

Der Witz an der Sache ist der folgende: Der Historical Debugger schreibt selbständig zu bestimmten Zeitpunkten während der Programmausführung ein Log mit Informationen über den Zustand des Programms zum jeweiligen Zeitpunkt. Der angepriesene „Schritt zurück in der Zeit“ besteht darin, nach einem Stopp des Programms aus der Debug History, d.h. der Liste der Zeitpunkte, einen Eintrag auszuwählen und sich im Debugger den Zustand des Programms anzuschauen, wie er damals war.

Das kann natürlich – im Prinzip – ganz nützlich sein: Hat man z.B. einen Breakpoint erreicht und stellt fest, dass eine Variable einen falschen Wert aufweist, muss man nun nicht mehr mit dem Debugging von vorne beginnen und sich vorsichtig an den Zeitpunkt heranpirschen, wo der falsche Wert zum ersten Mal auftaucht, sondern kann bequem und entspannt die Debug History verwenden, um den Zeitpunkt zu finden oder mindestens stark einzugrenzen, wo die Sache aus dem Ruder läuft.

Man kann in 2 Stufen wählen, wie die Zeitpunkte bestimmt werden sollen: Log schreiben entweder bei „wichtigen Systemereignissen“ oder bei solchen Ereignissen plus bei jedem Methoden-Aufruf. Man kann hier erahnen, dass die Sache Potential hat auszuufern, denn Methoden-Aufrufe können ja sehr zahlreich sein.

Ins Log geschrieben werden der Call Stack zum Zeitpunkt und Variablen-Werte zum Zeitpunkt, wobei man bei Objekten nur noch das Resultat von ToString sieht, aber keinen Zugriff mehr bekommt auf die einzelnen Komponenten.

Ein paar Screenshots hierzu findet man im Blog Dariusz quatscht hier.

Meiner Meinung nach ist das ganz hübsch, aber ob es für eine Revolution reicht, ist fraglich. Insbesondere die doch sehr eingeschränkte historische Sicht auf Variablen-Werte enttäuscht. Mir ist schon klar, dass es schlicht unmöglich ist, zu Hunderten von Zeitpunkten den gesamten Heap ins Log zu schreiben, damit ich auch nachträglich noch Objekte mit all ihren Details anschauen kann, aber hey, es hätte ja sein können, dass jemand mit Hilfe einer genialen Idee ein Log implementiert hat, das viele Details mit praktikablem Aufwand speichern kann, z.B. mit einer Heap-Differenzen-Methode…

Was haben andere so gemacht in Sachen Debugger mit Historie? Hier ist von einem experimentellen Java-Debugger die Rede, der vor ein paar Jahren implementiert wurde und der offenbar alle Variablen-Zuweisungen während eines Programmlaufs protokolliert, indem er sich in die Pseudocode-Ausführung der JVM einklinkt. Er nennt sich denn auch treffend Omniscient Debugger („allwissender Debugger“) und erlaubt offenbar die volle Sicht zu einem beliebigen Zeitpunkt.

In einer PDF-Datei, welche den Debugger genauer beschreibt, findet sich die Information, dass Apache Ant etwa 24 Millionen Variablen-Zuweisungen macht, während das Tool seine eigene Kompilation steuert. Das sind eine ganze Menge, aber nicht so viele, dass sie den Ansatz an sich gleich zu Fall bringen.

VMWare hat etwas im Angebot, das die Firma Replay Debugging nennt, beschrieben auf der Website hier. Unterstützt wird Debugging für C/C++, wie man im Artikel hier nachlesen kann. Das ganze funktioniert mit Hilfe der Virtual Machine, wo man natürlich wie bei der JVM eine zentrale Stelle hat, wo man sich einklinken kann, um zu protokollieren, was läuft. Das Debugging, sprich der Blick auf das Log findet statt in einem Visual Studio, das um ein VMWare-Plugin ergänzt wurde.

Anhand der Beschreibung vermute ich, dass komplett protokolliert wird und man so in einzelnen Schritten vorwärts und sogar rückwärts durch das Programm gehen kann. Die Suche nach dem Punkt im Programm, wo eine Datenstruktur „zerstört“ wird, finde man so: Zeitpunkt finden, wo sie falsch ist, dann Programm „rückwärts laufen lassen“ mit Daten-Breakpoint auf der Struktur und einfach auf den Break durch Veränderung warten.

Hier meldet sich natürlich wieder meine Neugier, die mich veranlasst hat, überhaupt erst den Historical Debugger von Microsoft anzuschauen und die sich nun fragt: Wie macht VMWare das? Ich vermute, dass die komplette Abfolge aller CPU-Befehle, welche das Programm ausführte, der zentrale Bestandteil des Logs ist, und dass das „Debugging“ darin besteht, mit Hilfe der Virtual Machine das Programm irgendwie entlang dieser Abfolge zu führen, vielleicht gestützt auf Komplett-Speicherabzüge in gewissen Zeitabständen.

Und ich vermute ebenfalls, dass die Sache derart auf die Ausführung direkter CPU-Anweisungen zentriert ist, dass die Ausdehnung des Prinzips auf C# mit seinem JIT-Compiler eine schwierige bis unmögliche Sache werden dürfte.

Veröffentlicht in Keine Kategorie. Schlagwörter: , . 1 Comment »

Ein etwas nostalgischer Blick zurück

Als ich vor einiger Zeit ernsthaft mit Visual Studio und .NET/C# zu arbeiten begann, verglich ich diese Programmierumgebung ganz automatisch mit dem vor über 10 Jahren erschienenen VB6, mit dem ich vor allem durch eine privat damit gebaute Shareware sehr gut vertraut war.

Bei diesen beiden Systemen sind nur wenige Dinge exakt gleich, schon alleine wegen C# anstelle von BASIC als Sprache. Aber trotzdem hatte ich immer das Gefühl einer grossen Vertrautheit, den Eindruck einer weitgehenden Übereinstimmung bezüglich der grundlegenden Philosophie: Überall sah ich quasi den „Geist“ von VB6 durchschimmern.

Was mich aber noch viel mehr beeindruckte, und auch immer stärker, je genauer ich Visual Studio und .NET kennenlernte, war die folgende Geschichte: Im Gegensatz zum Nachfolger ist VB6 geradezu ein Winzling, weist aber trotz seiner bescheidenen Grösse (und trotz seines Alters) eine erstaunliche Menge der wichtigsten technologischen „Errungenschaften“ bereits auf.

Dinge wie Garbage Collection, IntelliSense im Editor, grafischer Form-Designer, hervorragendes Laufzeit-Debugging inklusive Watches und Immediate-Fenster, Code-Änderungen während das Programm läuft, mächtige String-Klasse, Kompilieren zu Native Code, Klassen inklusive Late Binding beim Aufruf von Objekt-Methoden, alles schon drin in diesem System von 1998, in einem Laufzeitsystem von nicht mal 3 MB und einer IDE von absolut lächerlichen 15 MB.

Natürlich könnte ich problemlos eine noch längere Liste von Eigenschaften aufzählen, die VB6 nicht hatte, ohne die man aber im Jahre 2009 zum Entwickeln von Software gar nicht anzutreten braucht.

Es geht mir um etwas Anderes: Der Vergleich VB6 versus Visual Studio 2010, C# und .NET 3.5 ist für mich mittlerweile eines der besten Beispiele, die ich persönlich kenne, um die 80%/20%-Regel zu illustrieren: Ja, das moderne System kann mehr als das gute alte VB6, aber man sehe sich mal an, wieviele der wirklich wichtigen, zentralen Eigenschaften VB6 bereits aufweist (die „80%“ in besagter Regel), erreicht mit vergleichsweise bescheidenem Aufwand (den „20%“). Oder umgekehrt: Ja, das moderne System ist überlegen, aber man sehe sich mal an, mit welch gigantischen Aufwand gewisse Verbesserungen erkauft werden mussten.

Natürlich kann ich als reiner Anwender von Visual Studio und .NET das Resultat geniessen, denn Microsoft trieb ja quasi für mich den grossen Aufwand, nicht ich. Und einen modernen Rechner bringen auch grosse IDEs und Laufzeitsysteme nicht ins Schwitzen.

Aber wenn ich selber etwas baue, tue ich gut daran, immer mal wieder an die 80%/20%-Regel zu denken und diese zu beherzigen. Mir persönlich fällt das nicht schwer, mit einem etwas nostalgischen Blick zurück zu VB6 dann und wann, zu dem ich z.B. Gelegenheit habe, wenn mein PC die Visual-Studio-IDE mit viel Festplatten-Aktivität in den Speicher wuchtet und diese riesige Maschine anwirft…

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . 1 Comment »

IntelliSense und Erweiterungen von Klassen

IntelliSense in Visual Studio ist eine wunderbare Sache, die das Programmieren ungemein erleichtert. Eigentlich sollte heutzutage niemand mehr in einer Umgebung programmieren müssen, wo kein in etwa gleichwertiges Feature zur Verfügung steht. Trotzdem sahen wir ein ernstzunehmendes Problem damit, als wir hier in der Megos ernsthaft damit begannen, unsere neues Programmierwerkzeug Triton in C# zu implementieren.

IntelliSense scheint seine Listen immer stur alphabetisch zu sortieren und immer alles aufzulisten, ohne Filtermöglichkeiten. Das kann dan zu einem Problem werden, wenn man Klassen erweitert, die bereits eine Menge Members haben, und dann in der IntelliSense-Liste seine „eigenen“ Members (d.h. diejenigen der Erweiterung) kaum mehr findet. Je nach Art der Klassen benötigt man beim Implementieren bevorzugt eben diese eigenen Members, was das Ganze dann etwas mühsam macht.

Unsere Überlegungen zeigten uns, dass sich die Sache zuspitzt, wenn man Klassen für den Datenbank-Zugriff generiert, wo für jede Kolonne in einer Tabelle eine Property definiert wird, die sich dann zu all den Members der Zugriffs-Basisklasse gesellt und unter diesen irgendwie unterzugehen droht, obwohl sie doch zum eigentlichen „Witz“ der generierten Klasse gehört.

Man kann das bereits bei Visual-Studio-eigenen typed datasets beobachten: Eine Tabellen-Zugriffs-Klasse wird von System.Data.TypedTableBase abgeleitet, einer Klasse mit geschätzten etwa 100 Members. Eine Kolonne TitelKurs wird zu einer Property namens TitelKursColumn und wird von IntelliSense unter T eingeordnet; eine Kolonne WährungsKurs wird zu WährungsKursColumn und taucht dann in der Liste unter W und damit an einem ganz anderen Ort auf. Dieses Verhalten verunmöglicht es praktisch, sich per IntelliSense einen schnellen Überblick über alle Kolonnen zu verschaffen – aber wo ausser da soll denn dieser Überblick herkommen?

Es war schnell klar, dass es bei Visual Studio und IntelliSense, so wie jetzt implementiert, nur ein einziges „Rädchen“ gibt, an dem man überhaupt drehen kann, wenn man dieses Problem irgendwie lösen will: Will man Members zusammen sehen in einer IntelliSense-Liste, so müssen sie eben entsprechend heissen, d.h. alle mit irgendeinem Präfix beginnen.

Sie werden als geneigter Leser vielleicht schon ahnen, dass dieser Blog-Eintrag hier geradewegs auf ein Dilemma zumarschiert: Von Namenspräfixen wird in .NET und C# eigentlich abgeraten; verwendet man sie trotzdem, stecken einen gewisse Leute schnell einmal in die Schublade „Ewiggestrige“, die reserviert ist für Leute, die von ihren alten Gewohnheiten nicht lassen können und auch nicht verstanden haben, dass man heutzutage nur noch „natürliche“ Namen vergibt, weil man – eben gerade durch Features moderner IDEs wie z.B. IntelliSense – nicht mehr darauf angewiesen ist, vom Namen eines Dings irgendwelche Meta-Information ablesen zu können.

Aber wie gesagt, hier geht es nicht darum, sondern um eine Lösung für ein kleines, aber sehr lästiges Problem mit IntelliSense.

Wir sahen das Ganze als Wahl zwischen zwei Übeln: 1) einen Teil der Namen mit Hilfe von Präfixen verunstalten, aber damit den Nutzen von IntelliSense aufwerten, oder 2) den Empfehlungen und der Mehrheit der C#-Programmierer folgen, aber sich mit Situationen abfinden, in denen IntelliSense wenig hilft, obwohl es gerade da sehr nützlich wäre.

Nach einigem Hin und Her entschieden wir uns für das Übel 1). Wir wählten z.B. für die Properties unserer eigenen Klassen in Triton den Einbuchstaben-Präfix z, weil eine Abklärung ergab, dass nur wenige .NET-Klassen bereits Properties haben, mit mit Z beginnen, und damit diese Properties nicht nur zusammen angezeigt werden in einer IntelliSense-Liste, sondern auch noch herausstechen.

Seit dieser Entscheidung haben wir eine rechte Menge Code gemäss diesen Präfix-Konventionen erzeugt, und es ist eine erste Beurteilung des Erreichten möglich. Der gewünschte Effekt bei IntelliSense hat sich eingestellt: Man behält so tatsächlich ohne Probleme den Überblick über die eigenen Dinge im Gegensatz zu den „fremden“ Dingen des Frameworks. Aber hübsch sieht es irgendwie nicht aus, und eine richtige Gewöhnung an unsere mit Präfixen dekorierten Namen will sich eigentlich auch nicht einstellen.

Für jemanden, der sich im .NET-Framework wirklich gut auskennt, gäbe es vielleicht eine Wahlmöglichkeit 3), welche das Dilemma umgeht: ein Add-In programmieren, welches neben der IntelliSense-Liste eine zweite, entsprechend eingeschränkte Liste implementiert. Aber ganz soweit sind wir in der Megos noch nicht…

Veröffentlicht in Keine Kategorie. Schlagwörter: , . 1 Comment »