StyleCop – Manchmal muss man auch Regeln brechen – Rule Suppressions

Jemand, der wie ich, StyleCop zur Einhaltung und Durchsetzung von Coding Styles einsetzt, versucht im allgemeinen möglichst viele der vorgegebenen Regeln aktiviert zu lassen und beim schreiben von Source Code diese Regeln um und einzusetzen um einheitlichen Source Code zu produzieren.

Je nach Einsatzgebiet, globalen Vorgaben oder Absprachen der Entwicklerteams kann es natürlich vorkommen, dass einzelne Regeln generell deaktiviert werden.Dies sollte dann aber wirklich gut überlegt sein, und auch nicht ständig geändert werden und sozusagen zum eigenen Regelwerk werden.

Nun kann es aber trotz dem größten Willen alle aktiven Regeln einzuhalten, an der einen oder anderen Stelle dazu kommen , dass man Code schreibt, der in diesem speziellen Fall genau so gewünscht ist,  aber so wie er geschrieben wurde gegen eine Regel verstößt.

Wenn man ein Tool wie StyleCop einsetzt, dann ist dass Ziel das ein Projekt ohne StyleCop Warnungen durchläuft. Also ohne einen Bruch der Regeln. Wenn aber an einer bestimmten Stelle bewusst eine Regel gebrochen wird, dann sollte dies Möglich sein, sollte aber genau dokumentiert sein.

Um diesem Umstand gerecht zu werden, gibt es die Möglichkeit bestimmte Regeln auf verschiedenen Ebenen zu unterdrücken.

Mit Ebenen sind hier jede Art von Code Elementen gemeint wie:

  • Klassen
  • Methoden
  • Felder
  • Eigenschaften
  • usw.

Doch zuerst möchte ich mal ein solches Beispiel zeigen, bei dem StyleCop eine Warnmeldung ausgibt, ich aber den Code aus genau so und nicht anders schreiben möchte. Wir müssen an dieser Stelle nicht über den Code diskutieren, da er hier lediglich als Beispiel dienen soll.

Hier nun die gewollte Code Variante, die aber von StyleCop angemeckert wird:

string cmd = new StringBuilder("PORT ").
  Append((short)hostBytes[0]).Append(",").
  Append((short)hostBytes[1]).Append(",").
  Append((short)hostBytes[2]).Append(",").
  Append((short)hostBytes[3]).Append(",").
  Append((short)portBytes[0]).Append(",").
  Append((short)portBytes[1]).ToString();
 

StyleCop gibt bei diesem Code die nachfolgenden Meldungen aus:

StyleCop kommt hier nicht mit der Aufteilung der Methodenaufrufe auf mehrere Zeilen klar.

Ich möchte aber auf keinen Fall den folgenden Code in meinem Source Code haben, der würde zwar den Ansprüchen von StyleCop entsprechen aber nicht meinen.

string cmd = new StringBuilder("PORT ").Append((short)hostBytes[0]).Append(",").Append((short)hostBytes[1]).Append(",").Append((short)hostBytes[2]).Append(",").Append((short)hostBytes[3]).Append(",").Append((short)portBytes[0]).Append(",").Append((short)portBytes[1]).ToString();

Alternativ würde StyleCop auch mit dem nachfolgenden Code zufrieden sein. Doch den möchte ich auch nicht.

StringBuilder stringBuilder = new StringBuilder("PORT ");
stringBuilder.Append((short)hostBytes[0]);
stringBuilder.Append(",");
stringBuilder.Append((short)hostBytes[1]);
stringBuilder.Append(",");
stringBuilder.Append((short)hostBytes[2]);
stringBuilder.Append(",");
stringBuilder.Append((short)hostBytes[3]);
stringBuilder.Append(",");
stringBuilder.Append((short)portBytes[0]);
stringBuilder.Append(",");
stringBuilder.Append((short)portBytes[1]);
stringBuilder.ToString();
string cmd = stringBuilder.ToString();

Wenn ich also dich den Code verwenden möchte den StyleCop angemeckert ohne das dadurch der Code angemeckert wird, muss ich StyleCop dazu bringen genau an dieser Stelle die Meldungen zu unterdrücken.

Hierzu verwenden wird aus dem NameSpace System.Diagnostics.CodeAnalysis ein Attribut mit dem Namen SuppressMessage und packen dieses Attribut an die Methode, Klasse oder was auch immer, um die StyleCop Regel genau an der gewünschten Stelle zu unterdrücken.

