Firefox 5 – Finale Version über FTP Server schon verfügbar

Wenn auch die Offizielle Veröffentlichung von Firefox 5 erst für den 21. Juni geplant ist, so ist die Finale Version bereits jetzt über den FTP Server der Open Source Entwickler verfügbar.

Wer also nicht warten kann oder möchte der kann ab sofort über die nachfolgenden Links die neuste Version des Firefox Browsers herunterladen.

Windows Version

Linux Version

Hier geht es zum Root Verzeichnis der Version 5 mit anderen Versionen wie Mac oder Linux 64 Bit.

BlogEngine.NET – Die Deutschsprachige Community Plattform ist ONLINE

Seit Gestern ist die erste Deutschsprachige Community Plattform für Themen rund um die BlogEngine.NET Open Source Software ONLINE. Eigentlich ist es die erste Community Plattform überhaupt, aber die eben in Deutsch 🙂

Zusammen mit zwei Kollegen (Klaus Bock alias klaus_b und Roland Schumacher alias GENiALi), die selbst schon lange Erfahrungen mit der BlogEngine.NET vorweisen können, habe ich in den letzten Wochen das Gerüst für die Community Plattform geschaffen und Gestern dann für die Öffentlichkeit ONLINE gestellt.

Wir stehen ab sofort auch als Moderatoren im ebenfalls enthaltenen Deutschsprachigen Forum zur Verfügung.

Ich betreibe zur Zeit nur meinen englischsprachigen Blog unter der BlogEngine.NET.

Mein Deutscher Blog, also dieser hier, auf dem Ihr gerade den Beitrag lest, läuft noch unter WordPress. Wobei das tut er auch erst seit Anfang des Jahres, bis dahin wurde der Blog unter dasBlog betrieben. Aber dasBlog wird ja leider nicht mehr wirklich weiter entwickelt. Aber mit BlogEngine.NET gibt es ja einen würdigen Nachfolger als .NET Blog Software.

Eine der spannendsten Aufgaben sehe ich darin auf der neuen Community Plattform über neue Migrationspfade von WP zu BE zu berichten.

Hierbei ist mein Ziel möglichst viel der Funktionalitäten, die ich hier nicht näher beschreiben möchte ebenfalls von WP zu BE zu migrieren. Aber dazu später mehr auf www.dotnetblogengine.de

Wir sehen uns, hoffe ich doch.

Hier geht es übrigens direkt zur Registrierung

DotNetNuke – Dateimanager Ordner Baumansicht wird nicht geöffnet

Auf einem DNN Portal das unter DotNetNuke Version 5.6.2 betrieben wird, kommt es plötzlich zu dem Problem, dass beim Klicken auf das Pluszeichen des Dateimanagers, die Unterordner nicht mehr angezeigt werden.

Die nachfolgende Abbildung zeigt dieses Phänomen:

Es sieht so aus, als ob endlos versucht wird die Verzeichnisstruktur zu lesen und darzustellen. Doch dies wird, wenn es erst einmal zu diesem Verhalten gekommen ist, nicht mehr geschehen, auch wenn man noch so geduldig ist.

Ich habe diese Verhalten auf verschiedenen Systemen gesehen und in einigen Fällen kommt es noch zur Ausgabe einer Fehlermeldung ähnlich der nachfolgenden:

„Laufzeitfehler in Microsoft JScript: Sys.ArgumentException: Cannot deserialize empty string. Parameter name: data“

In anderen Fällen, je nach Umgebung, eingesetztem Browser und Browsereinstellungen kann es aber auch vorkommen, dass keine Fehlermeldung ausgegeben wird.

Also nicht darauf verlassen, dass eine Fehlermeldung ausgeben wird.

Und unbedingt beachten: Dieser Fehler verursacht auf keinem mir bekannten Fall einen Eintrag im DNN Ereignisprotokoll.  Da es sich bei diesem Problem um ein Clientseitiges JavaScript Problem handelt, kann DNN von diesem Fehler nichts mitbekommen und dementsprechend auch keine Eintrag in das Ereignisprotokoll vornehmen.

Wenn dieses Problem auftritt, sollte man unter den Systemeinstellungen in den Erweiterten Einstellungen die Einstellungen der Leistungsoptimierung im Bereich kontrollieren,

Wenn dort als Kompressionseinstellungen „GZip-Kompression“ eingestellt ist, dann sollte diese Einstellung dahingehend geändert werden, dass „unkomprimiert“ ausgewählt ist.

Nun noch die Einstellung speichern und ich bin mir ziemlich sicher, dass der Dateimanager nun wieder funktioniert.

