DotNetNuke mit C# auf dem richtigen Weg, aber noch nicht am Ziel! (CTP-3)

Nachdem nun bereits die dritte CTP Version von DotNetNuke 6.0 verfügbar ist, ist es an der Zeit sich einmal den Source der C# Version genauer anzuschauen.

Vorab aber noch einmal

„Gratulation an DotNetNuke“

für die Entscheidung das Projekt von VB nach C# zu migrieren.

Das ist auf jeden Fall eine Zeitgemäße und Zukunftsweisende Entscheidung.

Und ebenfalls Gratulation für die im großen und ganzen gute Umsetzung der C# Migration, bis hierhin.

Nach dem herunterladen und dekomprimieren der Source Version, gelingt es beim ersten Versuch, die Solution in Visual Studio zu laden und anschließend zu erstellen.

Das war in der Vergangenheit nicht immer so (eher sogar selten).

Dennoch bin ich mehr als nur ein wenig enttäuscht, dass man im Zuge der Migration nicht gleich einen einheitlichen Stil für die Erstellung des Source Code (Design Guidelines) im Stile von StyleCop eingeführt und umgesetzt hat.

Auf jeden Fall sind solche Regeln im vorhandenen Source Code (noch) nicht durchgängig zu erkennen..

Schade finde ich auch die fehlende bzw. nur sehr spärlich vorhandene Kommentierung des Source Code.

Ich werde auf jeden Fall, jetzt wo DotNetNuke ein C# Projekt geworden ist, und somit in meiner bevorzugten Programmiersprache entwickelt wird, wieder ein wachsames Auge auf das Projekt werfen.

Meine eigenen DotNetNuke Module werden in naher Zukunft ebenfalls so überarbeiten, dass diese unter der neuen Version lauffähig sein werden.

Wer mehr über die aktuellen Beta und CTP Versionen erfahren möchte, kann dies unter dem nachfolgenden Link direkt auf http://www.dotnetnuke.com nachlesen.

Beta Informationen zu DotNetNuke

3 Gedanken zu „DotNetNuke mit C# auf dem richtigen Weg, aber noch nicht am Ziel! (CTP-3)“

  1. Es gab schon immer die Möglichkeit, mit C# für DotNetNuke zu entwickeln. Man mag als Entwickler das ein oder andere lieber, aber ein .NET-Entwickler sollte mindestens mit C# und VB.NET umgehen können. So haben sich die DNN´ler einfach auf die andere Seite des Spielfeldes der Paradigmen-Anbeter gestellt. Das ist für mich kein Fortschritt.
    Am Core-Code sollte man bei keinem Framework herumfingern, wenn man den Upgrade-Prozess ohne Kopfschmerzen überstehen will. Und wenn man es doch unbedingt tun muss, kann man als C#-Liebhaber die Konfrontation mit VB.NET als Lehrstunde für effektiven Code nutzen 🙂

  2. Hallo Dirk,
    manchmal muss eine Entscheidung, damit Sie richtig ist nicht unbedingt einen direkten Vorteil mit sich bringen. Es gibt Strategische Entscheidungen wie diese hier, die einfach richtig sind und genau das ist meine Meinung.
    Ein OS Projekt unter .NET sollte heute einfach die Standardsprache verwenden und das ist ganz ohne Frage C#.
    Und wenn man, wie bei DNN, mit der Content Lokalisierung in den Core eingreift, dann kann es auch gleich die Umstellung auf die modernere Sprache sein.
    Was ich in VB.NET als Lehrstunde für effektiven Code sehen soll, kann ich nicht nachvollziehen.
    Ich habe selbst, das Core Blog Modul für DNN mit VB.NET entwickelt und es dann der Community gespendet. Ich habe aber auch einige OS Module in C# geschrieben und muss Heute sagen, dass es mir immer mehr graut in VB programmieren zu müssen, auch wenn ich das sicherlich noch immer beherrsche.
    Eine solche Überarbeitung des Core hat unter anderem auch den Vorteil, dass man den vorhandenen Code noch mal einem genauen Review unterziehen kann.

    Ich weiß nicht wie tief du im Code von DNN steckst, ich stecke da seit 9 Jahren drin und erlaube mir daher auch dieses Urteil, welches ich in meinem Blog Beitrag veröffentlicht habe.

    Es würde keinen Fortschritt geben, wenn man nicht den Mut besitzt auch an einem Framework herumzufingern.
    Wir würden heute noch in Assembler (was ich übrigens am Anfang noch gemacht habe) versuchen Mini Routinen zu schreiben und auf den Heap zu pushen und zu poppen.

    Oder wir hätte noch immer ein Windows das auf MS-DOS aufsetzt anstelle eines eigenständigen Windows Betriebssystems.

    Oder….. hier gibt es tausende von Beispielen die ich bringen könnte, aber das würde zu nichts führen.

    Beste Grüße
    HP

    1. Hallo Hans-Peter,

      ich respektiere Deine Erfahrung. Meine Erfahrung mit DotNetNuke beschränkt sich auf 5 Jahre und den Core-Code habe ich ebenfalls oft genug ändern müssen, weil nicht alle Version wirklich stabil waren usw.

      Wie schon gesagt, sollte man es -zumindest bei Kundenprojekten- vermeiden, wenn es sich vermeiden lässt, sofern man den Supportaufwand noch kalkulieren können muss. Und wenn man ein Modul entwickeln möchte, kann man das komplett in C# und VB tun. Wenn man das dann spenden möchte und DNN plötzlich auf C# basiert, freut man sich nun, aber als VB-Fan spielt man dann beleidigte Leberwurst, weil C# angeblich den Kalten Krieg der Programmiersprachen gewonnen hat?
      C# ist keine Standardsprache, das iPhone ist kein Standard-Smartphone. Die Anteile der Verbreitung sind derzeit hoch, aber es gibt nicht nur schwarz und weiß und in 2 Jahren ist wieder alles anders. Jede Alternative hat ihre Berechtigung und im Fall von VB gibt es nicht mal fachliche Gründe in Form von Funktionsdefiziten etc. Auch wenn das mit der Lehrstunde eher als Spaß gemeint war, so breche ich gern noch eine Lanze in diesem uralten Streit … Wenn man mit VB.NET Code schreibt, schreibt man effektiver, weil man etliche Zwänge, die rein sprachspezifisch sind, nicht beachten muss. Man muss nicht explizit x mal toString() anwenden, wenn für den Compiler klar sein muss, dass in einen String zu konvertieren ist. Man ’sagt‘, dass hier das ‚Ende von if‘ ist, während man in C# froh sein kann, dass die Entwicklungsumgebung zusammenhängende Klammern hervorheben kann und und und. Man ist in C# gegenüber VB einfach zu lange beschäftigt, einfach nur die Syntax ’sauber‘ zu halten. Und das nicht effektiv. Ich weiß, die meisten C#-Propheten sind stolz auf kryptische Syntax, aber das steigert mehr das Ego als den Nutzen. Meiner Meinung ist der Gedanke hinter VB selbst nach so langer Zeit noch nicht radikal genug umgesetzt. Der Code sollte NUR aus Wörtern bestehen – und das kann ruhig (erstmal) in Englich sein (denn das ist eine Standardsprache). Der Compiler muss daraus alles machen, was die Maschine zur Umsetzung braucht. Das ist der Schritt zur Effektivität. Denn das Ergebnis ermöglicht allen Menschen mit gewisser ‚Basisintelligenz‘ ihre Version der Software zur Not sogar dynamisch ins Mikro zu diktieren 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.