Nähere Informationen zur Verwendung der “Rule Suppression” für StyleCop findet man hier auf der Codeplex Seite von StyleCop

Nun aber das Beispiel anhand einer Methode um die StyleCop Meldungen für diese Methode zu untedrücken.

[SuppressMessage("StyleCop.CSharp.SpacingRules", "SA1019:MemberAccessSymbolsMustBeSpacedCorrectly")]
internal static string TestRule(byte[] hostBytes)
{
    string cmd = new StringBuilder("PORT ").
        Append((short)hostBytes[0]).Append(",").
        Append((short)hostBytes[1]).Append(",").
        Append((short)hostBytes[2]).Append(",").
        Append((short)hostBytes[3]).Append(",").ToString();

    return cmd;
}

Wobei fogendes gilt:

Für die StyleCop Regeln kommen folgende Kategorien in betracht:

  • StyleCop.CSharp.DocumentationRules
  • StyleCop.CSharp.LayoutRules
  • StyleCop.CSharp.MaintainabilityRules
  • StyleCop.CSharp.NamingRules
  • StyleCop.CSharp.OrderingRules
  • StyleCop.CSharp.ReadabilityRules
  • StyleCop.CSharp.SpacingRules

Als Rule ID muss die jeweilige Rule ID bestehend aus der Nummer und dem Text ab besten aus dem Rules Konfigurations Bereich des SyteleCop Add In herause gelesen werden. (Siehe nachfolgende Abbildung)

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in Allgemeines | 7 Comments

DotNetNuke 6.0 Final Release – Ein letztes großes VB.NET Projekt wird zu Grabe getragen

Mit dem Finalen Release 6.0 des Open Source CMS Frameworks DotNetNuke wird unter anderem auch eines der letzten großen VB.NET Open Source Projekte sein Ende finden.

Da eine Migration eines DotNetNuke 5 Portals nach 6.0 keine größeren Umstände bereiten sollte, ist zu vermuten und auch zu hoffen, dass mit der Version 5.6.3 die letzte VB.NET Version von DotNetNuke veröffentlicht wurde und die zukünftige Entwicklung komplett auf Basis der C# Version fortgeführt wird.

Die Highlights sind:

  • Umstellung des Framework von VB.NET auf C#
  • Die UI/UX wurden komplett überarbeitet (wem es gefällt)
  • Windows Azure kompatibel
  • SQL Azure kompatibel

DotNetNuke 6 kann direkt über das Open Source Community Portal Codeplex heruntergeladen werden.

Hier geht es direkt zum Download

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in News, Open Source | Tagged , , , | Leave a comment

DotNetNuke 6 RC (Release Candidate) steht zum Download bereit

Nach 8 Monaten Entwicklungszeit steht nun seit Gestern Abend der Release Candidat der Version 6, der ersten C# Version von DotNetNuke zum Download zur Verfügung.

Der Release Candidate hat die Build Nummer 2962 und kann auf www.codeplex.com heruntergeladen werden.

Hier geht es direkt zum Download auf Codeplex

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in News, Open Source | Tagged , , , , | Leave a comment

DotNetNuke 6 Beta 2 seit Gestern verfügbar

Irgendwie scheint es die letzen Wochen nicht so viel interessantes gegeben zu haben über dass sich das Schreiben lohnen würde.

Gut Google+ wäre ein Thema, aber darüber haben schon so viele geschrieben, über MVC, Razor und HTML5 schreiben sowieso momentan alle, über die BlogEngine gibt es seit der letzten Version auch nichts neues zu berichten.

Und so kommt es, dass meine letzen Beiträge, und auch dieser wieder, über DotNetNuke handelt.

Nun gut, dann zum eigentlichen Thema dieses Beitrags.

DotNetNuke Version 6 Beta 2 ist steht seit Gestern Abend zum Download bereit.

Da ich diese Version selbst noch nicht getestet habe, hier der Link zum Download und einige Informationen die ich über diese Version bisher zusammentragen konnte:

Hier geht es zum Download

Unbedingt bei den Versionen auf die Build Nummer achten, die Beta 2 hat die Build Nummer 2756. Der Build 2300 ist Beta 1

Und hier die “signifikanten” Änderungen zur Beta 1

  • Modal Popup nur noch standardmäßig für Core Funktionen aktiviert
  • Support für eine neue DNN 6 Manifest Struktur
  • Neue Standard Skins
  • Und hoffentlich ganz viele Fehlerbehebungen ( z.B. IE9 )
  • Installation von Multi-Language Packs

