HttpRequestValidationException 0x80004005 A potentially dangerous Request.Form value was detected from the client

Bei der Umstellung eines ASP.NET Projektes auf das Framework 4.0 wurde bei bestimmten Eingabedaten immer der Fehler geworfen:System.Web.HttpRequestValidationException (0x80004005): A potentially dangerous Request.Form value was detected from the client (_dataTextBox="...bitkarte (<print template="pay...").   at System.Web.HttpRequest.ValidateString(String value, String collectionKey, RequestValidationSource requestCollection)   at System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection nvc, RequestValidationSource requestCollection)   at System.Web.HttpRequest.get_Form()Dieses konnte man unter ASP.NET 2.0 durch ein @pagedirektive unterdrücken bzw. die Filterung ausschalten. Bei ASP.NET 4.0 ist dieses per @pagedirektive aber nicht mehr per Default möglich, es gibt aber die Möglichkeit die RequestValidierung per Eintrag in die web.config wieder in den Modus "ASP.NET 2.0" zu versetzen, damit das Verhalten gleich bleibt. Dafür ergänzt man die web.config wie folgt:<httpRuntime requestValidationMode="2.0" /> Weiter Informationen gibt es in der MSDN.

Convert VS2003 Class Library to VS2008 Web Application Project

Bei der Weiterentwicklung eines recht alten Portals stand ich nun vor der Aufgabe eine aktuelle Entwicklungsumgebung aufzusetzen. Die bisherige Umgebung war DNN 3.2.2 und nun wurde das Portal auf die aktuelle Version von DNN (4.x) aktualisiert. Da ich auch nicht mehr mit Visual Studio 2003 entwickeln wollte, habe ich den SourceCode das Modul mit dem Conversion Wizard auf die aktuelle VSS Version 2008 konvertiert. Das Projekt vom Type ClassLibrary konnte aber nicht vernüftigt debugged werden, daher habe ich beschlossen das Projekt als WAP (Web Application Project) weiterzuentwickeln.Dafür muss man (nach erfolgreichem Durchlaufen des Conversion Wizard von VS2008) die Projektdatei mit einem Editor öffnen und anschließend die Zeile<ProjectType>Local</ProjectType>gegen <ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>tauschen. Nach dem erneuten Öffnen der Projektmappe / des Projektes im Visual Studio wird diese nun als WAP angezeigt. Nun muss man nur noch die einzlnen ASCX / ASPX in eine Web-Anwendung konvertieren. Das ist auch sehr einfach zu erledigen: Die gewünschten Dateien Auswählen und im Kontextmenü den Punkt "In Webanwendung konvertieren" wählen. Nun werden im Hintergrund die *.designer.cs Dateien angelegt und gleichzeitig die Codebehind-Klassen als "partial" gekennzeichnet. Schon ist das Update von einer Class Library in ein Web Application Project fertig!Achso: Bitte die Konfiguration überprüfen und evtl. Anpassen...

ASP.NET 2.0 Validatoren JavaScript Bug missing ; before statement

Bei der Entwicklung von DotNetNuke-Modulen (bzw. auch bei "normalen" ASP.NET Anwendungen) verwende ich recht häufig die Möglichkeit, Usercontrols (ascx) dynmaisch zur Laufzeit anzuzeigen / nachzu laden. Der entsprechende Quellcode dafür ist nicht wirklich neu und sieht so aus:PortalModuleBase objToLoad = this.LoadControl(_ControlToLoad) as PortalModuleBase; objToLoad.ID = System.IO.Path.GetFileName(_ControlToLoad); objToLoad.ModuleConfiguration = this.ModuleConfiguration; this.Controls.Add(objOrderCtrl); Wichtig dabei ist die Zeile, wo die ID des Controls gesetzt wird, damit die Resourcendateien durch DotNetNuke (durch die Property LocalResourceFile) angesprochen werden können. Bei der Verwendung einer Templateengine für ein Modul und der gleichzeitigen Verwendung von Standard ASP.NET 2.0 Validatoren, bekam ich im Browser immer die Javascript-Fehlermeldung  "missing ; before statement". Nach kurzer Recherche habe ich die Ursache gefunden: In den ID's von den Controls wurde ein Punkt verwendet und damit kommt JavaScript bzw. der JavaScript-Code der ASP.NET Validatoren nicht zurecht. Nach Abänderung der ID Zuweisung auf folgende Zeile:objToLoad.ID = System.IO.Path.GetFileNameWithoutExtensi(_ControlToLoad); funktionieren sowohl die Resourcendateien als auch die Validatoren wieder ohne Probleme.

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.    

Videoportal, Video konvertierung und FFMPEG

Das ich im letzten Jahr eine Videoportal Software auf Basis von DotNetNuke mit WCF Services im Backend entwickelt habe, ist hier ja schon ein paar mal erwähnt wurden. Die bis jetzt aufgesetzten Videoportale können natürlich auch die hochgeladenen Videos in Flash konvertieren (sorry Silverlight ;-)).Aktuell wird dafür das Tool FFMpeg genutzt, dass auch einen guten Dienst leistet und recht flexibel ist. Durch die asyncrone Entkopplung der einzelnen WCF Services ist auch so ein Command-Line Tool im Hintergrund kein wirkliches timing Problem. Heute habe ich per Zufall aber gesehen, dass es nun .NET Lib für die Konvertierung gibt - getestet habe ich diese noch nicht - könnte aber evtl. eine denkbare Alternative sein. Laut Website auch für den Einsatz in webbasierter Software gut geeignet. Die Lib ist kostenlos, wer den SourceCode haben möchte, muss dafür ein paar Dollar hinlegen. Mehr Infos gibt es hier: http://www.intuitive.sk/fflib/

