Die web.config bei der Installation eines Modules verändern

Je nach Modul gibt es schon mal die Anforderung, dass neue Einträge in die web.config geschrieben werden müssen. Dieses kann man entweder im SourceCode erledigen oder aber die Änderungen in dem DNN Modul Manifest / Definitionsdatei (meinmodule.dnn) definieren. Verfügbar ist das ab der Version 5 von DotNetNuke. Um das zu nutzen, muss man in der Manifest-Datei folgendes hinzufügen:<component type="Config"> <config> <configFile>web.config</configFile> <install> <configuration> <nodes>             ..... </nodes> </configuration> </install> <uninstall> <configuration> <nodes /> </configuration> </uninstall> </config> </component>Wie man sieht gibt es zwei Bereiche. Der Bereich <install> wird während der Installation und der Bereich <uninstall> wird be der Deinstallation von dem DNN Modul ausgeführt.Innerhalb des Tags <nodes> können dann die entsprechenden Einträge hinzugefügt werden. Hier ein Beispiel womit ein HttpHandler hinzugefügt wird:<node path="/configuration/system.web/httpHandlers" action="update" key="path" collision="overwrite"> <add verb="*" path="myhandler.axd" validate="false" type="DNN.Module.Shop.MyHandler, DNN.Module.Shop" /> </node>Weiter Informationen findet man im Wiki auf www.dotnetnuke.com

DotNetNuke Standardcontrol portal:url und die Auswahl "keine Auswahl"

Das DNN Control portal:url ist ja sehr flexibel und damit kann man vieles abfangen. Auwahl von Seiten, Verlinkungen, Benutzern, internes Dateisystem, etc. Wenn das Feld aber kein Pflichtfeld ist der Benutzer auch nachträglich noch die Möglichkeit haben soll den Werte wieder zu entfernen, dann muss bei dem Control eine Property setzen:required="False"Durch diesen Parameter erscheint dann "keine Auswahl" in der Drowdownbox.

Debug-Konfiguration von WAP DNN Modulprojekten unter VS 2008 beim Fehler "virtuelles Verzeichnis"

Bei der Umstellung / Migration der Entwicklungsumgebung von Visual Studio 2003 (für ein Projekt wurden bisher Module für DNN 3.2.2 erstellt) auf Visual Studio 2008 und die Projektart WAP (Web Application Projects), bekam ich immer folgende Meldung bei der Konfiguration vom Server (IIS): Diese Konfiguration ist aber notwendig, damit man das WAP-DNN-Modul Projekt vernüftig debuggen kann. Die Meldung ist zunächst verwirrend, denn unter der angegebenen URL war bereits ein komplett lauffähiges DotNetNuke installiert und die URL war natürlich als Anwendung konfiguriert. Es konnte also nicht im IIS liegen (IIS unter Vista). Die Berechtigungen war auch richtig gesetzt und waren nicht der Grund für diese Meldung. Die Lösung war dann folgende Konfiguration: Bei Projekt-URL habe ich den kompletten Pfad zum Modul eingetragen (also z.B. http://gmsshop/desktopmodules/shopsystem) Damit nun die Verweise z.B. in den ASCX Dateien richtig funktionieren muss zwigend die Option "URL des Anwendungsstam überschreiben" aktiviert werden. Dann die eigentliche URL der DotNetNuke Installation in das dann verfügbare Textfeld schreiben Mit dieser Konfiguration startet Visual Studio 2008 das DotNetNuke Modul auch wieder im Debugmodus

but its type (System.Web.UI.UpdatePanel) is not compatible with the type of control

In unserem DotNetNuke Shop Modul wird im Administationsbereich einiges mit ASP.NET AJAX durchgeführt. Bisher verlief die Installation der Entwicklungsumgebung auch immer ohne Probleme. Bei einem Kollegen, kam es aber zu einer echt blöden Fehlermeldung: DotNetNuke.Services.Exceptions.ModuleLoadException: The base class includes the field 'pnlExtPrice', but its type (System.Web.UI.UpdatePanel) is not compatible with the type of control (System.Web.UI.UpdatePanel). ---> System.Web.HttpParseException: The base class includes the field 'pnlExtPrice', but its type (System.Web.UI.UpdatePanel) is not compatible with the type of control (System.Web.UI.UpdatePanel). ---> System.Web.HttpParseException: The base class includes the field 'pnlExtPrice', but its type (System.Web.UI.UpdatePanel) is not compatible with the type of control (System.Web.UI.UpdatePanel). at System.Web.Compilation.BaseTemplateCodeDomTreeGenerator.BuildFieldDeclaration(ControlBuilder builder) at System.Web.Compilation.BaseTemplateCodeDomTreeGenerator.BuildSourceDataTreeFromBuilder(ControlBuilder builder, Boolean fInTemplate, Boolean topLevelControlInTemplate, PropertyEntry pse) at System.Web.Compilation.BaseTemplateCodeDomTreeGenerator.BuildSourceDataTreeFromBuilder(ControlBuilder builder, Boolean fInTemplate, Boolean topLevelControlInTemplate, PropertyEntry pse) at System.Web.Compilation.TemplateControlCodeDomTreeGenerator. BuildMiscClassMembers() at System.Web.Compilation.BaseCodeDomTreeGenerator.BuildSourceDataTree() at System.Web.Compilation.BaseTemplateBuildProvider.GenerateCode(AssemblyBuilder assemblyBuilder) at System.Web.Compilation.AssemblyBuilder.AddBuildProvider(BuildProvider buildProvider) --- End of inner exception stack trace --- at System.Web.Compilation.AssemblyBuilder.AddBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at System.Web.UI.TemplateControl.LoadControl(String virtualPath) at DotNetNuke.UI.Skins.Skin.InjectModule(Control objPane, ModuleInfo objModule, PortalSettings PortalSettings) --- End of inner exception stack trace --- Eigentlich war alles so weit auch richtig installiert und in einer anderen DNN Installation lief AJAX ohne größere Probleme. Auf dem Rechner war neben ASP.NET 2.0 auch bereits .NET 3.5 installiert und ich dachte mir schon, das es irgendein Konflikt mit den Versionen sein muss. Eine Recherche im Web hat mich dann auf folgendes Ergebnis gebraucht: In der web.config muss der Bereich "runtime" wie folgt angepasst werden:<runtime>      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">        <probing privatePath="bin;bin\HttpModules;bin\Providers;bin\Modules;bin\Support;" />        <dependentAssembly>          <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35" />          <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0" />        </ependentAssembly>        <dependentAssembly>          <assemblyIdentity name="System.Web.Extensions.Design" publicKeyToken="31bf3856ad364e35" />          <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0" />        </dependentAssembly>      </assemblyBinding>    <runtime>  Danach läuft das Modul und die AJAX Funktionen - hier im speziellen das UpdatePanel - wieder ohne Probleme.    

DotnetNuke Game / Battleship Module

Eigentlich habe ich ja ein paar Module (News, FAQ) für DotNetNuke gesucht - dabei bin ich dann über ein Game gestolpert, dass jeder von uns kennt und auch gerne spielt: Schiffe versenken :) Auf der Seite http://www.donein.net/Default.aspx?tabid=58 gibt es sowohl einen Downloadlink als auch die Möglichkeit, das Spiel direkt mal zu testen! Viel Spaß :)