Ich werde sicherlich in den nächsten Tagen diese neue Version auch noch genauer unter die Lupe nehmen.

Und wenn es sich lohnt, werde ich darüber noch einmal ausführlicher berichten.

Übrigens: Im Bereich Mehrsprachigen Inhalt hat sich leider nichts getan.

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in News, Open Source | Tagged , , | Leave a comment

DotNetNuke 5.6.3 seit letzter Nacht verfügbar !

Obwohl alle nur noch über DotNetNuke 6.0 sprechen geht vorerst die Entwicklung der 5. er Version weiter.

Letzte Nacht wurde eine neue Version “DotNetNuke 5.6.3″ zum Download bereitgestellt.

Diese Version war notwendig da es massive Probleme mit DotNetNuke 5.6.2 und dem Internet Explorer 9 (IE9 ) gegeben hat.

Unter anderem wurde in dieser Version das aktuelle Servicepack 2 der verwendeten Telerik Controls integriert.

Außer einer Reihe von Sicherheitsproblemen die gefixt wurden, gab es keine funktionalen Neuerungen in dieser Version.

Diese werden wohl erst wieder mit der Version 6 folgen.

Die Version 5.6.3 gibt es wie immer auf Codeplex.Com

Hier der direkte Link zum Download der Version 5.6.3

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in News, Open Source | Tagged , | Leave a comment

DotNetNuke – Mehrsprachige Portale auch mit der Version 6 noch immer nicht wirklich realisierbar

Vorab die Kernaussage dieses Beitrags für all diejenigen die nicht meinen ganzen Frust und viele Einzelheiten zu dem Thema “Mehrsprachige Portale mit DotNetNuke” lesen möchten.

Auch mit DotNetNuke 6.0 werden im Core Mehrsprachige Portale nicht umzusetzen sein.

Ich hatte gehofft einen solchen Artikel niemals schreiben zu müssen, aber nachdem auch nach 9 Jahren, die DotNetNuke Mannschaft es nicht geschafft hat, DotNetNuke mit echten Mehrsprachigen Funktionalitäten auszustatten, denke ich, dass wir es wirklich aufgeben können, auf eine durchgängige Corelösung zu warten.

Ich hatte die Hoffnung, dass im Zuge der großen Umstellung von VB zu C# nun endlich die weichen gestellt werden, aber leider wurde diese Hoffnung nicht erfüllt.

Nicht jetzt und nicht mit diesem Konzept, dass sicherlich nur von Englischen Muttersprachlern über dem großen Teich verstanden und verteidigt werden kann.

Ich möchte nur kurz das Prinzip des Konzepts erläutern (ausführlicher Lohnt sich wirklich nicht)

  • Start Konzept
    • Es werden alle Seiten und alle darauf vorhandene Module für jede installierte und aktivierte Sprache dupliziert.
  • Ende Konzept

OK, ein klein wenig mehr hat man sich dabei evtl. schon gedacht, aber ich sagte ja, ich wollte nur das Prinzip beschreiben, und viel mehr ist es auch nicht.

Soweit könnte man sich aber mit dem Grundkonzept abfinden, da dieses Konzept zumindest einen Vorteil hätte:

Vorhandene Modul (die Meisten jedenfalls) wären ohne spezielle Anpassung lokalisierbar.

Die Implementierung selbst übertrifft aber an Unübersichtlichkeit alles was ich bisher gesehen habe. das fängt schon damit an, das die Umstellung auf Content Lokalisierung eine Einbahnstrasse ist.

Wer einmal sein Portal auf Content Lokalisierung umgestellt hat, der hat es umgestellt und kann diese Einstellung nicht mehr zurücknehmen.
Hier hilft nur ein Backup, oder sehr aufwendige manuelle Anpassungen und Änderungen in der Datenbank, welche, ich würde mal vermuten “außer mir” noch maximal eine Handvoll Deutsche DotNetNuke Entwickler vornehmen könnten. (Etwas Werbung darf auch mal sein :-) )

Hinzu kommt, dass das Handling dieser Funktionalitäten so “unintuitiv” sind, dass man alleine um diese Funktionalität einem Kunden zu vermitteln mehr Schulungsaufwand benötigen würde, als für alle anderen Funktionen inklusive Systemadministration zusammen notwendig wären.

