[SharpDevelop] Dokumentation erzeugen: Seite nicht gefunden

[Luckie]

Wenn ich mir mit SharpDevelop eine chm-Dokumentation erzeuigen lasse und ein Thema anklicke, dann steht da immer:

Zitat:

Die Seite kann nicht angezeigt werden.

Das passiert auch wenn ich das HTML2Help Projekt mit dem HTML Workshop lade und von da kompiliere. Was läuft da falsch? :gruebel:

Und kannman für (global) eine Seite angeben? Wenn ja wo?

[MathiasSimmack]

Betrifft dieser Fehler deine eigenen Seiten? Also die Funktionen und Member deiner Klassen? Ich nehme doch an, du lässt dir mit NDoc eine Doku zu deinen Klassen erzeugen.

Bei mir taucht der Fehler nur auf, wenn Deklarationen aus dem .NET-Framework referenziert werden. Der System-Namespace bspw. Das liegt aber auch bloß daran, dass NDoc den englischen Help 2.0-Namespacenamen für das .NET-Framework verwendet (MS.NETFrameworkSDKv1.1). Der deutsche lautet aber "MS.NETFrameworkSDKv1.1.DE", und darum führen die Links grundsätzlich ins Leere.

[Robert_G]

@MS (Ich wollte mich schon immer mal direkt an MS wenden. :mrgreen: )
Das solltest du im Konfig.-Fenster von nDoc einstellen können. :gruebel:
Ob es geht weiß ich nicht, da ich weder das SDK noch irgendwas anderes auf deutsch installiert habe. :gruebel:

[MathiasSimmack]

Das mag sein, Robert, aber ich kreide das nicht NDoc an. Das Problem liegt bei Microsoft. Das Help 2.0-System ist an sich großartig. Es spielt keine Rolle, wo sich die Hilfedateien befinden. Wichtig ist nur, dass sie für den jeweiligen Namespace registriert werden. Es wäre also kein Problem gewesen, immer den gleichen Namen zu verwenden, egal ob man nun englische, deutsche oder französische Versionen des SDK installiert. Weil Microsoft nun aber andere Namespace-Namen benutzt (MS.NETFrameworkv1.1 vs. MS.NETFrameworkv1.1.DE) ist es für Dokus eher hinderlich, weil die mit NDoc nur mit dem englischen Framework funktionieren werden. Und lokalisieren kann man es auch nicht, weil es dann wieder bei einem Engländer oder Franzosen nicht geht.

Ich habe gerade die Idee für ein Tool, das Alias-Namespaces registriert, so dass eben sowohl der deutsche als auch der internationale Name bekannt sind. :mrgreen: Muss ich mal drüber nachdenken.

[Luckie]

Zitat:

Zitat von MathiasSimmack

Betrifft dieser Fehler deine eigenen Seiten? Also die Funktionen und Member deiner Klassen? Ich nehme doch an, du lässt dir mit NDoc eine Doku zu deinen Klassen erzeugen.

Ja genau.

Zitat:

Bei mir taucht der Fehler nur auf, wenn Deklarationen aus dem .NET-Framework referenziert werden. Der System-Namespace bspw. Das liegt aber auch bloß daran, dass NDoc den englischen Help 2.0-Namespacenamen für das .NET-Framework verwendet (MS.NETFrameworkSDKv1.1). Der deutsche lautet aber "MS.NETFrameworkSDKv1.1.DE", und darum führen die Links grundsätzlich ins Leere.

Klingt plausibel. Was läßt sich dagegen machen?

[MathiasSimmack]

Zitat:

Zitat von Luckie

Klingt plausibel. Was läßt sich dagegen machen?

Hilf mir bei meiner XSD-Validierung, und die Lösung steht kurz danach als Freeware zur Verfügung. :mrgreen:

Nein, ernsthaft: Entweder du installierst das englische .NET-Framework SDK, was ich aber für unsinnig halte, oder du registrierst die schon benutzten Hilfedateien dieses SDK noch mal für den internationalen Namen (ohne das ".DE" drin). Das halte ich für besser, weil die Hilfedateien nicht doppelt Platz auf der Platte belegen. Ich habe gestern schon ein Export-Utility geschrieben. Das nimmt einen Namespace, liest sämtliche Daten aus (Hilfedateien, Filter, Plugins) und erzeugt daraus eine XML-Steuerdatei für mein Registrierungstool. Auf Wunsch exportiert es den Namespace auch schon mit neuem Namen. Dann wird der neue Namespace einfach mit meinem Tool registriert, und schon funktionieren die Links.

Rein technisch funktioniert das auch schon perfekt. Ich hätte eben nur noch gern eine Validierung der XML-Datei, weil ich die Filter-Syntax verändert (vereinfacht) habe. Und um zu verhindern, dass jemand meinem Registrierungstool eine alte XML-Datei vorsetzt, will ich sie prüfen. Ich kann´s auch ohne anbieten, dann aber erst recht auf eigenes Risiko. :stupid:

[Robert_G]

Ich habe es zwar schon oben beschrieben....
Warum ändert ihr nicht einfach in nDoc die Sprache des zu referenzierenden SDKs? :gruebel:
Wobei ich eine Mischung aus englischen Kommentaren im Code und einem deutschen SDK für witzlos halte ;) (Programmierer können entweder englisch oder werden mit fehlnder Doku bestraft, ich bin da ziemlich darwinistisch. :mrgreen: )


Ich habe noch schnell einen Screenie rangehängt. ;)

[Luckie]

Hm, bei mir sieht das etwas anders aus. Siehe Anhang.

[Robert_G]

Wie alt ist denn das? :shock:
http://ndoc.sourceforge.net/

[Luckie]

War das bei SharpDevelop mitgeliefret NDoc.

[Robert_G]

Jupp, das ist wohl "etwas" alt. ;)

[Luckie]

Ich habe jetzt das aktuelle installiert, das hat aber auch nichts geholfen.

[MathiasSimmack]

Zitat:

Zitat von Robert_G

Ich habe es zwar schon oben beschrieben....

Ja, ich auch. Ich habe auch oben beschrieben, was die Ursache ist.

Zitat:

Warum ändert ihr nicht einfach in nDoc die Sprache des zu referenzierenden SDKs? :gruebel:

Damit löst Luckie das Problem auf seinem Rechner und bei allen, die auch das deutsche .NET-Framework SDK installiert haben. Dann würde der 404-Fehler eben bei allen anderen auftreten, die kein deutsches SDK verwenden. Wenn ich davon ausgehe, dass er sein Programm inkl. der generierten Hilfe veröffentlichen wird, dann wäre mein Vorschlag, die englische Referenz zu belassen. Es wäre ja nicht das erste seiner Programme, das über deutsche Grenzen hinaus bekannt ist.

Und wenn man unbedingt funktionierende Links haben will, dann installiert man entweder das englische SDK zusätzlich (was aber IMHO enorme Platzvergeudung wäre), oder man richtet einen zweiten Help 2.0-Namespace mit dem englischen Namen ein, in dem bloß die schon installierten deutschen Hilfedateien referenziert werden. Damit werden bloß ein paar neue kleine Dateien erzeugt, die für das Help 2.0-System wichtig sind, um die neue Collection identifizieren und starten zu können.
Das funktioniert bei mir super und beweist auch, dass die interne Dateistruktur der SDK-Hilfe überall identisch ist. Der ganze Sch*** wird also tatsächlich bloß durch den Namespace-Namen ausgelöst, den Microsoft offenbar unbedingt Länderspezifisch haben wollte. :roll:

Zitat:

Zitat von Luckie

Ich habe jetzt das aktuelle installiert, das hat aber auch nichts geholfen.

Du musst die neue NDoc-Version aus dem Startmenü aufrufen. SharpDevelop liefert eine eigene Version mit, und leider sind weder NDoc noch #d so clever, die alte Version zu überschreiben bzw. die neue Version aufzurufen.