Artentus schrieb:

und lade sie hier hoch. Ansonsten hab ich keinen Anhaltspunkt, wo der Fehler liegt.

Ich muss das direkt hier auf meinem PC im VS-Debugger machen, damit ich ordentliche Infos über den Fehler bekomme. Nur "ArgumentOutOfRangeException" reicht leider nicht.

Das Programm kann seit der 1.2 auch einzelnen Projekmappen laden. Wähle also jeden Ordner einzeln aus und prüfe, bei welchem der Fehler auftritt. Diesen lädst du dann als ZIP hier hoch.

Ich hab tatsächlich ein wenig fahrlässig programmiert. In diesem Projekt gab es keine Angabe zur Frameworkversion, da hat es geknallt. Ich müsste jetzt aber überall Sicherheitsabfragen drin haben, damit sowas nicht wieder passiert.
Neue Version ist im ersten Post.

Aufgrund eines weiteren Fehlers hab ich nochmal nen Hotfix hochgeladen.
Außerdem werden jetzt Projekte und Dateien, die nicht vorhanden sind, übersprungen, anstatt das Programm zum Abstürzen zu bringen.

Hier kommt nun das Tutorial dazu, wie ihr die dem Programm beiliegende VBProjectInfoLib verwenden könnt.

Im ersten Teil geht es lediglich darum, wie ihr die Grundfunktionalität der Lib benutzen könnt, um die Eigenschaften von VB und C# Projekten auszulesen. Darum wird es nicht sehr lang sein.
Wenn ihr die Lib eingebunden und Artentus.ProjectInfo importiert habt, habt ihr unter anderem Zugriff auf die Klassen Solution, Project und CodeFile, welche das Kernstück der Lib bilden. Sie sind auch sehr einfach in der Benutzung.

Edit: seit die Lib in der Version 3.0 vorliegt, ist das ganze Pluginbasiert. Ihr müsst zusätzlich also noch die folgenden Schritte befolgen:
Importiert auch den Namespace Artentus.ProjectInfo.Packages. Jetzt hab ihr Zugriff auf die Klasse PackageManager.
Wenn ihr die Plugins in dem Standardordner "Packages" belassen habt, so genügen folgende Aufrufe einmalig zum Programmstart:

Solltet ihr den Ordner geändert haben, so müsst ihr dies dem PackageManager so mitteilen:


Um eine komplette Projektmappe zu laden verwendet einfach den folgenden Code:
Wie ihr seht also ganz einfach. Die Klasse wird sich nun automatisch um den Rest kümmern, das bedeutet es werden sowohl die Eigenschaften der Projektmappe geladen als auch alle enthaltenen Projekte und Codedateien. Dabei wir so intelligent vorgegangen, dass nicht unterstützte Datei- und Projekttypen übersprungen werden (sie werden nachher nicht in den Eigenschaften auftauchen).

Wenn ihr keine ganze Projektmappe sondern nur ein einzelnes Projekt laden wollt, so könnt ihr auch direkt ein Project-Objekt instanzieren. Das funktioniert dann ganz genau so wie bei der Projektmappe:
Dabei werden auch alle enthaltenen Codedateien geladen, wobei alle ungültigen übersprungen werden. Beachtet aber, dass nur Projektdateien vom Typ .vbproj und .csproj geladen werden können, alle anderen werfen einen Fehler. Wie ihr das ändern könnt werde ich in einem anderen Teil des Tutorials erklären.

Ihr könnt natürlich genauso auch nur einzelne Codedateien laden:
Es können standardmäßig nur Codedateien mit den Endungen .vb und .cs geladen werden. Auch das kann geändert werden, was ich ebenfalls später erklären werde.

Für eine Liste, was alles ausgelesen wird, seht ihr hier noch mal das Klassendiagramm (für diesen Teil des Tutorials ist nur die linke Hälfte von Bedeutung):


Hier gehts zum zweiten Teil des Tutorials.

Niko Ortner schrieb:

solange normale Projektmappen drin sind.

Heißt das, dass es bei bestimmten Projektmappen immer noch nicht funktioniert?

Niko Ortner schrieb:

Wie werden die Projekte in der Projektmappe sortiert?

Sie sind in der selben Reihenfolge, wie in der .sln-Datei.

Niko Ortner schrieb:

Hast Du Dir die VistaFBD.dll angeschaut?

Noch nicht, ich wollte es erst mal zum laufen bringen.