IE und die Option "Anmeldedaten merken"

Wer sich wundert das die Funktion "Anmeldedaten merken" im IE nicht funktioniert und sich ebenfalls darüber ärgert, für den habe ich nun eine Lösung (vielmehr habe ich im Web eine gefunden). Im Blog auf www.dotnetnuke.com habe ich einen Beitrag gefunden der erklärt, wieso, weshalb, warum und was man dagegen tun kann.Hier ist der Beitrag...Prinzipell müssen zwei Einträge in der web.config angepasst werden, damit die Funktion das macht, was sie soll:<forms name=".DOTNETNUKE" protection="All" timeout="120" cookieless="UseCookies" /> <add key="PersistentCookieTimeout" value="20160" />Der "Fehler" liegt auch weniger an DNN sonder viel mehr an der Behandlung von Cookies unter ASP.NET 2.0.

ASP.NET Ajax das Updatepanel und der FCKEditor

Heute habe ich versucht, den FCKEditor innerhalb eines ASP.NET Ajax Updatepanel dazu zu bewegen mir auch den eingegebenen Text auszuhändigen. Normalerweise ist ja die Einbindung und Nutzung vom FCKEditor innerhalb von DotNetNuke denkbar einfach. Also wie gewohnt die Arbeitsschritte ausgeführt und mal mutig F5 gedrückt. Leider mit dem Resultat, dass die Eigenschaft Text vom FCKEditor nach einem partial PostBack immer leer war und der Text zunächst mysteriös verschwand. Die Suchmaschine meines Vertrauen hat mir auch prompt ein paar Hinweise zu dem Thema ausgespuckt - gut, ich war wohl nicht alleine auf dieser Welt. Auf der Seite http://jlcoady.net/archive/2007/03/30/fckeditor-work-inside-updatepanel wurde ein Lösungsansatz vorgestellt, der aber leider so nicht ganz funktioniert - zumindest im meinem Fall nicht. private void Page_Load(object sender, EventArgs args){   Page.ClientScript.RegisterOnSubmitStatement(   editor.GetType(),   "editor",   "FCKeditorAPI.GetInstance('" + editor.ClientID + "').UpdateLinkedField();");} Dieser Code-Snippet bracht mich nicht weiter, denn der Text wurde immer noch nicht zurück geliefert, nach einem Postback innerhalb vom UpdatePanel. Auch der folgende Code sollte angeblich funktionieren, konnte aber meine FCKEditor auch nicht wirklich übereden, mal endlich seine Arbeit aufzunehmen. this.Page.ClientScript.RegisterOnSubmitStatement( this.GetType(), "AjaxHack", "for ( var i = 0; i < parent.frames.length; ++i ) if ( parent.frames[i].FCK ) parent.frames[i].FCK.UpdateLinkedField();" ); Wie sich nun herausstellt, sind die Scripte vollkommen in Ordnung und funktionieren auch. Nur ist es empfehlenswert die Methode "RegisterOnSubmitStatement" nicht als Methode der Page aufzurufen sondern als Methode vom ScriptManager. Das sieht dann so aus: ScriptManager sm = ScriptManager.GetCurrent(Page);if (sm != null){ScriptManager.RegisterOnSubmitStatement(this.Page,this.GetType(),"FCKAjaxHack","for ( var i = 0; i < parent.frames.length; ++i ) if ( parent.frames[i].FCK ) parent.frames[i].FCK.UpdateLinkedField();");} Oh Wunder, jetzt funktioniert auch der FCKEditor in der Zusammenstellung von DotNetNuke, ASP.Net Ajax und dem Updatepanel!