Erschwerend kommt aber noch hinzu, dass bei diesem Konzept nachfolgende Themen völlig unberücksichtigt sind:

  • DotNetNuke Host Listen
  • Benutzergruppen
  • Taxonomie
  • Suche

Wie über den Teich zu hören ist, sind die Herren Walker und Co. der Meinung, dass alles, so wie es ist gut ist, und wollen an diesem Konzept festhalten. Man hört einfach nicht auf den falschen Weg weiter zu gehen.

Aber es ist auch kein Wunder, wenn man sieht das bereits seit 2003 immer wieder Team Mitglieder oder dem Produkt nahe stehende Entwickler die sich für echte Belange von Mehrsprachigkeit eingesetzt (und auch ausgekannt) haben keine langfristigen Karten im Core DNN Spiel hatten.

Ich erinnere mich, dass bereits im Jahr 2003/2004 eine Version 1.x gab die für den Deutschen (Mehrsprachigen) Markt angepasst war. Personen die an dieser Version mitgearbeitet haben, wurden damals nicht gerade positiv übern Teich betrachtet.

Es liegt nicht daran, dass DotNetNuke Grundsätzlich nicht mit dem richtigen Konzept Mehrsprachig gemacht werden könnte.

Aber eben mit dem richtigen Konzept, den richtigen Leuten  (denen die etwas davon verstehen) und einer notwendigen Lobby um diese Änderungen durchsetzen zu können.

Leider sind die Herren und Schöpfer von DotNetNuke auf diesem Ohr über Jahre hinweg und ich behaupte auch Heute noch immer vollkommen Taub.

Wenn das Konzept der Lokalisierung von statischen Texten in ASP.NET Anwendungen nicht so einfach und vom Framework vorgegeben worden wäre, dann würden wir, so glaube ich wenigstens, Heute noch darauf warten DotNetNuke für nicht Englische Webseite nutzen zu können.

Zumindest ohne ein Unikat zu erstellen, dass dann nicht mehr aktualisierbar wäre.

Natürlich gibt es Drittanbieter Lösungen für Mehrsprachige Portale mit DNN, aber ich finde keine dieser Lösungen funktioniert zu 100% und außerdem gehört dieses Thema nicht in die Hände von Drittanbietermodulen sondern in den Core eine Produkts.

Wenn ich Heute wirklich ein Mehrsprachiges Portal aufbauen muss, dann verwende ich entweder nicht DNN oder falls es DNN sein muss (wegen zu verwendender vorhandener Module), dann nehme ich eine Child Portal Lösung (Für jede Sprache ein eigenes Child Portal), das ist übrigens sehr nahe am “neuen” Konzept der Version 6.0.

Doch mit dieser Lösung sind wenigstens das Taxonomie und Suchprobleme gelöst.

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in Allgemeines, Open Source | Tagged , , , | Leave a comment

DotNetNuke 6.0 Beta – Ein erster schneller Eindruck

Nachdem vor 2 Tagen die erste Beta Version von DotNetNuke 6.0 veröffentlicht wurde möchte ich Heute kurz einen ersten Eindruck, zu den aktuellen Neuerungen und dem Stand der Umsetzung, abgeben.

Hier die Key Feature der Version 6.0

  • Bereits bekannt aber natürlich ein Riesenschritt (Umstellung des Core auf C#)
  • Verwendung von Razor möglich
  • Popup Fenster (JavaScript und noch mehr JavaScript)
  • Seiten Administration komplett geändert
  • Telerik Editor anstelle dec FCK Editors (mal wieder)
  • … und noch einiges mehr
  • Und eigentlich sollte auch mit 6.0 die Content Lokalisierung komplett implementiert sein (Hoffentlich ist das nicht dem Razor Wahn zum Opfer gefallen)

Nach der Installation fällt sofort auf,  dass nichts mehr ohne Javascript geht.

Hier ein Javascript, da ein Popup (wer es mag) und dort wieder ein Script !

Ich finde schon das JavaScript und Popup Fenster an manchen Stellen dezent eingesetzt die Useability erhöhen können, aber wenn es nur noch popt und tabed kann es auch leicht mal unübersichtlich werden.

So ganz sicher scheint man sich aber auch noch nicht zu sein, denn wenn man die neue Seitenadministration sieht, da hat man auf das ganze Popup verzichtet, oder hat man das einfach bisher vergessen ;-)

Und natürlich musste auch bei DotNetNuke unbedingt Razor mit eingebaut werden, ich habe hierzu bereits meine Meinung im Beitrag über die BlogEngine 2.5 RC abgegeben.

