Blog Home  Home Feed your aggregator (RSS 2.0)  
HP's Blog - Monday, February 16, 2009
Hans-Peter Schelian's Weblog
 
# Monday, February 16, 2009

Wer Vorgestern (Valentinstag) die Seite www.dotnetnuke.com besuchen wollte, wurde von einer netten Meldung “Diese Seite ist zur Zeit wegen geplanter Wartungsarbeiten nicht ONLINE, versuchen Sie es später” darüber informiert, dass irgendwelche Update Arbeiten durchgeführt werden. Das war sicherlich nicht das erste mal, dass diese Meldung auf www.dotnetnuke.com oder einer anderen Webseite zu lesen war, aber diese Meldung Vorgestern war dann doch etwas besonderes.

Denn plötzlich ist alles anders (oder doch nicht). –> DotNetNuke geht nun auch Professional (Das ging auch schon vorher und das sogar ohne die PE und ohne die DNN Corp.)

imageAb sofort gibt es also 2 Versionen eine Community Edition (CE) und einer Professional Edition (PE).

Die Frage die sich stellt ist doch: Was ist denn der Unterschied zwischen den Versionen ?

Laut Aussage auf der Webseite www.dotnetnuke.com soll die Professional Edition folgendes sein:

  • Stable (Stabil)
  • Secure (Sicher)
  • Certified (Zertifiziert)
  • Supported (Unterstützt …)

Laut Aussage der DNN Corp. auf www.dotnetnuke.com soll aber auch:

Die CE und die PE keine andere Programmversion sein (Upgrade von CE auf PE ohne Programmupdate möglich)

Die PE ist eine zertifizierte Fehlerbereinigte CE Version – Dabei stellt sich mir die Frage von wem Zertifiziert ? – Von DNN Corp Wink

Und nicht zu vergessen, man erhält auch noch Garantien zur Performance und …. noch eine Menge mehr Marketing Sprüche !

Ich finde es unglücklich dass man hier versucht ein Produkt zu erfinden, welches es “so” gar nicht gibt, wenigstens nicht dann, wenn DNN Corp. das macht was sie sagen/schreiben. Es wäre sicherlich richtiger dieses Produkt zum Beispiel:

DotNetNuke Professional Services (Kann ich diesen Begriff jetzt mit © H-P Schelian verwenden)

zu nennen.

Da wüsste man auch anhand des Namens gleich um was es sich eigentlich handelt.

Aber was hat diese “Neue” PE Version für Auswirkungen auf die Community und vor allem was hat das für Auswirkungen auf den nicht englisch Sprachigen (Insbesondere den Deutschsprachigen) Raum.

Da ich selbst seit vielen Jahren Professionelle Dienste wie Portal und Modulentwicklung, First und Second Level Support, Umsetzung von Mehrsprachigen Portalen sowie Hosting rund um DotNetNuke und vor allem im Deutschsprachigen Raum anbiete sehe ich dieser Entwicklung im Hinblick auf das Geschäft in eben diesem Deutschsprachigen Raum so gut wie gar nicht betroffen.

Wo ich das gerade aufschreibe, fällt mir auf, dass mit Ausnahme das ich noch nie versucht habe mich selbst zu zertifizieren Thinking, der Rest bereits nach DNN PE klingt.

DNN Corp. hat wie viele andere rein Amerikanische Unternehmen / Gruppierungen bis heute nicht verstanden was wir (in nicht englischen Sprachräumen) eigentlich wollen und benötigen. Sie verstehen das Theater um Lokalisierung und Mehrsprachigkeit von Anwendungen noch immer nicht wirklich, oder besser gesagt, es interessiert sie einfach nicht wirklich.

Also ich freue mich endlich mal eine stabile Version zu bekommen, ohne dass ich dazu noch eigene Änderungen am Code durchführen muss, der, selbst wenn ich ihn hundert mal einreichen würde nicht in das Core Produkt eingebaut bekommen würde, ich spreche halt die falsche “Mutter”Sprache.

To be continued … Sarcastic Entschuldigung – Fortsetzung folgt …

DotNetNuke
Monday, February 16, 2009 8:35:05 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [1]  
Autor: Hans-Peter Schelian  |  Trackback
# Friday, February 13, 2009