Übrigens scheint dieses kein neues Problem in der Version 5.6.2 zu sein, sondern schon in älteren Versionen vorzukommen.

Also wenn ein solches Problem mit einer älteren Version auftritt, auf jeden Fall die Einstellungen prüfen und gegebenenfalls ändern.

Fehler BC30456: „Framework“ ist kein Member von „DotNetNuke.UI.Skins.Controls.DotNetNuke“

Nachdem ich mit der weiter unten beschriebenen Systemumgebung versucht habe die Source Version von DotNetNuke Version 5.6.2 zu installieren und zu übersetzen habe ich den nachfolgenden Fehler erhalten:

Fehler BC30456: „Framework“ ist kein Member von „DotNetNuke.UI.Skins.Controls.DotNetNuke“

Nachdem ich kurz versucht habe über Google eine Lösung zu finden und dort als Lösung einen Tipp vorgefunden habe der vorschlägt einfach nicht die Source Version zu verwenden, habe ich nur den Kopf geschüttelt und selbst nach einer Lösung gesucht.

Hier aber nun zur Lösung des Problems und zur verwendeten Systemumgebung:

  • Windows 7 Rechner
  • Visual Studio 2010 SP1
  • IIS Express (7.5)
  • DotNetNuke Version 5.6.2 Source Version (diese Version)

Nachdem ich also DNN 5.6.2 auf dem Rechner installiert habe und die Solution in Visual Studio unter IIS Express eingerichtet habe, wollte ich das Gesamte Projekt übersetzen.

Das ist aber mit dem oben beschriebenen Fehler gescheitert.

Um den Fehler zu beheben muss man folgende Änderung in der Datei: jQuery.ascx.vb welche im Unterordner amin/Skins des Website Root Verzeichnises zu finden ist, vornehmen.

Der Aufruf Im Page.Init Event muss wie folgt geändert werden.

Hier der Source des Originalevent

Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init
	DotNetNuke.Framework.jQuery.RequestRegistration()
End Sub

Hier der geänderte Source, man beachte das Global vor dem Verweis auf DotNetNuke

Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Init
	Global.DotNetNuke.Framework.jQuery.RequestRegistration()
End Sub

Nach dieser Änderung kann man die Solution Fehlerfrei übersetzen.

Übrigens habe ich später doch noch einen Hinweis im Web gefunden, welcher die gleiche Lösung parat hält wie die hier von mir beschriebene.

Ich möchte daher an dieser Stelle auch auf diesen englischsprachigen Beitrag hinweisen.

Compilation error in dnn 5.6.2

BlogEngine.NET – Zugriffsstatistiken (Site Stats) einrichten (Google Analytics)

Die BlogEngine.NET 2.0 bietet von Hause aus keine eigene Protokollierung der Webseiten Zugriffe. Das finde ich persönlich auch nicht unbedingt als Nachteil, auch wenn viele andere Blog Engines eine einfache Statistik im Standard bereits beinhalten.

Für die meisten Blog Betreiber wird Google Analytics die erste Wahl wenn es darum geht sich eine Zugriffsstatistik für den Blog einzurichten.

Nachfolgen erkläre ich Schritt für Schritt wie man Google Analytics für einen Blog mit der BlogEngine.NET einrichten kann.

Als erstes müssen wir dazu ein Google Analytics Konto einrichten (Dazu muss natürlich ein Google Konto eingerichtet oder vorhanden sein.).

Hier geht es zu Google Analytics

Entweder man meldet sich mit einem bereits bestehenden Google Konto an, oder man richtet ein neues Google Konto ein.

Nachdem man sich mit seinem Google Account angemeldet hat kann man sich für Google Analytics anmelden.

Nach der Anmeldung geht es an die Eintragung der für die Webseite notwendigen Daten.

Hier werden die Daten der Webseite eingegeben.

Das sollte dann in etwas so aussehen.

Jetzt auf Weiter klicken.

Als nächstes müssen die Kontaktinformationen eingeben werden.

Und wieder auf Weiter klicken.

Nun muss man noch den AGB’S zustimmen und dann auf „Neues Konto erstellen“ klicken.

Fast fertig.

Das Script unter Punkt 2 müssen wir nun noch kopieren und in der BlogEngine einfügen.

Also Script markieren, kopieren und Button Speichern und Fertig klicken.

Nun rufen wir die URL unseres Blogs auf, melden uns an der BlogEngine als Administrator an, rufen dort Settings und dort den Link (Menüpunkt) Custom Code auf.