@Niko Ortner
Ist schon behoben.
Und zu dem Dialog: funktioniert der auch in XP und niedriger, oder muss ich das abfragen? Ansonsten ist das Ding echt top!

Die 1.4 ist da. Getan hat sich folgendes:

• besserer FolderBrowserDialog (nur ab Vista und höher)
  
• vollständige Unterstützung für Drag and Drop
  
• Bug beim Auslesen mancher .sln-Dateien behoben
  

In diesem Teil des Tutorials gehts es darum, wie ihr die Lib dazu bringen könnt, auch andere Projektdateien als .vbproj und .csproj zu akzeptieren.
Erklären werde ich dies anhand der Standardimplementation von C#.

Wenn ihr vorhabt, einen weiteren Projekttyp zu registrieren, so müsst ihr zunächst eine entsprechende Projektdatei ausfindig machen und diese öffnen. Achtet dabei darauf, dass ihr die Datei mit "Rechtsklick -> Öffnen mit" öffnet, da ein Doppelklick warscheinlich das Projekt in VisualStudio laden wird.
Ich habe hier zum Beispiel die Projektdatei für MathUtils gewählt:

Leider sind diese nicht für alle Sprachen gleich aufgebaut, weswegen ihr der Lib mitteilen müsst, wo nach bestimmten Informationen gesucht werden soll.
Dafür gibt es das Interface IProjectTypeDescriptor, welches ihr implementieren müsst. In meinem Fall sieht das so aus:
Das Interface deklariert einige Properties, die ihr implementieren müsst. Ich werde sie nun nacheinander durchgehen.

Zuerst müsst ihr die Dateiendung und den Namen des Projekttyps angeben. Das geschieht durch diese beiden Eigenschaften:
Hier genügt es, einfach einen konstanten String zurückzugeben. Beachtet auch, dass die Dateiendung den Punkt beinhalten muss.
Der Name kann beliebig gewählt werden, er hat keine Bedeutung für das Programm.

Dann benötigt die Lib einen Ort, an dem nach den Projektressourcen gesucht werden soll. Im Fall von C# ist das der Ordner "Resources":
Der Ordner wird dabei relativ zum Projektverzeichnis gesucht.

Die übrigen Properties geben alle das Interface IXmlPathDescriptor zurück und beschreiben einen Ort in der XmlDatei.
Wir müssen uns also zunächst darum kümmern, dieses Interface zu implementieren. Dafür habe ich in der Lib eine einfache Standardimplementation verwendet, ihr könnt das aber so komplex gestalten, wie ihr möchtet (dafür das Interface).

Hier eine kurze Erklärung, was die einzelnen Propreties machen:

• PathAvailable: Gibt an, ob die gewünschte Information überhaupt verfügbar ist. Wenn False, dann wird diese Eigenschaft von der Lib komplett ignoriert.
  
• Path: Gibt den Pfad in der XmlDatei an, unter dem die Informationen gespeichert sind.
  
• UsesAttribute: Gibt an, ob die Informationen als Xml-Attribut vorliegen.
  
• Attribute: Der Name des Attributes, in dem die Informationen enthalten sind. Ist UsesAttribute False, so wird dies ignoriert.
  

Mit dieser kleinen Hilfsklasse können wir nun mit der eigentlichen Arbeit beginnen.
Als erstes müsst ihr die restlichen Properties implementieren:

Die Namen der Properties beschreiben ziemlich genau, welcher Pfad jeweils verlangt ist.

Wir sehen uns also die erste Property an, sie heißt AssemblyNamePath, was drauf schließen lässt, dass hier der Pfad gesucht ist, unter dem der Assemblyname zu finden ist.
Nun suchen wir in der Projektdatei von oben nach einem Knoten, der darauf passt, und finden <AssemblyName>MathUtils</AssemblyName> mit dem Pfad "/x:Project/x:PropertyGroup/x:AssemblyName".
Beachtet das "x:" vor jedem Knotennamen. Es wird als Platzhalter für den Xml-Namespace benötigt, ohne wird es nicht funktionieren.
Mit diesem Wissen können wir die Property implementieren:
Das zweite Argument (also der Attributname) kann hir "null" sein, da der Assemblyname nicht als Attribut vorliegt (deswegen ist das dritte Argument auch false).