Von Zeit zu Zeit kommt es vor, dass man ein Verzeichnis welches sich unter Versionskontrolle (Subversion – TortoiseSVN) befindet,  einfach kopieren und aus dieser Kopie die Versionskontrolle entfernen möchte (Entfernen aller .svn oder _svn Verzeichnisse und deren Inhalt). Ich möchte damit eine echte Kopie aller Dateien (mit Ausnahme der Dateien der Versionskontrolle) erhalten welche sich in dem Projekt befindet, damit meine ich auch die Dateien und Verzeichnisse welche von der Versionskontrolle ausgeschlossen sind.

Klar kann man das mit dem Explorer Suchfunktion machen.

Projekt Kopieren und dann in der Kopie nach den Verzeichnissen mit _svn oder .svn (je nach eingestellter Option) suchen und diese dann anschließend markieren und löschen.

Explorer Suchfenster

Ein wie ich finde eleganterer Weg aber ist es dies durch TortoiseSVN selbst erledigen zu lassen.

Und hierzu gibt es eine ganz einfache Methode:

Man markiert das kopierte Verzeichnis, Rechtsklick mit der Maus und Kontextmenü TortoiseSVN und dort das Untermenü Export aufrufen.

Wenn man nun als Zielverzeichnis das Quellverzeichnis selbst angibt, dann stellt TortoiseSVN dies fest uns fragt:

Wollen Sie die Arbeitskopie aus der Versionskontrolle entfernen?

Wenn man nun mit Ja dieses Dialogfeld bestätigt, dann entfernt TortoiseSVN aus dem Verzeichnis alle Dateien und Verzeichnisse der Versionskontrolle.

Als Ergebnis erhält man also eine Arbeitskopie ohne Bezug auf die Versionskontrolle.

Note | Tools
Friday, February 13, 2009 8:04:53 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [5]  
Autor: Hans-Peter Schelian  |  Trackback
# Thursday, February 12, 2009

Nachdem man, Vorausgesetzt man hat das DotNetNuke Starterkit installiert, mit Visual Studio 2008 eine neue Webseite “DotNetNuke Application Framework” erstellt und konfiguriert hat, kommt es dazu (eventuell kommt es auch nur in bestimmten Fällen dazu), dass nach dem ersten Aufruf der fertig eingerichteten Webseite beim nächsten Start (Kompilierung) folgende 6 Fehler in Visual Studio angezeigt werden und die Webseite nicht mehr aufgerufen werden kann:

Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fcklinkgallery" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckCSS" konnte nicht geladen werden Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.FckHtmlEditorOptions" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckinstanceoptions" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckimagegallery" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckStyles" konnte nicht geladen werden.

Da ich an dieser Stelle keine umfangreiche Abhandlung über die Gründe dieses Problems halten möchte folgt hier einfach kurz und knapp ein Workaround.

Man kopiert die Datei “DotNetNuke.FckHtmlEditorProvider.dll” aus dem BIN\Provider Verzeichnis der DotNetNuke Installation in das BIN Verzeichnis der DotNetNuke Installation.

Nun einfach das Projekt neu übersetzen “Webseite erstellen” – Fertig !!!!

Dieser Workaround trifft auf folgende Konfiguration zu:

  • Windows XP SP3
  • Visual Studio 2008 SP1
  • DotNetNuke Version 5.00.00
  • FckHtmlEditorProvider Version 2.0.2.1
DotNetNuke | Entwicklung
Thursday, February 12, 2009 2:55:25 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback
# Wednesday, February 11, 2009

Während der Installation von DotNetNuke 5 wird die Verwendung von Ajax 1.0 automatisch eingerichtet.

Das geschieht unter anderem dadurch, dass eine System.Web.Extension DLL Datei in das BIN Verzeichnis von DotNetNuke kopiert wird.

Wenn man sich später am Portal als Host Administrator anmeldet und die Host Einstellungen öffnet findet man dort einen Link mit dem man das Portal auf das aktuelle Framework (Ajax Version 3.0 welches mit dem ASP.NET Framework 3.5 ausgeliefert wird) umstellen kann (siehe nachfolgende Abbildung).

Update Site to current Framework

Mit dem betätigen des Links werden 2 Dinge durchgeführt:

  • Die Web.Config wird für Ajax 3.0 eingerichtet
  • Die System.Web.Extension DLL wird aus dem BIN Verzeichnis von DotNetNuke gelöscht.

Das ganze funktioniert, soweit ich das bisher beurteilen kann, sehr zuverlässig.

Und trotz der Zuverlässigkeit dieser Funktion kann es später unter bestimmten Umständen sehr leicht zu folgendem Fehler kommen:

An error has occurred. DotNetNuke.Services.Exceptions.PageLoadException: Object reference not set to an instance of an object. ---> System.NullReferenceException: Object reference not set to an instance of an object. at DotNetNuke.UI.Utilities.MSAJAX.get_IsInstalled() at DotNetNuke.UI.Utilities.MSAJAX.RegisterStartupScript(Page objPage, String Key, String Script) at DotNetNuke.UI.Utilities.ClientAPI.RegisterStartUpScript(Page objPage, String key, String script) at DotNetNuke.Framework.DefaultPage.InitializePage() in C:\dnn5\Website\Default.aspx.vb:line 202 at DotNetNuke.Framework.DefaultPage.Page_Init(Object sender, EventArgs e) in C:\dnn5\Website\Default.aspx.vb:line 452 at System.Web.UI.Control.OnInit(EventArgs e) at System.Web.UI.Page.OnInit(EventArgs e) at DotNetNuke.Framework.PageBase.OnInit(EventArgs e) in C:\dnn5\Library\Framework\PageBase.vb:line 545 at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) --- End of inner exception stack trace ---

Die Ursache für dieses Problem ist. das nach der Umstellung des Framework, aus welchem Grund auch immer, die System.Web.Extension DLL Datei wieder im BIN Verzeichnis von DotNetNuke vorhanden ist.

Das geschieht natürlich nicht aus versehen oder von selbst, aber durch eine Sicherung die man zurückspielt oder durch Verwendung einer Versionsverwaltung kann das ganz schnell geschehen.

Abhilfe schafft das einfache löschen dieser System.Web.Extension DLL Datei aus dem BIN Verzeichnis von DotNetNuke.

Eventuell muss man noch den Applikation Pool abschießen oder alternativ einfach die web.config mit einem Editor öffnen und speichern, damit dadurch das Portal neu gestartet wird.

DotNetNuke | Installation
Wednesday, February 11, 2009 5:42:57 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [1]  
Autor: Hans-Peter Schelian  |  Trackback
# Monday, February 09, 2009

Beim Testen einer Software “Sync2” bin ich heute wieder einmal über eine “Übersetzung der lustigen Art” gestolpert.

Wie auf der nachfolgenden Abbildung zu sehen ist, kann man für den Synchronisationstyp zwischen Automatisch und Handbuch Confused auswählen.

image 

Manchmal sollte man doch besser Handbuch manuell übersetzen statt automatisch Big Grin

Allgemein | Dies und Jenes
Monday, February 09, 2009 4:55:25 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback
# Tuesday, February 03, 2009

Nachdem ich einige Aufräumarbeiten in den Inhalten meiner OneNote Notizbücher durchgeführt hatte, war mir aufgefallen dass die Dateigröße der einzelnen OneNote Dokumente (*.one Dateien) trotz nun erheblich weniger Inhalten noch immer unverändert groß waren.

In meinem speziellen Fall der “Nicht abgelegten Notizen” führte das zum Beispiel dazu, dass obwohl nun keine Notiz mehr enthalten war, die Dateigröße noch immer über 9 MB betragen hat.

Nachdem ich weder in der OneNote Hilfe noch im Internet auf Anhieb fündig geworden bin (ich hatte nach komprimieren bzw. verkleinern von OneNote Dokumenten gesucht), habe ich die Optionen von OneNote durchsucht und bin in der Kategorie “Speichern” dann doch noch fündig geworden.

“Dateien optimieren”

Dieser Begriff war mit bisher neu und da ich sicherlich beim nächsten mal wieder nicht weiß das mit Dateien optimieren, komprimieren gemeint ist, erstelle ich diesen Blog Beitrag.

Dateien optimieren - Komprimieren - Verkleinern

Als Gedächtnisstütze sozusagen Light bulb

Allgemein | Tips und Tricks
Tuesday, February 03, 2009 10:27:43 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [2]  
Autor: Hans-Peter Schelian  |  Trackback
# Tuesday, January 06, 2009

Hintergrund

In einer Windows Form Applikation wird in einer Form ein DataGridView verwendet das je nach Bedarf Schreibgeschützt (Alle Spalten) oder zur Eingabe von Daten (nicht Schreibgeschützt) verwendet werden soll. Soweit würde die Anforderung auch kein Problem darstellen, wenn - aber dazu lest einfach den Rest des Beitrags.