In das Feld Tracking Script fügen wir nun das Script aus der Zwischenablage ein und speichern die Eingabe.

Ab sofort werden die Zugriffe über Google Analytics erfasst und gespeichert.

Die Informationen stehen nun später zur Ansicht und Auswertung über Google Analytics zur Verfügung

Aber nicht so schnell, das dauer einige Stunden bis sichtbare Daten vorhanden sind, also etwas Geduld und mal einen Tag warten.

DotNetNuke – FolderController – Obsolete Klasse

Im vorläufig letzten Teil meiner kleinen Serie „Clean Code meiner DotNetNuke Module“ geht es Heute um eine ganze Klasse, welche unter DotNetNuke 6.0 nicht mehr weiter verwendet werden soll.

Die Klasse wird mit Obsolete gekennzeichnet und soll durch die neue Klasse FolderManager ersetzt werden.

Allerdings trifft dies nicht für alle Methoden aus der alten Klasse FolderController zu.

Ich hatte in einem meiner Module den nachfolgenden Code eingesetzt um aus einem virtuellen Verzeichnis den absoluten Pfad auf dem Server zu ermitteln.

FolderController folderController = new FolderController();
string mappedTargetModuleFolder = folderController.GetMappedDirectory(portalFolder);

Nun sucht man in der neuen Klasse FolderManager aber vergebens nach einer Ersetzung für diese Methode.

Doch gibt es natürlich auch hiefür eine Lösung.

Im Namespace DotNetNuke.Common.Utilities finden wir die Klasse PathUtils und diese Klasse enthält eine Methode MapPath, die genau die Funktionaltität der zu ersetzenden Methode aus der Klasse FolderController erfüllt.

Und so sieht dann der Code aus:

string mappedTargetModuleFolder = PathUtils.Instance.MapPath(portalFolder);

DotNetNuke – GetModuleDefinitionByName – Obsolete

Heute geht es in meiner Serie „Clean Code meiner DotNetNuke Module“ um die Methode GetModuleDefinitionByName() aus dem Namespace
DotNetNuke.Entities.Modules.Definitions.ModuleDefinitionController.

Der Einsatz dieser Methode war immer schone etwas umständlich da man nicht direkt den Friendly Name verwenden konnte sondern dieser erst über den Umweg des DesktopController ermitteln musste.

Um wie im folgenden Beispiel die ModuleDefId einer Moduls ermitteln zu können, musste man 2 verschiedene Controller Klassen ansprechen.

  • ModuleDefinitionController
  • DesktopModuleController

Diese Methode wurde bereits mit der Version 5.0 ersetzt.

Bis zur Version 5 wurde die Methode wie folgt verwendet:


ModuleDefinitionController moduleDefinitionController = new ModuleDefinitionController();
int newModulDefId = moduleDefinitionController.GetModuleDefinitionByName(
desktopModuleController.GetDesktopModuleByName("DNNPortal-Download").DesktopModuleID, 
"DNNPortal-Download").ModuleDefID;

Hier nun der Aufruf mit der neuen Methode:


int newModulDefId = ModuleDefinitionController.GetModuleDefinitionByFriendlyName("DNNPortal-Download").ModuleDefID;

BlogEngine.NET – Twitter Widget einrichten (BlogEngine von 0 auf 100)

Die BlogEngine 2.0 enthält bereits ein Twitter Widget.



Nachfolgend sehen wir die notwendigen Einstellungen des Twitter Widget.

Hier muss man nun die  „Twitter Account URL“, die wie nachfolgend aufgebaut ist eingeben.

  • http://twitter.com/[TwitterUserName]

Als Beispiel nachfolgend meine „Twitter Account URL“

  • http://twitter.com/SchelianHP

Seine „Twitter Account URL“ dürfte den meisten bekannt sein, anders sieht es jedoch mit der sogenannten „Twitter RSS feed URL“ aus, die Daten für diese URL sind nicht ganz so einfach zu ermitteln.

Das generelle Format dieser URL lautet wie folgt.

  • http://twitter.com/statuses/user_timeline/[TwitterID].rss

Seine  TwitterID kennt vermutlich nicht jeder und kann leider auch nicht einfach auf der Twitter seite abgeufen werden. Neben vielen verschiedenen Möglichkeiten in Drittanbieter Modulen zu Twitter zu seiner TwitterID zu kommen, bevorzuge ich die einfachste Varianten.

Hierzu ruft man einfach die URL http://www.idfromuser.com/ auf.

Nun gibt man seinen Twitter Username in das Eingabefeld ein und betätigt den Button Get ID…