Ein Videoportal auf Basis von DotNetNuke, WCF und MS - Message Queue

Im Netz gibt es zwei Seiten mutlimedia.katholisch.de und www.kirche.tv. Beiden Seiten wurde mit DotNetNuke umgesetzt und sollen so eine Art YouTube darstellen. Natürlich sehr stark spezialisiert auf den Bereich der katholischen Kirche.Die Architektur von diesen Videoportalen ist recht interessant, da hier beide Portale (getrennte Installationen) aus einem gemeinsamen Datenpool bedient werden. Der Lösungsansatz ist DotNetNuke mit WCF zu verheiraten. Die Module zur Darstellung von Videos, zum Upload von Videos und natürlich die Administration von Videos greifen dann nicht wie sonst üblich auf den DataProvider zurück, sonder befragen einfach die laufenden WCF-Services. Die eigentlich "anzeige Module"  - sprich die *.ascx" - greifen aber wie gewohnt auf Controller-Klassen zu, durch die dann eine Kommunikation mit den WCF-Services ermöglicht wird. In den Controllern kann man dann z.B. auch Caching und ähnliches einbauen. Neben der WCF wurde auch die MSMQ (Message Queue) stark genutzt, was gerade im Zusammenspiel mit der WCF sehr viel freude bereitet und denkbar einfach ist. Der große Vorteil bei der Verwendung von MSMQ ist natürlich, dass Prozesse asynchron ablaufen können und der Benutzer nicht warten muss, bis der komplette Workflow-Prozess dahinter abgerabeitet ist. Ein kurzes Beispiel um das zu verdeutlichen: Ein Anwender macht einen Video - Upload durch das DNN-Modul; dieses macht eine erste Validierung der Daten und wenn diese in Ordnung sind, wird eine Nachricht mit allen Informationen in eine transaktionale Message Queue übertragen. Damit ist der Job für das DNN-Modul zunächst erledigt. Ein WCF-Service der permanent die Queue "im Auge" hat, holt die Nachricht ab und bearbeitet diese nun weiter - Daten werden in die Datenbank geschrieben, eine Nachricht zur Konvertierungs Queue abgesetzt, etc.). Gerade bei der Konvertierung von Videos kommt man um einen asynchron Verarbeitung nicht herum, da große Dateien längere Zeit in anspruch nehmen,. Die Konvertierung erfolgt übrigens in das Format Flash. Wenn das Video konvertiert wurde, wertet ein diesmal ei NT-Dienst das Ergebnis aus und berichtet den Status. Für die Konvertierung werden externe Programm eingesetzt und deshalb überwacht das ein NT-Dienst. [Dieser Workflow ist nur sehr grob beschrieben und beinhaltet noch deutlich mehr Schritte]Die beiden Portale laufen nun seit gut 6 Monaten sehr zuverlässig, stabil und schnell. Ein schöner Beweis das man mit DotNetNuke als Basis wirklich so ziemlich alles umsetzen kann und das man DotNetNuke auch wunderbar mit anderen Technologien nutzen kann.Wer ausführlichere Informationen dazu haben möchte, kann sehr gerne mit mir Kontakt aufnehmen...