Echt kritisch ist aber, dass die Administration eines Portals dieser Beta Version mit dem IE9 quasi nicht möglich ist. Mit Chrome scheint aber soweit alles zu funktionieren.

Ich werde mir in den nächsten Tagen die Beta Version auf jeden Fall noch genauer ansehen und sicherlich auch noch den einen oder wenn nötig auch anderen  Beitrag darüber veröffentlichen.

Stand Heute würde ich aber vermuten, dass dies nicht die letzte Beta Version war, bevor es dann irgendwann zum einem RC kommt.

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in News, Open Source | Tagged , , , | Leave a comment

DotNetNuke – Nach C kommt B oder anders gesagt, nach der CTP3 ist nun die Beta 1 Verfügbar

Heute wurde die erste öffentliche Beta Version von DotNetNuke 6.0 veröffentlicht.

Somit ist nach über 3 Monaten (da wurde die letzte CTP Version veröffentlicht) in der sich nichts neues ergeben hat, nun endlich eine aktuellere Version vorhanden.

Ersten Meldungen zu folge gibt es mit dieser Beta Version Probleme mit dem IE9, aber das ist leider nicht wirklich etwas neues.

Mit Chrome soll es diese Probleme übrigens nicht geben (auch nicht neues :-) )

Hier geht es direkt zum Download der aktuellen Beta Version DotNetNuke 6.0

Schauen wir mal was uns mit dieser Beta erwartet.

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in News, Open Source | Tagged , , , | Leave a comment

The URL ‘….. for Web project ‘….’ is configured to use IIS Express as the web server but the URL is currently configured on the local IIS web server.

Die komplette Fehlermeldung die ich erhalten habe lautet wie folgt:

20110622 - IIS Express

Auch wenn dieser Fehler bei arbeiten an einem DotNetNuke Modul aufgetreten ist, kann dieser Fehler in jedem anderen Web Projekt unabhängig von DotNetNuke auftreten.

Was war geschehen.

Ich habe ein laufendes Projekt, von einem Windows 7 Rechner mit Visual Studio 2010 auf dem auch der IIS7 installiert ist, in ein Mercurial Repository gespeichert, und dann später auf einem zweiten Rechner geklont um auf diesem anderen Rechner einige Änderungen vornehmen zu können.

Nach dem Klonen des Projekts musste ich, da der Rechner auf dem ich den Klone erstellt habe, keinen IIS sondern nur den IIS Express installiert hat die Projekteigenchaften dahingehend ändern, dass das Projekt mit dem IIS Express funktioniert.
Was übrigens auch kein Problem war und einwandfrei funktioniert hat.

Bereits zu diesem Zeitpunkt hatte ich mir tatsächlich schon überlegt, ob es zu Problemen führen könnte, wenn ich das Projekt später wieder eingecheckt und dann auf dem ursprünglichen Rechner aktualisiere. Bin aber, da ich neben dem echten IIS auch den IIS Express auf dem ursprünglichen Rechner installiert habe zu der Überzeugung gekommen, dass es keine Probleme geben dürfte, was sich, wie man hier lesen kann nicht bewahrheitete.

Einige Wochen später, natürlich hatte ich mittlerweile vergessen, dass ich eine Umstellung von IIS auf IIS Express vorgenommen hatte, habe ich das Projekt aus dem Mercurial Repository auf dem ursprünglichen Rechner wieder ausgecheckt, bzw. eigentlich nur aktualisiert.

Und nachdem ich mit Visual Studio das Projekt geöffnet habe, kam es zu dem oben beschriebenen Fehler.

Mit der Fehlermeldung konnte ich erst überhaupt nichts anfangen. Dann fiel mir aber ein das ich ja diese IIS Express Änderungen an dem Projekt machen musste um es auf dem auf dem anderen Rechner zum laufen zu bekommen.

Das eigentliche Problem bei diesem Fehler ist, dass sich das Visual Studio Projekt nicht mehr öffnen lässt und daher auch keine Einstellungen geändert werden können. So dass man nicht einfach die Verwendung des IIS Express wieder ausschalten kann. (Ich hätte natürlich händig auch den IIS Express konfigurieren können, das hätte vermutlich auch geholfen)

Ich habe dann folgende Lösung entdeckt, und möchte diese für mich und gegebenenfalls auch für andere die ein solches Problem haben hier veröffentlichen, damit man,  wenn ein solches Problem wieder auftritt diese Lösung wieder finden kann und nicht wieder nach einer Lösung suchen muss.

