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.

Welche web_mediumtrust.config greift denn unter dem Net-Framework 3.5

Unter bestimmten Umständen muss man beim Betrieb einer Web Seite die unter Medium Trust betrieben wird Änderungen an der Medium Trust Konfiguration vornehmen.

Die Konfiguration hierfür wird in der web_mediumtrust.config vorgenommen.

Laut dokumentation befindet sich die Datei in folgendem Verzeichnis:

 %windir%\Microsoft.NET\Framework\{Version}\CONFIG 

Doch was ist wenn die Webseite unter NET Framework 3.5 Betrieben wird, da gibt es dieses Verzeichnis erst gar nicht.

Und das ist eigentlich auch klar, denn der NET Framework 3 und 3.5 sind lediglich Erweiterungen des FW 2. Erst mit dem NET Framework 4.0 wurde ein komplett neuer Framework veröffentlicht.

Und genau das spiegelt sich auch in dem vorhandensein, oder nicht vorhandensein der Config Dateien wieder.

Somit ist die Antwort auf die in der Überschrift gestellten Frage wie folgt:

Die web_mediumtrust.config Datei zur Änderung des Medium Trust verhalten einer unter dem NET Framework 3.5 betriebenen Webseite befindet sich im Verzeichnis

 %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG 

Übrigens gilt das bisher geschriebene nur für 32 BIT Windows Betriebssysteme, unter einem 64 BIT Betriebssystem findet man die config Dateien unter folgendem Verzeichnis:

 %windir%\Microsoft.NET\Framework64\v2.0.50727\CONFIG 

DotNetNuke und NET Framework 2.0 SP 1

Ich möchte in diesem Beitrag nicht ergründen, ob das von mir geschilderte Problem durch DotNetNuke oder den Service Pack 1 für das NET Framework 2.0 verursacht wird. Fakt ist auf jeden Fall das dieses Problem in der von mir beschriebenen Konstellation auftritt.

Das Problem stellte sich bei mir wie folgt dar (Windows XP Rechner):

  • Source Version von DotNetNuke 4.08.00 entpackt (C:\DNN_4_8_0).
  • development.config nach web.config umbenannt (Alle Einstellungen belassen)
  • Virtuelles Verzeichnis (dnn488) auf Localhost angelegt.
  • Verzeichnisrechte (C:\DNN_4_8_0) für ASPNET Benutzer (ALLE Rechte) gesetzt.
  • Internet Explorer, URL (localhost/dnn488) des virtuellen Verzeichnis eingegeben und aufgerufen.
  • Installationswizzard mit Auto ausgeführt.
  • Installation ist einwandfrei durchgelaufen.
  • Nun Link zum Start des Portal aufgerufen –> Nix.

Im IE einfach nur warten…

Mit Firefox bekommt man eine Meldung dass man sich in einer Endlosschleife befindet und man nie ein Ergebnis erzielen wird

Nach einigen Recherchen und Versuchen (wenn man anstelle der development.config die release.config verwendet geht es übrigens) war klar wo das Problem liegt.

<trust level="Medium" originUrl=".*" />

Der oben dargestellt Eintrag für dazu dass man in ein ewiges Redirect Status Codes 302 gerät.

Auf einem Entwicklungsrechner kann man einfach diese Zeile in der web.config auskommentieren und schon funktioniert der Aufruf des Portals wie erwartet.


Das Problem hat übrigens nichts mit der verwendeten DotNetNuke Version 4.8.0 zu tun, es tritt sowohl bei den neuen Versionen 4.8.1 und 4.8.2 als auch bei früheren Versionen 4.5.3 und 4.6.2 auf.

NET Framework – Bereit für die Debug Session

Auch wenn schon … was weiß ich wie viele diese Nachricht „. NET Source Code veröffentlicht“ seit Gestern veröffentlicht haben, mache ich meinen Beitrag unter dem Motto „Eigene Notizen“.

Hier also jetzt vor allem aber nicht ausschließlich für mich selbst:

Der Source Code für das NET Framework (wenigstens einen Teil davon, siehe nachfolgende Auflistung) wurde von Microsoft veröffentlicht.

Für diese Assemblies steht der Source Code zur Verfügung:

  • Mscorlib.DLL
  • System.DLL
  • System.Data.DLL
  • System.Drawing.DLL
  • System.Web.DLL
  • System.Web.Extensions.DLL
  • System.Windows.Forms.DLL
  • System.XML.DLL
  • WPF (UIAutomation*.dll, System.Windows.DLL, System.Printing.DLL, System.Speech.DLL, WindowsBase.DLL, WindowsFormsIntegration.DLL, Presentation*.dll, some others)
  • Microsoft.VisualBasic.DLL