.NET AJAX .axd und der Fehler utcDate out of the range

Bei der Neuinstallation eines Windows 2008 Server mit ASP.NET 2.0 und AJAX bekam ich beim Abruf von Resourcen über WebResource.axd und ScriptResource.axd jeweils den Fehler: Specified argument was out of the range of valid values.Parameter name: utcDate Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.Parameter name: utcDateSource Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.   Lösung: Das liegt an der Systemzeit vom Windows Server. Zunächst sollte diese Zeit überprüft werden und falls nötig auf das aktuell Datum / Uhrzeit gesetzt werden. Sollte dadurch der Fehler nicht behoben werden, dann einfach unter Software die Installation von AJAX mit der Option "Reparieren" durchführen. Es scheint hier wohl eine Fehler zu geben und ASP.NET AJAX kommt dann mit dem Datum nicht zurecht. Nach der "erneuten" Installation funktioniert dann alles wie gewollt!  

HTML DOCTYPE bei DNN anpassen

Wer sich mit tabellenlosen Designs beschäftigt - und sind wir mal ehrlich, ergibt es anders einen Sinn - der wird sich auch immer wieder mal mit dem DOCTYPE rumschlagen müssen. Zum Glück haben die Entwickler von DotNetNuke da auch mitgedacht und den DOCTYPE pro DNN-Portal, sogar pro DNN Skin konfigurierbar gestaltet. Dafür muss lediglich eine XML-Datei angelegt werden, die den Namen des Skins trägt und dann die Endung ".doctype.xml" hat  also von Aufbau her so aussieht [SKINNAME].doctype.xml. Die XML Datei hat folgenden Aufbau: <SkinDocType><![CDATA[<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">]]></SkinDocType> Fertig ist der angepasste DOCTYPE für ein DotNetNuke-Skin. Das war doch mal wieder einfach :)  

Download von DotNetNuke 4.8.0

Auch während Weihnachten war das DNN-Core-Team wohl nicht ganz untätig und hat am 27.12.2007 den Download der DotNetNuke Version 4.8.0 frei gegeben. Es wurden viele Fehler korrigiert und neu ist der Support von DNN für den IIS (Internet-Information-Server) 7.0. Wer sich einen genauen Überblick von den Änderungen der aktuellen DNN Version machen möchte - Bitteschön, wie immer geht das im Bugtracking System support.DotNetNuke.com

DotNetNuke 4.7.0 steht als Download bereit

Also zunächst mal: Ich lebe noch ;-) Auch wenn mein Blog in den letzten Wochen eigentlich etwas anderes vermuten läßt. In den letzten Woche stecke ich in einem größeren Projekt wo ich DotNetNuke und die WCF (Windows Communication Foundation) mit einander kombiniert habe, um ein Videoportal (so in Richtung youtube, myvideo, etc.) zu entwicken. Doch dazu später hoffentlich mehr.... Seit heut steht DotNetNuke 4.7.0 zur Verfügung und wurde für die Öffentlichkeit als Download bereit gestellt. Dieses wurde pünktlich zur US-Konferenz OpenForce'07 bekannt gegeben. Dabei finde die neuen benutzerfreundlichen URLs sehr spannend. Leider komme ich im Augenblick noch nicht dazu, diese zu testen. :(  

Das mächtige Fragezeichen oder der ?? Opterator in C#

Immer wieder kommt die Situation das man im Laufe eines .NET Programmes überprüfen muss ob eine Objekt wirklich existiert oder aber ob in der Variablen der Wert NULL enthalten ist. Vielfach möchte man auch einfach für den NULL Fall einen Defaultwert setzen. Mit dem doppelten Fragezeichenoperator ist das in .NET C# sehr elegant und einfach zu realisieren. Hier ein ganz einfaches Beispiel: string resultmessage = param jQuery152023533955193124712_1339428543134 "Keine Nachricht da ;-)"; In der MSDN findet man dazu auch nähere Informationen (hier )    

Escape Sequence Description

Hier eine Liste der wichtigsten (zumindest für mich) Escape-Sequencen: \t Tab (Unicode 0x0009). \r Carriage return (0x000d). \n Newline (line feed) (0x000a). \v Vertical tab (0x000b). \a Alert (0x0007). \b Backspace (0x0008). \0 Null (0x0000). \\ Backslash (0x005c). \' Single quote (0x0027). \" Double quote (0x0022).  

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

Open Source .NET code performance and memory profiling software

Bei der Suche nach Performancemessungen für ein .NET Projekt, habe ich ich folgende interessante(s) Seite / Projekt gefunden: ProfileSharp Bis jetzt nur kurz getestet, scheint es aber ein gute Lösung zu sein um: Eine Speicheranalyse durchzuführen (z.B. Memoryleaks) Wo welche Rechenleistung benötigt wird Besonders interessant ist, dass der Profiler keinerlei Veränderungen am SourceCode benötigt - Bestandteile des Profilers müssen also nicht in das Projekt / Assembly k(c)ompiliert werden. Er läßt sich einfach von außen anfügen Das Produkt ist OpenSource und steht damit jedem zur Verfügung. Ob bei dem Funktionsumfang / Leistung mit kommerzielle Produkten aufnehmen kann werd ich sehen.  

Eine .NET WinForms Anwendung nur einmal starten / arbeiten mit einem mutex

Wenn man eine Anwendung nur einmal durch den Anwender starten lassen möchte, dann ist das mit der Hilfe von einem erzeugten Mutex sehr einfach zu realisieren. Nur ein paar Zeilen Quellcode sind dafür in der Main() Methode notwendig. Wie immer ist der Beispiel-Code in .NET C#. bool createdNew;///Einen neuen Mutex erzeugen, damit die Anwendung nur einmal gestartet werden kann.System.Threading.Mutex appMutex = new System.Threading.Mutex(true, Application.ProductName, out createdNew);///Wenn die Erzeugung erfolgreich warif (createdNew){///... dann kann die Anwendung ausgeführt werdenLogIn frmLogIn = new LogIn();Application.Run(frmLogIn);if (frmLogIn.DialogResult == DialogResult.OK)Application.Run(new MainForm());// den Mutex wieder frei gebenappMutex.ReleaseMutex();}else{///Wenn die Anwendung schon ausgeführt wird -> Hinweis-Dialogstring msg = String.Format("Das Programm \"{0}\" wurde bereits gestartet!", Application.ProductName);MessageBox.Show(msg, Application.ProductName, MessageBoxButtons.OK, MessageBoxIcon.Information);}

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.

C#/VB .NET Coding Guidelines

Gerade habe ich ein kostenloses eBook zum Thema Coding Guidlines für C# und VB.NET gefunden und möchte darauf aufmerksam machen. Den Download gibt es direkt unter submain.com Das eBook hat folgende Themen: Naming Guidelines Class Member Usage Guidelines Guidelines for Exposing Functionality to COM Error Raising & Handling Guidelines Array Usage Guidelines Operator Overloading Usage Guidelines Guidelines for Casting Types Common Design Patterns Callback Function Usage Time-Out Usage Security in Class Libraries Threading Design Guidelines Formatting Standards Commenting Code Code Reviews Additional Notes for VB .NET Developers Ebenso recht nützlich ist das Tool SmartOutline for VS2005, welches als kostenlose Version auf der Seite zur Verfügung gestellt wird. Damit wird das Handling von #region's - welche ich sehr gerne benutze - noch etwas verbessert.

Die DotNetNuke WebControls / DNN NavigationProvider

Im Augenblick beschäftige ich mich mit dem DNN NavigationProvider. um für einen Kunden ein CSS basiertes Menu zur Verfügung zu stellen. Ursprünglich dachte ich eigentlich, dass man auf das Rendern des Menüs Einfluß hat und bestimmen kann, wie das Menu auszusehen hat.Nachdem ich den Sourcecode der mitgelieferten Provider analysiert habe .. kam zunächst recht schnell die Ernüchterung. Da wird in der class DNNMenuNavigationProvider auf eine Objekt vom Typ DNNMenu zugegriffen. Doch der Sourcecode scheint davon nicht mit im Standarddownload enthalten zu sein. Mein erster Schreck - das ich das Rendern gar nicht beeinflussen kann - ging schnell vorbei. Zum einem ist natürlich die Klasse DNNMenu in dem Downloadpaket DotNetNuke WebControls enthalten und zum anderen ist die Nutzung dieses Objektes ja gar nicht notwendig. Jetzt werde ich mal versuchen meinen eigenen Menuprovider zu entwicklen und bin gespannt wie das klappt!

DotNetNuke 4.5.2 Released

Nachdem ich eigentlich schon wieder viel zu lange nichts mehr über DNN veröffentlicht hab, möchte ich damit nun endlich wieder beginnen. Am 29.05 (also gestern) wurde die Version 4.5.2 veröffentlicht und steht wie gewohnt unter www.dotnetnuke.com zum Download bereit. Mittlerweile ist eine ganze Menge an neuen Features implementiert wurden und eine einzelne Aufzählung wäre mit Sicherheit zu lang(weilig). Einen sehr genauen Einblick über die Veränderungen innerhalb von DotNetNuke bekommt man wie immer in der Bug Tracker.  

Status List im Vista Style

Soeben habe ich ein sehr interessante Projekte oder viel mehr Komponente auf codeproject gesehen und möchte meiner Umwelt diese nicht vorenthalten. Dabei handelt es sich jeweils um sehr schön gemachte Status List entwickelt in C#. Hier ist der direkte Link zu dieser .NET Komponente .... klick :) Dazu passend gibt es auch noch ein Status Label (wohl in VB.NET) ... klick

Eine DotNet Technologie Suchmaschine

Suchmaschinen wie www.google.de oder www.live.de sind für alle Entwickler - ob .NET, PHP, Delphi, etc. - ein wertvolles Werkzeug um schnell Antworten und Lösungen bei Problemem zu finden. Das größte Problem dabei ist aber meist, dass man nicht nur Suchergebnisse bekommt dich sich auch wirklich mit .NET befassen und somit wird die Recherche unnötig erschwert. Dieses gehört aber der Vergangenheit an, denn Dan Appleman hat folgende Website erstellt: http://www.searchdotnet.com/ Diese Suchmaschine basiert auf Google, allerdings werden wirklich nur .NET relevante Ergebnisse angezeigt. Die ersten Erfahrungen mit dieer Suchmaschine waren sehr positiv!

Die Live-Suche von Microsoft liebt mein Blog

Also ich mir gerade so ein wenig die Referrer angeschaut habe bzw. die Suchbegriffe inkl. Positionen bin ich über folgendes gestolpert: In der Microsoft Live-Suche bin ich auf Platz 1 von 6 Millionen Treffer und das mit dem Begriff ".net 2.0". Find ich persönlich schon ziemlich sexy und mein Tag ist gerettet :D

Die ASP.NET AJAX Extensions sind fertig / RTW

Die ASP.NET AJAX Extensions haben das Betastadium verlassen und sind nun RTW (Ready-to-Web). Diese Bibliothek integriert sich vollständig in das ASP.NET 2.0 Framework und liefert sowohl serverseitige Funktionalität als auch eine plattformübergreifend clientseitige JavaScript-Bibliothek. Dadurch soll es möglich sein auch bestehende Anwendungen mit minimalem Aufwand AJAX fähig zu machen. Eine erste Anlaufstelle für AJAX ist die Website: http://ajax.asp.net/ Der direkte Downloadlink zur AJAX Extension ist hier.

Performanceoptimierung von DotNetNuke / DNN

Das DotNetNuke mittlerweile einen sehr großen und brauchbaren Funktionsumfang hat muss an dieser Stelle nicht weiter erwähnt werden. Bei der Implementierung alle dieser Features stand aber leider der Punkt Geschwindigkeit (Performance) nie im Mittelpunkt. Das soll nun endlich mit der kommenden Version 4.4.0 verändert werden! Durch folgende Maßnahmen soll die Geschwindigkeit verbessert werden: (1) Code Refactoring (2) Optimierung und verbesserte Einsatz des Caching (3) Assembly Management (4) Database (5) Compression (6) Page State Wer genauer wissen möchte was sich hinter den einzelnen Punkten versteckt kann das im Blogeintrag von Charles Nurse hier nachlesen. Die Ergebnisse der ersten Tests kann man hier nachlesen! Auf die Version 4.4.0 dürfen wir also alle sehr gespannt sein :)