So nun aber zur eigentlichen Lösung des Problems:

In der Konfigurationsdatei [Projektname].vbproj.user befindet sich unter der Region PropertyGroup folgende Einstellung:

<PropertyGroup>
       <UseIISExpress>true</UseIISExpress>
</PropertyGroup>

Diese Einstellung ändert man auf false, speichert die Datei, macht ein Reload der Projektdatei.

Und fertig.

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in Development, Tips und Tricks | Tagged , , , , , | 1 Comment

BlogEngine.NET 2.5 RC – Ein klein wenig Enttäuschung kann ich nicht verbergen

Ich glaube nach der Überschrift sollte ich zuerst noch einmal klar stellen, dass ich Pro BlogEngine.NET eingestellt bin, auch wenn man das anhand der Überschrift nicht denken könnte.

Wer meinen Blog schon länger verfolgt weiß aber, dass eher das genaue Gegenteil der Fall ist. Sonst hätte ich sicherlich nicht zusammen mit zwei Kollegen die “Deutschsprachige Community Plattform für BlogEngine.NET” ins leben gerufen.

Nachdem ich mir mit der Community Plattform auch ein Ziel gesetzt habe, das wie folgt lautet:

Die BlogEngine.NET zu einer echten alternative zu WordPress im Deutschsprachigen Raum anzusiedeln.

Bin ich aber über die heutige Entwicklung,  die aus dem aktuellen RC und der aktualisierten Roadmap hervorgeht, eben etwas enttäuscht.

Hier zuerst einmal die Feature der neuen Version 2,5 die seit Gestern als  RC verfügbar ist

  • Upgraded to .NET 4.0
  • Multiple Blogs in Single Installation
  • Razor Theme support (Razor theme included, “Garland-Revisited”)
  • Converted Admin pages to Razor (Dashboard, Extensions, Themes)
  • Install Themes from the BlogEngine.NET Gallery while in the BlogEngine.NET control panel.
  • NuGet support.
  • New language resource files for Estonian and Polish, and other translations updated.
  • Upgraded to jQuery 1.5.2.
  • Upgraded to latest version of tinyMCE WYSIWYG editor, v3.4.3.1.
  • Numerous fixes and improvements.

Und hier noch was für die Zukunft (Stand Gestern) geplant war:

  • Extend functionality of multiple blogs feature
  • Complete gallery integration (handle all packages from admin UI)
  • Build services/APIs to glue BE sites into ecosystem
  • Improve scalability
  • Improve theming engine – more granular with better HTML output
  • Improvements to code base (more Razor, testing etc.)

Das sind doch ganz ordentliche neue Feature und auch die Aussichten für die Zukunft sehen doch ganz nett aus.

Warum also bin ich denn Enttäuscht?

Weil man meiner Meinung nach etwas Technik verliebt auf einen Razor Zug aufspringt, der im jetzigen Stadium keinen wirklichen Mehrwert bringt und dadurch wichtige Ressourcen für etwas verwendet die man besser mit der Implementierung überlebensnotwendiger Funktionalitäten wie der vollständigen Gallery Implementierung für Widgets und Extensions hätte verwenden können.

Was mir auch noch fehlt, ist die Strategie zur Implementierung eines Aktualisierungsframeworks für Widgets, Extension und im besten Fall auch die BE selbst.

Andere Produkte haben so etwas und bevor nicht die Installation und Aktualisierung von Erweiterungen , Themes und Widgets für den “Jungen von Nebenan” so einfach wie das Speichern eine Dokuments ist, wird die BE ein Produkt für Entwickler bleiben.

Und bis dahin wird es auf der Community Seite auch ruhig bleiben, denn die Entwickler die BE als Blog Engine betreiben haben solche Hilfe meistens nicht notwendig, das sind dann eher die, welche andere später mal helfen bestimmte Anforderungen umzusetzen und Fragen zu beantworten.

Aber ich bin guter Hoffnung, dass es eine solche Zukunft für die BlogEngine.NET und dann auch für die Community Plattform geben wird.

Und wenn es meine Zeit erlaubt werde ich selbst einige Ideen zur Implementierung solcher “Jedermann Funktionalitäten” beitragen und umzusetzen.

Twitter del.icio.us Digg Facebook linked-in Yahoo Buzz StumbleUpon
Posted in News, Open Source | Tagged , , , | 4 Comments