Der Source Code steht zur Zeit nur in Verbindung mit dem Debugger in VS2008 zur Verfügung, ein Download des gesamten Source Code ist „noch“ nicht verfügbar, soll aber wohl auch noch folgen.

Wie man VS2008 konfigurieren muss, damit man in das Framework hinein Debuggen kann, wir ausführlich in dem Blog Beitrag von Shawn Burke beschrieben.

Der Source Code ist unter der Microsoft Referenz Lizenz (oder wie ich sie nenne Peep Show Lizenz) veröffentlicht. Die sagt hauptsächlich aus:

  • Gucken -> Erlaubt !
  • Alles andere verboten

Ich bin gespannt ob dieses Lizenzmodell richtig verstanden wird, es gibt leider viele die eine Verfügbarkeit des Source Code gleichsetzen mit Open Source. Und selbst bei Open Source wird häufig die Lizenz nicht wirklich beachtet.

Na mal sehen wie das ausgeht!

PS: Ich habe das übrigens schon getestet, ist wirklich eine schöne Sache, mal schauen wann ich es dann auch mal wirklich brauchen kann.

Na ja auf jeden Fall können wir jetzt MS mit der Meldung eines Fehlers auch gleich einen Vorschlag für die Behebung schicken! smile_teeth

Cookies unter NET Framework 2.0

Geändertes Standardverhalten von Cookies unter NET Framework 2


Ich hatte bereits in einem anderen Blog über das Thema in Bezug auf DotNetNuke geschrieben, aber es hat ja eigentlich nichts spezielles mit DotNetNuke zu tun, sondern es ist eigentlich ein Thema des NET Framework’s im speziellen des NET Framework 2.0.


So möchte ich an dieser Stelle noch einmal kurz das Thema Cookies und das geänderte Standardverhalten unter NET Framework 2 in diesem Beitrag beschreiben.


Zuerst einmal die reinen Fakten:



  • Unter NET Framework 1.1 wurde die Gültigkeit eines Cookies automatisch auf 50 Jahre gesetzt (ja 50 Jahre).
  • Unter NET Framework 2.0 wird ein die Dauer der Gültigkeit eins Cookies auf Standard 30 Minuten gesetzt.

Um die Gültigkeit eines Cookies unter ASP.NET 2.0 zu verändern ist der folgende Eintrag in der web.config zuständig.


Je nach Anwendung kann der Eintrag etwas anders aussehen, nachfolgend 2 Beispiele.


Beispiel DotNetNuke (Version 4.5.3 Standardwert)

Original Eintrag

    <authentication mode=“Forms“>
      <forms name=“.DOTNETNUKE“ protection=“All“ timeout=“60″ cookieless=“UseCookies“ />
    </authentication>


In dieser Version von DotNetNuke beispielsweise ist der Eintrag der Standardwert timeout=“60″ bedeutet 60 min.

Mögliche Änderung

    <authentication mode=“Forms“>
      <forms name=“.DOTNETNUKE“ protection=“All“ timeout=“2880″ cookieless=“UseCookies“ />
    </authentication>


Der oben stehende Eintrag bedeutet 48 Stunden Cookies Gültigkeit.


Beispiel dasBlog (Version 2.0.7226.0)

Original Eintrag

<authentication mode=“Forms“>
     <!– NOTE: If you want to run MULTIPLE dasBlogs on the SAME Domain Name
      include the path in each blog’s Web.Config like path=“/dasblog1″ and path=“/yoursite“  as appropriate. –>
       <forms name=“.DASBLOGAUTH“ protection=“All“ timeout=“60″ path=“/“ cookieless=“UseCookies“ />
</authentication>

Mögliche Änderung

<authentication mode=“Forms“>
     <!– NOTE: If you want to run MULTIPLE dasBlogs on the SAME Domain Name
      include the path in each blog’s Web.Config like path=“/dasblog1″ and path=“/yoursite“  as appropriate. –>
       <forms name=“.DASBLOGAUTH“ protection=“All“ timeout=“525600″ path=“/“ cookieless=“UseCookies“ />
</authentication>


Der oben stehende Eintrag bedeutet zum Beispiel 1 Jahr Cookies Gültigkeit.


Allgemeiner Hinweis:

Nachdem man diesen Eintrag in der web.config geändert hat sollte man trotzdem noch zusätzlich den Cache löschen, oder einfach das web neu starten, damit das Cookies tatsächlich das neue Timeout erhält.