Nun ist es aber so, dass auch in der Variante indem das DataGridView als Eingabe (also nicht Schreibgeschützt) verwendet wird, die eine oder andere Spalte des DataGridView sehr wohl (zur Zeit der Entwicklung, also nicht zur Laufzeit) auf Schreibgeschützt gesetzt wurden.

Eigentlich sollte das ganze kein Problem darstellen, also "Einfach sein", wie es im Lied der FANTA4 beschrieben ist, aber wie geht es im Lied weiter; "is es aber nicht", und genau so ist es auch in dem hier beschriebenen Fall.

Das Problem liegt daran, dass durch das setzen der ReadOnly Eigenschaft des DataGridView auf True das DataGridView "vergisst" welche Spalten des DataGridView während der Entwicklungszeit auf ReadOnly gesetzt wurden.

Nachdem man während der Laufzeit die ReadOnly Eigenschaft des DataGridView einmal auf True und dann später wieder zurück auf False gesetzt hat, sind alle Spalten, auch diese die vorher ReadOnly waren plötzlich nicht mehr Schreibgeschützt.

Die Idee

Die Idee der nachfolgenden Lösung war schnell entstanden und wird im folgenden beschrieben.

Beim Start der Windows Form (am besten direkt im Konstruktor) muss man die Information der Schreibgeschützten Spalten sichern, und diese nachdem die ReadOnly Eigenschaft des DataGridView zurück auf False geändert wurde, einfach wieder auf die ursprünglichen Werte herstellen.

Die Lösung

Um die Information, welche Spalten beim Start der Windows Form Schreibgeschützt sind zu speichern, verwende ich ein typisiertes Array von int Werten um den Spalten Index der Schreibgeschützten Spalten zu sichern.

private List<int> saveReadOnlyColumn;

Die Logik zum Speichern der Informationen habe ich in eine eigene Methode (siehe nachfolgenden Code der Methode saveReadOnlyColumnInformation) ausgelagert, welche ich dann einfach am Ende des Konstruktor aufrufe.

private void saveReadOnlyColumnInformation()
{
    saveReadOnlyColumn = new List<int>();

    foreach (DataGridViewColumn o in dgVerladung.Columns)
    {
        if (o.ReadOnly)
        {
            saveReadOnlyColumn.Add(o.Index);
        }
    }
}

So nun haben wir die Informationen der Schreibgeschützten Spalten im typisierten Array für den späteren Gebrauch gespeichert.

Dann kümmern wir uns nun noch darum, diese gespeicherte Information immer dann wenn die ReadOnly Eigenschaft auf False gesetzt wurde, wieder auf die Startwerte zurücksetzen.

Hierzu können wir einfach den ReadOnlyChanged Event des DataGridView verwenden, welcher immer dann ausgelöst wird, wenn man im Code die ReadOnly Eigenschaft ändert.

Nachfolgend ist der Code dargestellt um die vorher gespeicherten Schreibgeschützten Spalten wieder herzustellen

private void dgVerladung_ReadOnlyChanged(object sender, EventArgs e)
{
    if (dgVerladung.ReadOnly == false)
    {
        foreach (int i in saveReadOnlyColumn)
        {
            dgVerladung.Columns[i].ReadOnly = true;
        }
    }
}

 

Der Vollständigkeit halber hier noch der Code des Konstruktor's (Hier erklärt die Zeile 4) dargestellt.

public formPlanungen()
{
    InitializeComponent();
    saveReadOnlyColumnInformation();
    Application.Idle += new EventHandler(Application_Idle);
}
Programmierung | Code | Tips und Tricks | C#
Tuesday, January 06, 2009 11:26:34 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback
# Tuesday, December 30, 2008

Nachdem bereits die letzten Versionen (seit über 2 Jahren) von DotNetNuke keine aktualisierte Dokumentationen enthalten haben, wird leider auch mit der aktuellen Version 5.0 eine weitere Dokumentation's Mogelpackung zum Download bereitgestellt.

Das mit DotNetNuke 05.00.00 Docs bezeichnete Download enthält nur alte Dokumentationen (letzte Aktualisierung am 21.06.2006) .

Dann werden wir wohl die dringenden Fragen doch im Forum der Deutschen DotNetNuke Community klären müssen.

Hierzu habe ich auch einen neuen Bereich im Forum eingerichtet.

DotNetNuke | Open Source
Tuesday, December 30, 2008 10:31:10 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback
Copyright © 2010 Hans-Peter Schelian - Schelian IT Beratung. All rights reserved.