Machen wir mit der nächsten Property, CodeFilesPath, weiter. An der Namensgebung könnt ihr schon erkennen, dass hier mehrere Knoten möglich sind (nicht zwingend erforderlich!).
Die Codedateien sind in meinem Beispiel in solchen Knoten gespeichert: <Compile Include="ArcPolygon.cs" />
Diesmal ist also ein Attribut mit im Spiel welches wir ebenfalls angeben müssen. Beim Rest gehen wir einfach so vor, wie im vorherigen Beispiel. Die fertige Implementation sieht dann so aus:

Bei den Restlichen Properties könnt ihr genauso vorgehen.
Es kann auch sein, dass eine Sprache ein Feature nicht unterstützt. Bei C# wären das zum Beispiel die globalen Importe. In solch einem Fall ist das Implementieren sogar noch einfacher:
Das letzte false sagt der Lib, dass keine Informationen zu erwarten sind, wir können also überall null übergeben.

Die fertige Klasse sieht dann so aus:


Als letzten Schritt braucht ihr nur noch eure neue Klasse in der Lib zu registrieren, damit sie verwendet werden kann. Dies geht mit dieser einfachen Zeile:


Und das wars dann, nun könnt ihr mit der Lib auch euren neuen Projekttypen laden lassen.
Möglicherweise (sogar höchst wahrscheinlich) basiert euer Projekttyp auch auf anderen Codedateien. Wie ihr Unterstützung für diese hinzufügen könnt, erklär ich euch im nächsten Teil des Tutorials.

Hier gehts zum dritten Teil des Tutorials.

Das erste ist eine simple Rechnung (LineCount - EmptyLineCount), also sehr einfach einzubauen.
Bei dem zweiten bekomme ich aber so meine Probleme, dann nicht alle Sprachen haben solche Syntaxelemente wie die geschweifte Klammer.

Im dritten Teil des Tutorials werde ich euch nun zeigen, wie ihr die Lib dazu bringen könnt, auch Codedateien mit anderen Endungen als .vb und .cs zu laden.

Auch für dieses Vorhaben bietet die Lib ein Interface an, es heißt ICodeFileTypeDescriptor.
Zuerst müsst ihr es wie in Part 2 implementieren (wieder am Beispiel von C#):


Dieses Interface ist nicht ganz so komplex, wie IProjectTypeDescriptor, ihr müsst lediglich drei Member implementieren.
Zum einen wären das Languagename und FielExtension. In meinem Beispiel würden diese so aussehen:


Zum anderen wäre das die Funktion ParseCode. In dieser müsst ihr die Datei einlesen, also Codezeilen, Kommentarzeilen, Leerzeilen und Gesamtzeilen zählen. Erwartet wird ein Objekt vom Typ CodeDescription, welches diese vier Dinge speichern kann.
Hier nun die Funktion für C#:

Erklärung:
Die Datei wird Zeilenweise eingelesen. Für jede Zeile wird zunächst der Counter für die Gesamtzeilenanzahl inkrementiert.
Nun wird für alle Zeilen überprüft, ob sie leer, eine Kommentarzeile oder eine Codezeile ist, und der jeweilige Counter inkrementiert.
beachtet die Behandlung von mehrzeiligen Kommentaren (Z. 21 - 30), wo die zeilen zwischen Anfang und Ende als Kommentarzeile behandelt werden müssen, ahc wenn sich nicht mit dem Kommentarsymbol beginnen.
Am Ende wird einfach nur ein CodeDescription-Objekt erstellt, welchem die gezählten Werte übergeben werden.

Die vollständige Klasse sieht jetzt so aus:

Um diese zu verwenden müsst ihr sie ebenfalls registrieren. Dies macht ihr mit diesem Code:

Und damit seit ihr fertig, die der neue Dateityp wird jetzt von der Lib ausgewertet.
Beachtet, dass ihr für manche Projekttypen mehrere Dateitypen definieren solltet, wie zum Beispiel bei C++ die .cpp- und .h-Dateien.

Hier gehts zum vierten Teil des Tutorials.

Da die Lib ja jetzt hervorragend erweiterbar ist (siehe Tutorial) ist mir die Idee gekommen, dass das doch ein guter Pluginsystem abgeben würde.
Was haltet ihr davon, soll ich das ganze auf Plugins umschreiben? Das hätte den Vorteil, dass man Erweiterungen auch für dieses Programm erstellen könnte, und nicht wie vorher nur für eigene (ich denke mal, dass das sowieso das einzig sinnvolle wäre).

Edit: Umfrage hinzugefügt.