Quasi Code Documentation as a Service. Dann müssen sich die ganzen Devs das nicht installieren, sondern wir haben was zentrales, was alle nutzen können.

Da wäre es wirklich super, wenn man eine statische HTML-Seite emittiert, damit man das direkt auf Github-Pages pushen kann, wenn der CI-Build durchläuft.
Sollte ja jetzt auch schon gehen, oder? Wie würde man das am besten machen?

Ich sehe, du migrierst auf Roslyn. Gefällt mir.

Es wäre jetzt noch schön, wenn man in dem Projekt ein Post-Parse aber Pre-Build-Skript angeben könnte. Der Hintergrund dazu ist, dass ich das Projekt einlesen, dann den Branch auf z. b. gh-pages wechseln möchte und dann die Doku in den Branch emittieren will. Gut wäre auch, wenn ich den Output-Pfad so konfigurieren könnte, dass ich nicht noch die "Html/default"-Unterordner habe, sondern direkt die Webseite.

Da wäre ich auch stark für.

Die Icons der HTML-Doku beginnen mit Großbuchstaben. Im Quelltext werden sie allerdings komplett kleingeschrieben referenziert, was dazu führt, dass es z. B. bei den github-Pages (oder jedem anderen Linux-Webserver?) ein 404 gibt.

Bei Enums fände ich es schön, wenn man irgendwo den tatsächlichen Wert eines Enum-Members stehen hätte. Ich bin wahrscheinlich der einzige Mensch auf dem Planeten, der das brauchen würde, deshalb würde ich es - wenn du es überhaupt machst - abschaltbar machen.

Bzgl. dem Build redest Du nun aber von Plattformen, nicht von Framework-Versionen. Die Plattformen verwenden fast alle verschiedene Framework-Derivate, wie z. B. Silverlight oder WP8.
Projektverweise spielen hier eh keine Rolle. Wie will ich dann Code eines Projektes nur mit Hilfe von Präprozessordirektiven für z. B. Silverlight compilen? Das geht nur mit Setup separatem Projekt - oder habe ich da was übersehen?
Aber ja - ich hab mich dort vermutlich nicht ganz korrekt ausgedrückt. Ich meine sowohl Framework-Versionen als auch Plattformen.

Diese Fachsimpelei ist zwar interessant, aber leider in diesem Thread OT. Wir können die Unterhaltung aber gerne wo anders weiterführen.

Eine Möglichkeit, um diese in der Doku gesondert zu behandeln (siehe Anhang) wäre außerordentlich schön - so wie es in der MSDN geht. Man müsste aber schauen, wie man die verschiedenen Herangehensweise für die Cross-Compilation unter einen Hut bekommt.

Deswegen erstelle ich jetzt einen kurzen Namen der, über das ganze Projekt hinweg, eindeutig ist. Sollte noch ein Typ "Templater" vorhanden sein würde die Url z.b. bla.de/index.html#type/Templater2 heißen. Hat das dann den folgenden Nebeneffekt?

Klasse: A.Templater --> type/Templater
Klasse: B.Templater --> type/Templater2

Klasse A.Templater wird in einen Namespace "C" verschoben und die Doku wird neu erstellt.

Klasse: B.Templater --> type/Templater (vorher type/Templater2)
Klasse: C.Templater --> type/Templater2 (vorher type/Templater)

Oder machst du was, damit ein bereits in einem vorherigen Build benutzter Name nicht noch einmal an einen andern Typen vergeben wird?
(Externe?) Verlinkungen, die ursprünglich auf A.Templater zeigten, zeigen nun auf B.Templater, obwohl sie in einem 404 enden sollten.

Ich weiß natürlich nicht, in welcher Reihenfolge du die Typen abarbeitest, ich gehe aber davon aus, dass sich diese beeinflussen lässt. Ob das nun mit dem Namespace-Namen oder irgendeiner Buid-Reihenfolge ist, spielt für das Problem ja keine Rolle.

Das Problem ist, dass bei Typen oder Mitgliedern dieser sehr lang werden kann. Ich sehe hier kein Problem. Beim Reference-Source könenna uch sehr lange URLs zustande kommen.
ht****tp://referencesource.microsoft.com/#PresentationFramework.Aero/src/Themes/Aero/Microsoft/Windows/Themes/ProgressBarHighlightConverter.cs#31

nicht mehrere Solutions pflegen muss und alles mit einem Knopfdruck erstellt wird. Bei meiner Herangehensweise habe ich auch nur eine Solution mit mehreren Projekten, die ebenfalls alle gleich (nacheinander) erstellt werden. Der Vorteil dabei ist, dass ich nicht nur für das Desktop-.NET, sondern auch für Silverlight, WP bzw. PCL und anderen Framework-Derivaten kompilieren kann, die auch teilweise leicht unterschiedliche Verweise haben. Das geht mit reinen Build-Konfigurationen/Compilerkonstanten in einem Projekt leider nicht so ohne Weiteres.

