BlogEngine Update 2.5.0.X auf 2.5.011 – Datenbank Update notwendig

Heute Morgen wollte ich „schnell“ meinen BlogEngine betriebenen Blog auf http://blog.schelian.com mit der neuen Version 2.5.0.11 aktualisieren.

Diese Version ist die erste, welche eine komplette Gallery Integration (Installation, Update und löschen) von Paketen enthält.

Da ich einige persönliche Änderungen der BlogEngine vorgenommen habe, musste ich zuerst eine Verschmelzung (Merge) der Original Version 2.5.0.11 mit meiner lokale geänderten Version, die aber schon auf dem Code Version 2.5.0.10 basiert, vornehmen.

Der Merge konnte ohne manuelle Nacharbeiten einfach so durchgeführt werden.

Nach der Aktualisierung meins lokalen Quellcodes habe ich in Visual Studio 2010 einen kurzen Testlauf durchgeführt (mit XML Provider) und konnte keinen Fehler feststellen.

Nun habe ich mein NANT Skript aufgerufen, was mir aus der lokalen Version ein Package zur Aktualisierung meines Servers erstellt.

Das dabei erstellt ZIP File mit der Version 2.5.0.11 (in meiner angepassten Version) dann auf den Server hochgeladen und im Root Verzeichnis der BlogEngine entpackt (natürlich nicht ohne vorher eine Datensicherung durchgeführt zu haben).

Nun den Blog aufgerufen und…..

…. auf den ersten Blick war alles in Ordnung, nur auf den zweiten Blick leider nicht.

Beim Aufruf der Seite Plugins gab es eine Fehlermeldung die sich in weitestem Sinne um folgenden Aufruf gedreht hat.

BlogEngine.Core.Packaging.PackageRepository.GetPackage

Eine kurze Recherche hat das gezeigt, dass das Problem dadurch entsteht, dass diese Methode versucht auf eine Tabelle im SQL Server zuzugreifen, die es „noch“ gar nicht gibt.

Da auf der Codeplex Seite keine Hinweis auf ein erweitertes Datenbankschema zu finden war, hatte ich auch nicht nach einem Skript zur Aktualisierung der Datenbank gesucht.

Es gibt aber tatsächlich ein Script, allerdings mit dem merkwürdigen Zukunftsweisenden Namen „MSSQLUpgradeFrom2.5to2.6„, also einer Aktualisierung die erst beim Update der BE von 2.5 auf 2.6 notwendig sein soll.

Aber gut, es ist nun mal so, dass folgendes Script schon bei einem Update einer Version 2.5.0.X auf 2.5.0.11 notwendig ist:

SET CONCAT_NULL_YIELDS_NULL, ANSI_NULLS, ANSI_PADDING, QUOTED_IDENTIFIER, ANSI_WARNINGS, ARITHABORT ON
SET NUMERIC_ROUNDABORT, IMPLICIT_TRANSACTIONS, XACT_ABORT OFF
GO

--
-- Create table "dbo.be_Packages"
--
CREATE TABLE dbo.be_Packages (
  [PackageId] nvarchar(128) NOT NULL,
  [Version] nvarchar(128) NOT NULL
)
GO

--
-- Create table "dbo.be_PackageFiles"
--
CREATE TABLE dbo.be_PackageFiles (
  [PackageId] nvarchar(128) NOT NULL,
  [FileOrder] int NOT NULL,
  [FilePath] nvarchar(255) NOT NULL,
  [IsDirectory] bit NOT NULL
)
GO

Nachdem ich diese Skript auf der Datenbank ausgeführt habe, war der Fehler behoben und das Update auf Version 2.5.0.11 erfolgreich abegschlossen.

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

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

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.

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

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.

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.

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.

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.

BlogEngine.NET – Blog Software aktualisiert (Update 2.0.0.36 –> 2.0.0.69)

Wenn man sich den kleinen Versionssprung in der Überschrift ansieht „Version 2.0.0.36 auf 2.0.0.69“ dann würde man eigentlich denken, dass es sich dabei im ein marginales Update handelt.

Weit gefehlt, wenn man sieht,was dieses Update für Änderungen mit sich bringt:

  • Änderung des verwendeten NET Framework von 2.0 (NET Framework 3.5) auf 4.0
  • Einführung von Razor
  • Einführung einer Gallery Funktion für Themes (voll implementiert)
  • Einführung einer Gallery Funktion für Externsions und Widgets (zur Zeit nur Download soll aber später auch direkte Installation ermöglichen)
  • … Wer mehr Einzelheiten lesen möchte, kann dies in dem Detaillierten Beitrag von Klaus_b@.NET

Das Update selbst verlief ohne größere Probleme (siehe mein nachfolgendes Problem).

Ich hatte auf einem Server installiert, der noch keine MVC DLL Datein im Global Assembly Cache installiert hatte, und das hatte zur Folge, dass nach dem Update ein Fehler wegen der nicht vorhandenen DLL Dateien für die Verwendung von Razor aufgetreten ist.

Man kann diese Problem auf zwei verschiedene Arten lösen.

Man installiert MVC3 auf dem Server, insofern man vollen Zugriff auf den Server hat.

Man kopiert die notwendige DLL Dateien:

  • Microsoft.Web.Infrastructure.dll
  • System.Web.Helpers.dll
  • System.Web.Razor.dll
  • System.Web.WebPages.Deployment.dll
  • System.Web.WebPages.dll
  • System.Web.WebPages.Razor.dll

in das BIN Verzeichnis des BlogEngine Web Verzeichnisses.

Bevor ich es vergesse, das Update habe ich auf meine neuen Englischsprachigen Blog http://blog.schelian.com durchgeführt.