Eigentlich nur der Vollständigkeit halber hier die Information das die Version 4.8.0 der Open Source Software DotNetNuke in den letzten Tagen des Jahres 2007 veröffentlicht wurde.
Die Version enthält keine neuen Feature oder Funktionen, es sind lediglich eine Reihe von Fehlern aus der Version 4.7.0 behoben worden. Einen Versionssprung auf 4.8 wäre deswegen sicherlich nicht notwendig gewesen, eine 4.7.1 hätte dafür auf genügt.
Die Version kann hier herunter geladen werden.
Seit Gestern (eigentlich schon vorgestern) steht die erste 4er Version (ASP.NET 2.0 Version) des Announcements Moduls für DotNetNuke zum Download zur Verfügung.
Zum Download der Install und der Source Version geht es hier
Mehr Informationen (in Englisch) gibt es hier
Bitte unbedingt daran Denken, diese Version benötigt ASP.NET 2.0 das bedeutet mindestens DNN 3.3.7 oder aber natürlich DNN Version 4.X
Spätestens beim Debuggen von WPF Anwendungen sollte man eine Default Einstellung des Visual Studio 2008 ändern.
In den Option kann man dem Debugger sagen, er soll nur Code, den man selbst geschrieben hat Debuggen, Code der von einem Designer in Visual Studio erzeugt wird, wird dann nicht mehr beim Debuggen berücksichtigt.
Ein eventuell auftretender Fehler kann dadurch nicht konsequent verfolgt werden.
Beim Debuggen von WPF Anwendungen geht das soweit, dass selbst Fehler im XAML Code nicht mehr mit dem Debugger verfolgt werden können.
Also sollte man in die Optionen gehen und dort die folgende Einstellung vornehmen.
Die Option Enable Just My Code (Managed only) ist per Vorgabe aktiviert. Also einfach die Option deaktivieren und schon verfolgt der Debugger auch Code, der durch Designer erstellt wurden.
In diesem Beitrag geht es um die Einrichtung des Open Source Zugriffsstatistik Tool AWStats in Verbindung mit DotNetNuke.
Zuerst einmal die Voraussetzungen die erfüllt sein müssen, damit man dieses Analyse Tool zusammen mit DotNetNuke einsetzen kann:
Wenn man das Protokoll des IIS verwenden möchte dann sollte man die nachfolgenden Einstellungen dazu verwenden:
Um den Speicherort der Log Dateien zu ermitteln (ja den brauchen wir später) genügt ein Klick auf Eigenschaften:
Dort können wir sehen wo die Log Dateien abgelegt werden und wie sie benannt werden. In unserem Hier abgebildeten Beispiel ist das:
Allgemeine Verzeichnis für Protokolle des IIS D:\Logs und das Unterverzeichnis in dem die Log Dateien dieses web abgelegt werden hat hier den Namen W3SVC1338318087. Also lautet der Zugriffspfad zu den Protokollen D:\Logs\W3SVC1338318087. Darin werden die Logdateien vom IE erstellt.
Um die Einstellungen in DotNetNuke vornehmen zu können muss man sich als Systemadministrator (Host) anmelden. Dann muss man zunächst in den Systemeinstellungen kontrollieren ob, und gegebenenfalls die Einstellungen korrigieren, das überhaupt eine Loginformation erzeugt wird.
Um überhaupt eine Protokollierung der Seitnaufrufe in DotNetNuke zu aktivieren, müssen die beiden Einstellungen wie folgt vorgenommen werden:
Im Feld Protokollzeitraum muss mindesten der Wert 1 (1 Tag) angegeben werden damit ein Protokolleintrag erstellt wird.
Wenn der Wert 0 eingegeben wird, wird das Protokoll deaktiviert (es geschieht also gar nichts, weder in einem Datenbank noch in einem Dateisystem Protokoll).
Im Feld Protokollgröße sollte für normal stark frequentierte Seiten einfach eine 1 eingetragen werden, bei stärker frequentierten Seiten (> 500000 Zugriffe / Monat) sollte man mit höheren Werten experimentieren. Eine 0 in diesem Feld führt ebenfalls dazu dass keine Zugriffsprotokollierung erfolgt.
Um nun die Protokollierung in einem Format zu speichern, welches von AWStats verwendet werden kann um die Zugriffsstatistik zu erstellen, muss noch die Einstellung Portalprotokollspeicher auf Dateisystem eingestellt werden.
An dieser Stelle möchte ich einen Hinweis auf eine nicht richtig verstandene (übersetzte) Einstellung geben. Dazu schauen wir uns einen Teilbereich der Systemeinstellungen, einmal im Original (in Englisch) an, und einmal in der Deutschen Übersetzung:
Hier zuerst der Ausschnitt der Einstellung im Original:
Und hier in der Übersetzung:
Aus dem englischen “Site Log Buffer (Items)” wird Protokollgröße (Einträge).
Protokollgröße impliziert, dass man mit dieser Einstellung die Größe oder Anzahl der Einträge in der Protokolldatei einstellen würde.
Dem ist aber nicht so.
Mit dieser Einstellung gibt man vor ob die Daten des Protokolls gepuffert (Schreibvorgang erst nach Anzahl Einträgen durchführen) oder ungepuffert (nach jedem Eintrag sofort in die Log Datei schreiben) geschrieben werden. Außerdem führt ein Eintrag von 0 dazu dass die gesamte Protokollierung deaktiviert wird.
Technisch könnte man die Einstellungen wie folgt definieren:
Nun aber zurück zu dem eigentlichen Thema dieses Beitrags “Wie richte ich AWStats zusammen mit DotNetNuke ein”.
Nachdem die Einstellungen, wie hier beschrieben, vorgenommen wurden, wird das Zugriffsprotokoll nun im Dateisystem und nicht mehr in der Datenbank erstellt. Die Protokolle werden im Unterverzeichnis Logs des jeweiligen Portal Root Verzeichnisses angelegt (Beispiel wenn DotNetNuke auf C:\DotNetNuke installiert ist, dann findet man die Log Dateien für da Portal 0 (wenn man keine abweichen Benamung vorgenommen hat) im Verzeichnis C:\DotNetNuke\Portals\0\Logs). Diese Information benötigen wir später zur Konfiguration von AWStats.
AWStats kann komplette mit Source direkt von hier herunter geladen werden (Bitte das ZIP File herunterladen).
Die Beispiel Konfigurationsdateien für DotNetNuke kann man hier herunter laden:
Jetzt entpackt man das AWStats Archiv und kopiert alles aus dem Unterverzeichnis wwwroot ist in das Root Verzeichnis von DotNetNuke, das sind folgende Verzeichnisse.
Danach entpackt man die Dateien aus dem Konfigurationsarchiv direkt in das cgi-bin Verzeichnis.
Und jetzt sind noch folgende Anpassungen an den Konfigurationsdateien vorzunehmen:
Falls man den Namen der Konfigurationsdatei awstats.www.myDomain.de.conf nicht ändert, muss man in der Batch Datei Updatestats.bat keine Änderungen vornehmen. Wenn man die Konfigurationsdatei aber umbenennt, muss man den Namen in der Batch Datei anpassen.
Also die Zeile perl awstats.pl -config=www.MyDomain.de -update, so anpassen, dass der Name der Konfigurationsdatei richtig angegeben ist.
Die Konfigurationsdatei ist schon soweit vorbereitet, dass man lediglich für die Einrichtung mit der DotNetNuke Protokoll Datei die Herkunft der Protokolldateien, also den richtigen Pfad eintragen muss. Dazu öffnet man die Datei awstats.www.myDomain.de.conf mit einem Texeditor und sucht folgende Stelle:
LogFile=”C:\DotNetNuke\Portals\0\Logs\ex%YY-6%MM-6%DD-6.log”
Hier ersetzt man nun den Teil C:\DotNetNuke\Portals\0\Logs der Pfadangabe mit dem Pfad den wir aus unserer Installation ermittelt haben.
Nun sucht man den Eintrag:
SiteDomain=www.schelian.de und ersetzt www.schelian.de mit dem Namen der Domain für den AWStats eingerichtet werden soll.
Wenn man das Protokoll vom IE anstelle des DotNetNuke Protokolls verwenden möchte, muss man zusätzlich zum eben genannten Eintrag noch den Parameter LogFormat ändern.
Dazu sucht man den nachfolgenden Eintrag in der Konfigurationsdatei:
LogFormat=”date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status”
und kommentiert ihn durch voranstellen eines # aus.
Anschließend entfernt man das Kommentarzeichen am Anfang der folgenden Zeile.
#LogFormat=”date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken”
So dass diese Zeile gültig ist.
Nun richtet man im Windows Zeitplandienst (Scheduler) noch eine Aufgabe (Task) ein der Alle 6 Stunden die Batch Datei Updatestats.bat ausführt.
Damit ist die Einrichtung von AWStats soweit abgeschlossen, dass AWStats die Protokolldateien analysiert und umfangreiche Statistiken erstellt.
Was nun noch fehlt ist der Aufruf (die Anzeige) der Statistik.
Wenn die Domain www.mydomain.de heißt, dann lautet der Aufruf zur Anzeige der Statistik www.mydomain.de/cgi-bin/awstats.pl.
Noch ein Hinweis zum Schluss:
Sollte man bereits alte Protokolle haben, welche man durch AWStats abarbeiten lassen möchte, so kann ich hier auf einen früheren Beitrag hinweisen, der sich genau mit diesem Thema befasst.
Hier der Link zum Beitrag: http://blog.schelian.de/2005/02/06/AwstatsAlteLogDateienEinlesen.aspx
Eine immer wieder gestellte Frage lautet: Wie bilde ich die Funktion IIf() unter C# nach, oder gibt es direkt eine vergleichbare Funktion unter C#.
Unter C# ist diese Funktion tatsächlich nicht verfügbar, aber wie wir gleich sehen werden, wird sie auch nicht wirklich vermisst, denn C# hat dafür den mächtigen Bedingten Operator ?:.
Eine Logik wie hier unter VB dargestellt (Beispiel: Gib die größere von zwei Zahlen als Rückgabewert an die linke variable zurück):
Dim max As Integer = IIf(x > y, x, y)
Die Variable max bekommt, wenn x größer ist als y den Wert von x, ansonsten (y ist gleich oder größer x) den Wert von y zugewiesen.
kann unter C# unter Zuhilfenahme des ? Operators wie folgt gelöst werden:
int max = (x > y) ? x : y;
Allgemein gesagt hört sich das so an: Der bedingte Operator (?:) gibt abhängig vom Wert eines logischen Ausdrucks einen von zwei Werten zurück.
Etwas näher beschrieben lautet das dann so:
Auf der linken Seite des Operators ist ein logischer Ausdruck, der, wenn man Ihn auswertet, true oder false ergeben kann.
Je nachdem ob er true oder false ergibt wird der Rechte oder linke Ausdruck auf der rechten Seite des Operators ? ausgewertet, also das links neben dem : oder eben rechts davon stehende.
Übrigens können die Ausdrücke sowohl auf der linken als auch auf der rechten Seite des ? Operators durchaus sehr komplex sein, ein weiteres kleines Beispiel zur Demonstration von etwas komplexeren Ausdrücken wird nachfolgend dargestellt:
string currency = "$"; double price = 12.23; double money = (currency == "$")?(price * 1.56):(price);
Die Deutsche DotNetNuke Community DNNPortal.DE feiert Ihren Ihren 3.ten Geburtstag.
Vor 3 Jahren, genau am Nikolausabend des Jahres 2004 habe ich die Webseite der Deutschen DotNetNuke Community http://www.dnnportal.de frei geschaltet.
Die Community besteht heute aus über 4200 registrierten Mitgliedern.
In den Foren der Community findet man über 12000 hilfreiche Beiträge rund um das Thema DotNetNuke.
Weiter so !!
Ich habe bereits in einem früheren Beitrag über die Automatischen Eigenschaften als Spracherweiterung (oder Compilererweiterungen) in C# 3.0 bzw. Visual Studio 2008 berichtet.
Als ich mir das Konstrukt für die sogenannten “Auto-Implemented Properties” näher betrachtet habe, war ich im ersten Moment ratlos wie die Implementierung einer Schreibgeschützten Eigenschaft funktionieren soll, bzw. wie diese Schreibgeschützten Eigenschaften jemals einen Wert zugewiesen bekommen können.
Aber wie gesagt, meine Ratlosigkeit beschränkte sich auf den ersten Moment 
Schauen wir uns das Thema doch in Beispielen an.
Beispiel Klasse:
class Customer
{
public double TotalPurchases { get; set; }
public string Name { get; private set; } // Schreibgeschützt
public int CustomerID { get; private set; } // Schreibgeschützt
}
Der Compiler erzeugt bei diesem Konstrukt eine private aber anonyme variable, auf diese können wir, weil anonym ja nicht zugreifen.
Wie also kann man diese Schreibgeschützten Eigenschaften verwenden?
Da kam mit zuerst der Gedanke, da kommt natürlich eine weitere Neuerung die “Objekt Initialisierer” zum Zuge.
So zum Beispiel:
Customer c = new Customer { CustomerID = 1, Name = “Max Mustermann”}
Aber nein, das geht nicht !
Wenn man dann aber etwas genauer hinsieht, dann liegt die Lösung eigentlich ganz offensichtlich schon in der Art der Definition der Schreibgeschützten Eigenschaft.
Bei der Definition:
public string Name { get; private set; }
Heißt es nicht { get; read only set; }
sondern
{ get; private set; }
Das bedeutet, man erlaubt nur den Private Zugriff auf den Setter.
Das wiederum bedeutet, Zugriffe bzw. Wertzuweisungen, wie die nachfolgenden funktionieren einwandfrei.
Beispiel Konstruktoren:
public Customer()
{
CustomerID = 1;
}
public Customer(int id)
{
CustomerID = id;
}
Beispiel einer Methode der Klasse:
public void incCustomerID()
{
CustomerID++;
}
Zusammenfassend bedeutet dies, dass wir auf die Schreibgeschützten Automatischen Eigenschaften einer Klasse, innerhalb der Klasse, also private, schreibenden Zugriff auf die Eigenschaften selbst haben.
Wir benötigen also gar kein Wissen über die vom Compiler erzeugte private anonyme Variable um schreibenden Zugriff auf die ansonsten Schreibgeschützte Eigenschaft zu haben.
Etwas kurios und auch nicht ganz nachvollziehbar, was da gerade geschehen ist.
Diese Meldung habe ich gerade auf einem Rechner mit Vista bekommen, als der Internet Explorer versucht hat die Seite www.msn.de aufzurufen.
Internet Explorer funktioniert nicht mehr – Ist das wirklich eine Neuigkeit und eine extra Meldung wert. 
Wenn ich das unter einem Windows XP Notebook versuche, dann sehe ich das irgend etwas nicht mit der MSN Seite stimmt, aber die merkwürdige Meldung wie unter Vista bekomme ich nicht.
Hier die MSN Seite auf meinem XP Rechner.
Übrigens mit Firefox kann man auch auf dem Vista Rechner die MSN Seite problemlos aufrufen.
Eine Fehlermeldung wie diese:
“Der Zugriff auf das Steuerelement txtBarcode erfolgte von einem anderen Thread”
oder so ähnlich, deutet daraufhin, dass versucht wird aus einem anderen Thread Zugriff auf ein Control zu nehmen als der in dem das Control erstellt wurde.
Das geschieht zum Beispiel wenn, man im Timer Event oder dem DataReceived Event der SerialPort Klasse aus dem System.IO.Ports Namespace versucht auf ein Control in einem Windows Forms Programm zuzugreifen.
Eine Lösung für das Problem zeigt das nachfolgende Beispiel indem ein Barcode Scanner an die seriellen Schnittstelle angeschlossen ist und der Barcode in der Text Eigenschaft des Controls txtBarcode ausgegeben werden soll.
Hier nun der Code Ausschnitt des DataReceived Events mit Thread sicherem Zugriff auf das txtBarcode Control:
if (this.txtBarcode.InvokeRequired)
{
this.txtBarcode.Invoke((MethodInvoker)delegate()
{
this.txtBarcode.Text = bCode;
}
);
}
else
{
this.txtBarcode.Text = bCode;
}
Da mein Hauptgeschäft nicht in der Erstellung von SQL Abfragen liegt, kommt es immer wieder vor, dass ich nach ein und der gleichen Lösung für ein Problem immer wieder mal recherchieren muss, da ich mir die Lösungen nicht (bzw. nicht immer) merken kann.
Dieser Beitrag fällt unter diese Kategorie (Und nachdem ich es nun aufgeschrieben habe, werde ich es wohl nie mehr vergessen 
, na dann hätte es ja was genutzt dies hier aufzuschreiben.).
Nun aber zum eigentlichen Problem bzw. zur Lösung:
Ich weiß nicht wie oft ich schon mal schnell eine SQL Abfrage machen musste, die alle Daten anzeigt, oder löscht oder was auch sonst immer, welches entweder vor, nach oder in einem bestimmten Jahr einen Eintrag in einem datetime Feld enthält
Bei eigenen Tabellen Entwürfen häufig das Feld “Created”, oder “LastChange” – ein Datenbank Feld mit dem Datentyp datetime.
Nun ist die Abfrage “Select * from <table> where <datetimeField> < 2007″ wie in der Überschrift verwendet syntaktisch nicht falsch, also es wird kein SQL Fehler erzeugt, aber es wird auch nicht das gewünschte Ergebnis angezeigt.
So wie die Abfrage aufgebaut ist, wird das Ergebnis leer sein, da keiner der datetime Werte kleiner sein dürfte als der Wert 2007.
Die korrekte Abfrage (besser gesagt, eine korrekte Möglichkeit) dafür sieht wie folgt aus:
Select * from <table> where DatePart(year,<datetimeField>) <= 2007
Hier wird nun nur nach dem Jahr innerhalb des datetime Ausdrucks verglichen und der Vergleich mit 2007 ist dann richtig.
Mehr über DatePart auf MS TechNet
SQL Profis mögen mir verzeihen wenn ich bei den verwendeten Begriffen nicht immer ganz getroffen habe, aber wie gesagt, SQL Abfragen ist nicht unbedingt mein Spezialgebiet. Weiterlesen