Interne Klassen / Methoden kannst direkt ausfiltern. Kann niemand nutzen 😉 Wenn die Doku für zum Beispiel für (firmen)interne Arbeiten verwendet wird, ist das doch durchaus sinnvoll, denke ich. Man kann es doch in der jetzigen Version einstellen, vielleicht sollte man einfach nur die Standardeinstellung anpassen. Für manche open source-Projekte wäre das u. U. auch sinnvoll, dann man ja eventuell nicht alleine an einem Projekt arbeitet. Und sich eine schöne Doku anzuschauen ist (IMO) besser, als sich die Code-
Annotations anschauen zu müssen. Zumindest um in das Projekt "reinzukommen".

Ich bin sicherlich nicht der einzige, der für mehrere Framework-Versionen kompiliert. Ich mache das, indem ich mehrere Projektdateien habe, die alle auf die selben Dateien referenzierten und jeweils nur mit verschiedenen Präprozessor-Konstanten kompilieren. Ich weiß nicht, wie sharpDox das macht, bzw. ich vermute, dass du einfach die Standard-Release-Builds kompilierst, welche ja (bei mir zumindest) die richtigen Konstanten definiert haben. Leider ist mir nicht ganz klar, welches Projekt letztendlich für die gerenderte Doku verwendet wird. Ziemlich schön wäre es, wenn man die Projekte mit "Aliasen" versehen könnte, sodass man später zwischen den einzelnen Projekten der Solution in der Doku umschalten könnte. Die Aliase dienen dann dazu, um wie bei der MSDN-Doku die entsprechende Framework-Version (= einzelnes Projekt) auswählen zu können.
Ist aber nur eine Idee, die sicherlich verbesserungswürdig ist. Erstmal sollten denke ich die Kernkomponenten fertig werden. Ich wollte sowas nur mal erwähnt haben.

Edit:
Wenn ich diese URL sehe:
http://www.sharpdox.de/doc/index.html#type/Templater
Was ist denn, wenn ich zwei Typen habe, die "Templater" heißen und einfach nur in verschiedenen Namespaces sind?
Vielleicht sollte man lieber den vollqualifizierten Namen haben, wie es auch die neue, Roslyn-Gestütze Reference-Source macht?
http://referencesource.microsoft.com
Das würde ich auch semantisch angebrachter finden.
Die Doku von Sharpdox selbst ist auf meinem Handy (Lumia 925 mit WP8.1, IE11) leider unbenutzbar. Nicht jeder surft mobil auf eine Doku (vermutlich bin ich der einzige), aber solltest du zu viel Zeit haben, könntest du das UI ja ein bisschen mehr responsive machen.

Das sind aber alles nur meine 2 Cent.

Hi,

wie wäre es mit einer Möglichkeit, verschiedene "Themes" für die Doku bereitzustellen?
Falls jemand auf Bootstrap steht, kann man sich schnell sein eigens Theme hinzaubern. Alternativ würde es mir auch reichen, das bestehende Template einfach editieren zu können, um bestimmte Styleanpassungen vorzunehmen.

Ich habe mir das Programm runtergeladen, ohne in die Dokumentation zu schauen (und von diesem Thread wusste ich bis eben nicht mal etwas). Beim Ausprobieren war ich leicht irritiert, weil ich nicht wusste, was für einen Pfad ich bei "Eingabepfad" angeben sollte.
Nach etwas rumprobieren habe ich rausbekommen, dass es weder die XML-Doku, noch eine Assembly, sondern eine Solution sein muss (oder geht auch was anderes?).
Jedenfalls würde ich dort verdeutlichen, welche Dateien man verwenden kann - z. B. mit einem Filter im OpenFileDialog.

Kann natürlich auch sein, dass es manche von mir vorgeschlagene Features schon gibt, da ich mir wie gesagt noch nichts großartig durchgelesen habe.

Ich werde hiermit dann wohl meine alten und ranzigen Sandcastle-Dokus ablösen, wenn ich noch etwas rumgetestet habe.

Edit:

Ich hab dann noch ein paar kleine Sachen:

• "Void" ist groß geschrieben (siehe Anhang).
• Enums, Structs, Interfaces usw. haben die gleichen Icons im TreeView wie Klassen
• Der SVG-Output scheint einen kleinen Bug zu haben (siehe Anhang). Die Funktion ist diese hier.
• Wenn <exception>-Dokumentationen angegeben sind, wäre es ziemlich gut, wenn sharpDox diese auch bei der Methode anzeigt (siehe ebenfalls verlinkter Code/Anhang)
• Wie wäre es mit Syntax-Highlighting für die Metoden-Signaturen? Von dem hier rate ich ab, der kommt nicht mit Generics zurecht. Highlight.js ist ganz schön und würde mit VS-Theme sicherlich passen. Habe aber nur serverseitig als Node-js-Modul Erfahrungen damit, das gibts aber auch am Client.

Schönen Gruß von der Konkurrenz. 😉

Die Kaffeemaschine steht einen Meter von meinem Arbeitsplatz weg. Den Kaffee und alles, was man zur Zubereitung benötigt, müssen wir uns selber kaufen. Das ist aber nicht schlimm, weil die Kollegen immer zahlen. 😉

Bei mir ist das dann ca. eine 3/4 Kanne (á 10 Tassen) in 7,8 Stunden. Zum Ausgleich vernichte ich dann noch 2l Wasser.