Eine brauchbare DotNetNuke Sitemap

Ein Kunde wollte in seinem aktuellen DNN-Projekt eine Sitemap für sein Portal erstellen - eigentlich ja nichts ungewöhnliches aber in den letzten DotNetNuke Projekten wurde es bei uns so gut wie nie gebraucht. Habe mir heute die Mühe gemacht und noch mal ein wenig gesucht, welche DNN Module es denn derzeit so auf dem Markt gibt, welche die Anforderungen einer Sitemap erfüllen. Bei all den vielen Treffern habe ich dann die Seite houseofnuke.com bzw. dort das Modul HouseIndex entdeckt und finde die Darstellung dieser Sitemap wirklich klasse. Neben dem Seitenname kann man auch die Keywords und die Beschreibung der Seite ausgeben lassen - echt sinnvoll! Und so kann die Sitemap aussehen:

Neues Authentifizierungssystemen bei DotNetNuke (LiveId, OpenId, CardSpace)

In der kommenden Version von DotNetNuke (DNN 4.6.0) ist ein sehr interessantes Feature die Möglichkeit der Implementierung von neuen Authentifizierungssystemen jenseits von DNN. Nun ist es nicht nur mehr möglich sich gegen DotNetNuke oder einer ADS (Active Directory Service) zu authentifizieren, sondern eine Anmeldung kann nun durch: Cardspace LiveID OpenID Dafür wurde ein "neues" Providermodell für die Authentifizierung implementiert. In den letzten Tagen habe ich für einen Kunden bereits einen eigenen Provider für eine Anmeldung bei der zentralen Golf-Online-Seite erstellt und erste positive Erfahrungen damit gesammelt. Dafür muss man lediglich drei UI-Komponenten entwickeln: Login, Settings and LogOff – jeweils von Basisklassen abgeleitet (AuthenticationLoginBase, AuthenticationSettingsBase and AuthenticationLogOffBase). Die Konfiguration der einzelnen verfügbaren Provider wird über die Tabelle Authentication vorgenommen. Dort wird ganz einfach ein Prefix und die drei UI-Komponenten angegeben. Es ist auch möglich dem Benutzer die Auswahl selber zu überlassen, mit welchem Dienst er sich Authentifizieren möchte – das find ich insgesamt schon ziemlich sexy. Wenn sich der Benutzer über z.B. LiveID angemeldet hat, dann wird nach erfolgreicher Authentifizierung ein Benutzerkonto angelegt oder aber man kann diesen Login mit einem existierenden DNN-Benutzerkonto verknüpfen. In der Datenbank gibt es dafür die Tabelle: UserAuthentication

Alternatives ControlPanel / DotNetNuke Adminpanel

Das Core-Team von DotNetNuke hat in den letzten Versionen schon einiges an der Usability verbessert. Darunter gehört z.B. die Vererbung von Seiten-Rechten innerhalb der Seitenstruktur. In vielen Projekten höre ich aber immer wieder, dass das ControlPanel (dort wo z.B. die Module ausgewählt werden) nicht flexibel genug ist und es Vorteilhaft wäre, wenn man anhand der DotNetNuke spez. Rollen die Funktionen ganz gezielt freischalten kann. Somit könnte man bestimmten Rollen ganz gezielt lediglich ein paar Module zur Verfügung stellen, die diese für ihre tägliche Arbeit benötigen. Der Vorteil liegt ganz klar auf der Hand: Die Komplexität für die Redaktuere wird reduziert. In vielen Fällen werden ja wirklich nur ganz wenige Module für die normale Arbeite benötigt (z.B.Text/HTML, Links, Images). Seit ein paar Monaten verfolge ich eine Projekt, dass das DotNetNuke ControlPanel ersetzt (oder viel mehr eine Alternative bereit stellt). Mit diesem ControlPanel ist es nun endlich möglich die Berechtigungen innerhalb des Controlpanels sehr gezielt zu vergeben. Hier kann man das Modul downloaden Leider gibt es keine SourceCode Version von diesem Modul.