Und Schwups hier haben wir die benötigte ID.

Diese fügen wird dann an der richtigen Stelle in der URL ein, und dann sieht diese wie folgt aus (also mit meiner ID).

  • http://twitter.com/statuses/user_timeline/117727411.rss

Jetzt noch die Anzahl anzuzeigender Tweets und den Aktualisierungsintervall eingeben, fertig.

Das Widget ist sicherlich nicht der letzte Schrei wenn es um Darstellung geht, aber funktional …. einfach und perfekt.


Reihe: „BlogEngine von 0 auf 100“

DotNetNuke – PortalSecurity.HasEditPermissions – Obsolete

In der Serie Clean Code meiner DotNetNuke Module geht es Heute um die Methode PortalSecurity.HasEditPermissions().

Ebenfalls seit der DotNetNuke Version 5.0 ist die Methode HasEditPermissions() aus dem Namespace DotNetNuke.Security.PortalSecurity nicht mehr zu verwenden.

Die beschriebene Methode wird dazu verwendet, zu ermitteln ob der angemeldete Benutzer die Rechte zur Bearbeitung für ein bestimmtes Modul besitzt.

Ein Aufruf, der bis zur Version 5.0 wie folgt ausgesehen hat:


if (PortalSecurity.HasEditPermissions(ModuleId, TabId))

sollte nun durch den nachfolgenden Aufruf ersetzt werden.


if(ModulePermissionController.HasModuleAccess(
SecurityAccessLevel.Edit,
"EDIT",
this.ModuleConfiguration))

Mehr folgt in Kürze

BlogEngine.NET 2.0 – Grundinstallation auf einem W2K8 Server (BlogEngine von 0 auf 100)

Heute war es nun soweit, nach langer Zeit habe ich mich dazu entschieden für meinen Blog (Zunächst mal für meinem Englischsprachigen Blog) die BlogEngine.NET als Blog Software zu verwenden.

Ich werde in einer kleinen Reihe mit dem Namen „BlogEngine von 0 auf 100“ über die Installation, die offenen Wünsche, verfügbare Externsions und eventuelle Anpassungen berichten.

Heute beginne ich mit einer ToDo Liste für die Grundinstallation der BlogEngine.NET auf einer Windows 2008 Server Maschine.

Dies soll, wie aus dem Begriff ToDo Liste schon hervorgeht,  keine detaillierte Beschreibung für jeden einzelnen Schritt werden, sondern lediglich ein grobe Aufstellung, welche Schritte man durchführen muss um die BlogEngine zu installieren. Für die detailliertere Informationen zu den einzelnen Schritten gibt es Unmengen an Hinweise im Internet „Google/Bing“ sei dank.

Herunterladen und auspacken

BlogEngine.NET 2.0 (web)

Das ZIP File habe ich auf meinen Server geladen und dort entpackt.

IIS einrichten

Erstellen eines Anwendungspool und sofort die Identität auf Netzwerkdienst geändert. Das wird benötigt um die erforderlichen Rechte auf das Basisverzeichnis legen zu können und um die integrierte Sicherheit mit dem SQL Server zu konfigurieren.

Als nächstes mit dem IIS Manager eine neue Webseite angelegen, mit dem Root auf das Verzeichnis BlogEngine.Web zeigen lassen.

Rechte vergeben und Konfiguration kopieren

Dem Netzwerkdienst alle Rechte (ja es geht auch etwas kleiner) auf das Root Verzeichnis der Anwendung gegeben.

Da ich die Daten in einer SQL Datebank und nicht in XML Files speichern möchte, sind noch noch folgende schritte notwendig:

Aus dem Unterverzeichnis \setup\SQLServer die Datei SQLServerWeb.config nach web.config umbenennen und die web.config um Rootverzeichnis damit ersetzen.

Siehe auch

Datenbank anlegen und Zugriff einrichten

SQL Datenbank angelegen und auf der neuen DB das MSSQLSetup2.0.0.0.sql script ausführen. Das Script befindet sich im Unterverzeichnis \setup\SQLServer.
Wenn man mit Integrierter Sicherheit arbeiten möchte, nicht vergessen, dem Benutzer Netzwerkdienst Zugriff auf die Datenbank zu geben.

Connection string in der web.config anpassen.

Jetzt kann es eigentlich los gehen, Aufruf der Webseite, vorausgesetzt man hat dazu auch schon die notwendigen DNS Einträge vorgenommen und den richtigen HostHeader im IIS eingetragen.


Reihe: BlogEngine von 0 auf 100