Bei dem hier beschrieben Problem und deren BUGFIX handelt es sich um die DMX Version 3.5.X und dem Update eines DNN 4.9.X Portals auf DNN 5.X.

Sicherlich die einfachste Methode ist einfach ein Update des DMX Moduls zu erwerben und dieses Update zu verwenden.

Wer das aber nicht möchte und mit dem Funktionsumfang der 3.5.X Version zufrieden ist, kann mithilfe des hier einfach beschriebenen SQL Patches die Version 3.5.X unter DNN 5.3.X (und vermutlich auch höher) zum laufen bekommen.

ACHTUNG auch hier gilt:

Vor der Manipulation unbedingt eines Sicherung (in diesem Fall genügt die Sicherung der Datenbank) vornehmen.

Hier nun die Vorgehensweise, nachdem man vermutlich erst nachdem man das DNN Portal von 4.X auf 5.X aktualisiert hat, feststellt, dass das DMX Modul nicht mehr funktioniert.

Man meldet sich am Portal als Systemadministrator (host) an.

Im Systemverwalter wählt man nun den Menüpunkt SQL aus.

Dort kopiert man das nachfolgende SQL Script in die Eingabemaske:

IF EXISTS (select * from dbo.sysobjects where id = object_id(N'{databaseOwner}{objectQualifier}DMX_GetExtensionsByPortal') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
DROP PROCEDURE {databaseOwner}{objectQualifier}DMX_GetExtensionsByPortal
GO 

CREATE PROCEDURE {databaseOwner}{objectQualifier}DMX_GetExtensionsByPortal
    @PortalId Int
AS 

SELECT
    {databaseOwner}{objectQualifier}DMX_Extensions.[AccessRights],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Addon],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ControlToLoad],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Custom],
    {databaseOwner}{objectQualifier}DMX_Extensions.[DownloadUrl],
    {databaseOwner}{objectQualifier}DMX_Extensions.[EntryTypes],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ExtensionKey],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Icon16],
    {databaseOwner}{objectQualifier}DMX_Extensions.[Icon32],
    {databaseOwner}{objectQualifier}DMX_Extensions.[IsPrivate],
    {databaseOwner}{objectQualifier}DMX_Extensions.[MimeType],
    {databaseOwner}{objectQualifier}DMX_Extensions.[PortalId],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ResourceFile],
    {databaseOwner}{objectQualifier}DMX_Extensions.[SettingsControl],
    {databaseOwner}{objectQualifier}DMX_Extensions.[ViewByDefault], 
    {databaseOwner}{objectQualifier}DMX_Addons.Description AS AddonsDescription, 
    {databaseOwner}{objectQualifier}vw_PortalsDefaultLanguage.Description AS PortalsDescription
FROM
    {databaseOwner}{objectQualifier}vw_PortalsDefaultLanguage INNER JOIN {databaseOwner}{objectQualifier}DMX_Addons 
     INNER JOIN {databaseOwner}{objectQualifier}DMX_Extensions ON {databaseOwner}{objectQualifier}DMX_Addons.AddonKey = 
     {databaseOwner}{objectQualifier}DMX_Extensions.Addon ON {databaseOwner}{objectQualifier}vw_PortalsDefaultLanguage.PortalID = 
    {databaseOwner}{objectQualifier}DMX_Extensions.PortalId
WHERE
    {databaseOwner}{objectQualifier}DMX_Extensions.PortalId = @PortalId 

GO

achtet darauf das die Checkbox “Run as script” markiert ist betätigt den Link “Execute”

Das war’s auch schon

Wer übrigens mehr über den Hintergrund zu diesem Problem wissen will, kann in meinem Beitrag DotNetNuke 5.2.0 – Breaking Changes – Part I – Der Begin der echten Portal Lokalisierung mehr erfahren.

Ohne große Ankündigung und ohne genaue Beschreibung welche Probleme gelöst wurden, wurde vergangenes Wochenende ein Maintenance Release des Blog Moduls für DotNetNuke veröffentlicht.

Die Versionsnummer dieser Version lautet 3.05.01.

Die neue Version kann man hier herunterladen.

Letzte Nacht wurde eine neue Version des Blog Moduls und eine neue Version des News Moduls für DotNetNuke zum Download bereit gestellt.

Hier geht es zum Download der Version 03.05.00 des Blog Moduls

Hier geht es zum Download der Version 04.00.01 des News Moduls

Gestern Nacht war großer Release Tag bei DotNetNuke.

Folgende Module wurden neu bzw. aktualisiert veröffentlicht:

Modul Announcements Version 4.00.01

Das Modul setzt voraus das DotNetNuke Version 4.6.2 (also auch ASP.NET 2) oder höher installiert ist.

Die neuen Feature umfassen:

• Erfassen mehrerer Announcements in einer Instanz des Moduls.
• Implementierung der ISearchable Schnittstelle (DNN Suche und RSS)
• Basis Implementierung der IPortable Schnittstelle (Import Export von Inhalt)
• Verwendung von Platzhaltern / Systemvariablen möglich

Hier geht es zum Download

Modul Feedback Version 4.04.03

Das Modul setzt voraus das DotNetNuke Version 4.4.0 (also auch ASP.NET 2) oder höher installiert ist.

Hauptsächlich handelt es sich im einen Maintenance Release, es gibt nicht wirklich viel neues, außer man freut sich darüber dass man nun endlich einen funktionierenden Button zum löschen von Feedback Einträgen hat.

Hier geht es zum Download

Wer es genau wissen möchte kann aber hier mehr über die neuen Feature von 4.04.03 lesen (in Englisch)

Modul Chat Version 1.00.01 (Neues Modul)

Das Modul setzt voraus das DotNetNuke Version 4.6.2 (also auch ASP.NET 2) oder höher installiert ist.

Herzlichen Glückwunsch zur Veröffentlichung der ersten Version des Chat Moduls für DotNetNuke.

Hier geht es zum Download

Viele die mich kennen, wissen dass ich mich seit vielen Jahren intensiv um DotNetNuke und seinen Einsatz vor allem auch im Deutschsprachigen Raum engagiert habe.

Auch und gerade weil mir das Produkt am Herzen liegt muss ich aber nicht alles gut finden was die Herren in USA so an neuen Dingen vorstellen.

Vor einige Tagen ist mir nun die neue Version des DotNetNuke Blog Moduls unter die Finger gekommen. Für die, die es nicht wissen, das Blog Modul habe ich auf Basis, des leider aus der DotNetNuke Szene verschiedenen Michael Trefry hinterlassenen MyBlog Module für DotNetNuke, als Open Source Module für DotNetNuke 3.X entwickelt.

Damals, im ersten Halbjahr 2005 haben sich die Ereignisse dann überschlagen.

28.02.2005 erste Ankündigung des Blog Moduls

01.03.2005 erste Beta Version verfügbar

11.03.2005 Beta 2 des Blog Moduls mit dem Namen NewBlog verfügbar

und dann am

12.03.2005 der Schock, DotNetNuke 3.0.12 kommt auf den Markt und es enthält ein Forum und ein Blog Modul (war die ganze Arbeit umsonst ?)

Aber jeder Schock, Niederlage ist auch ein wenig Herausforderung und Neuanfang.

13.03.2005 das erste Final Release meines Blog Moduls wird als Open Source veröffentlicht

In den folgenden Wochen wird das Blog Modul NewBlog von Tausenden Leuten heruntergeladen und verwendet, die Reaktionen sind allgemein sehr positiv und es zeigt sich dass mein Blog Modul um Längen besser bei den Anwendern ankommt als das damalige Core Blog Module.

29.04.2005 Ich veröffentliche die zweite Version  (Version 3.1.5) des Blog Moduls

Das Highlight dieser Version war die integrierte Möglichkeit Bilder und Dateianhänge zu einem Blogeintrag zu speichern (so ähnlich wie das Heute auch von LiveWriter umgesetzt wird) und zu verwalten ohne den Dateimanager von DotNetNuke verwenden zu müssen, was übrigens nur von einem Benutzer mit Administrationsrechten gemacht werden konnte.

03.05.2005 DotNetNuke veröffentlicht eine neue Version seines Forum / Blog Moduls (wobei das Blog Modul keinen Deut besser wurde als es vorher war)

15.06.2005 Der nächste Versuch das DotNetNuke Core Blog Modul zu performen

20.07.2005 NewBlog wurde in 7 Wochen 2500 mal heruntergeladen

05.08.2006 Neue Version von NewBlog mit vielen neuen Feature veröffentlicht (mittlerweile über 3000 Downloads)

15.08.2005 Die Geschichte eines Moduls - Mein Blog Modul wird von mir als Core Blog Module zur Verfügung gestellt.

Ab nun begann mein Kampf mit den eingefahrenen Strukturen der US Boys. Da ich der erste Projekt Leiter eines Core Moduls war weder zum Core Team gehörte noch aus den USA stammte. Stimmte weder die Zeitzone noch die richtige Zusammenarbeit. In den folgenden Monaten habe ich um jedes Zugangsrecht und Freigabedatum kämpfen müssen, da es einfach keine festen Richtlinien gab, nach welchen man vorgehen konnte.

Trotz all dieser Widrigen Umstände konnte ich am

21.10.2005 Vermelden, dass die abschließenden Tests des ersten offiziellen Blog Moduls nach der Übernahme durch DotNetNuke abgeschlossen sind

Nicht das nun alles erledigt sei und das Modul veröffentlicht werden konnte.

24.10.2005 - Ich schreibe den Beitrag unendliche Geschichte (ein früher Vorläufer dieses Beitrags)

01.11.2005 Endlich ist es soweit die erste Version des neuen Blog Moduls steht zum Download zu Verfügung

06.11.2005 Nachdem das erst Release wirklich veröffentlicht ist, kann es voller Elan an das erst Update gehen

26.12.2005 Nach vielem hin und her (Die Herren des Core Team hatten Änderungen in DotNetNuke 4.0 eingebaut ohne mich zu informieren oder mir Zugriff auf die aktuelle Version zu geben, und dadurch lief das Blog Modul nicht mehr) ist es so weit die nächste Version des Blog Modul ist für den endgültigen Test fertig

28.12.2005 Ich veröffentliche eine Alpha Version des Blog Moduls 4.X das dediziert für den Einsatz für DotNetNuke 4.X erstellt wurde

29.12.2005 Die Blog Version 3.02.00 steht zum Download bereit

Mitte Februar 2006 melde ich mich von einer ersten krankheitsbedingten Auszeit zurück

Nach unergiebigen weiteren 12 Monaten beende ich meine aktive Projektarbeit am Blog Module mit einem offiziellen Schreiben im März 2007.

Der Neue Projektleiter wird Antonio Chagoury, jemand der bis dahin keinen eigenen Blog betrieben hat.

Aber warum habe ich eigentlich die Überschrift "DotNetNuke Blog Module - eine traurige Geschichte!" verwendet?

Der Grund der Überschrift ist, das entfernen einer der Kernfunktionen des von mir für DotNetNuke erdachten Blog Moduls

Unter dem neuen Projektleiter wurde die von mir mit der Version 3.1.5 integrierte Funktion zur Blog bezogenen einfachen Speicherung von Bildern und Anhängen einfach entfernt (Nein die DotNetNuke Standardfunktionen können dieses Funktionalität nicht bieten). 

Dieses Feature ist mit der Version 3.4.0 einfach verschwunden.

Aus Trauer über den Verlust dieser Funktion habe ich mir nicht mal die Mühe gemacht um zu sehen, was mit vorhandenen Beiträgen geschieht die dieses Feature verwendet haben (Ich vermute es bleiben einfach verwaiste Einträge bestehen). Ich weiß nur dass ich meine Blogs, die ich auf meinen DotNetNuke Web Seiten betreibe nun nicht mehr aktualisieren werde.

Auch wenn viele der "JA Sager" und "Alles ist Gut Jünger" von DotNetNuke sagen werden ich habe diesen Beitrag geschrieben weil ich mich persönlich auf den Schlips getreten fühle, dann ist das nicht so.

Ich bin einfach nicht glücklich über diese, meiner Meinung nach falsche Richtung, die man mit der Weiterentwicklung einschlägt. Und muss ich, nur weil ich mit dem Projekt mal näher betraut war, auf immer meine Meinung über etwas was ich selbst verwende zurück halten.

Nein, das werde ich nicht.

Vermutlich wird mich das ganze dazu bringen in absehbarer Zeit wieder eine eigene Version des Blog Moduls zu pflegen.

Aus anderen Beiträgen habe ich bereits erfahren, dass ich nicht der erste, und auch nicht der einzige bin, dem das entfernen dieses Feature vollkommen unverständlich ist.

Anstelle das Feature zu entfernen, hätte mir eher gewünscht dass man dieses Feature um eine LiveWriter Anbindung erweitert hätte.

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

Gestern habe ich über die Verfügbarkeit der neuen DotNetNuke Core Module Bog. Forum und Store berichtet.

Aus den ersten Tests der einzelnen neuen Module möchte ich an dieser Stelle aber gleich eine Warnung vor dem Upgrade des neuen Forum Moduls geben.

Es wurden im Forum Modul sogenannte "breaking changes" vorgenommen aber leider wurde dabei vergessen, oder man hatte dazu keine Lust, auch die entsprechend aufwendigeren Update Routinen zu entwickeln.

Die Folge daraus ist unter anderem:

Sofern nicht das Default Theme von DotNetNuke in vollkommen unangepasster Version benutzt wurde, wird nach einem Update das Theme nicht mehr funktionieren. Nicht nur das man nun global einstellen kan (muss) ob man gif, jpg oder png Bilder zur Verwendung in seinem Theme verwendet hat, sonder man hat auch noch die Namen der einzelnen Bilder geändert.

So ist zum Beispiel aus s_settings_32px.gif ein s_settings_lrg.png geworden.

Dann gibt es neben einigen anderen neuen Settings auch noch den Schalter "Enable Toolbar Icons":

Ich habe selten etwas häßlicheres gesehen als das was dann als Toolbar im Forum angezeigt wird, Gott sei Dank hat man da wirklich durch den Schalter die Wahl anstelle der Toolbar einfache Text links zu verwenden.

Neben dieses rein optischen aber doch sehr störenden Problemen sind leider auch die Update Routinen betreffend der Sicherheits- Einstellungen nicht wirklich ausgetestet.

Man muss nach dem Update (und das noch bevor das Portal wieder ONLINE geht) auf jeden Fall alle Rechte Einstellungen des Moduls und der einzelnen Foren überprüfen, ob diese noch das bewirken, was man eigentlich wollte.

Ich hatte beispielsweise plötzlich in einem Intranet Test das Problem das "normale" Mitarbeiter in das Forum der Personalverwaltung zugreifen konnten. Da hätte sich der eine oder andere warm anziehen können.

Also unbedingt umfangreiche Upgrade Tests des Moduls in einem Test-Portal durchführen, verwendete Themes anpassen und dann erst das Live Portal aktualisieren wenn klar ist was und wie das Update durchgeführt werden kann.

In der Nacht zum 16.10.2007 wurden für die nachfolgenden Module neue Versionen veröffentlicht:

• Forum (Version 04.04.03)
• Blog ( Version 03.03.01)
• Store (Version 02.01.00)

Blog Modul:

Das Blog Modul erhält nach 4 Monaten eine neue Version mit ....

mit einer einzigen Fehlerkorrektur, als ob es nicht genügend zu korrigieren geben würde. Na dann warten wir halt weiter auf die dann sicherlich bahnbrechende Version 03.04.00.

Das Blog Modul ist übrigens das einzige Modul dieser Veröffentlichung was noch nicht auf den ASP.NET 2 Framework umgestellt ist und benötigt als Voraussetzung für den Betrieb die Installation einer DotNetNuke Version 03.o3.07 oder 04.03.07.

Download Link Blog Modul

Forum Modul:

Für das Forum Modul ist es notwendig mindesten die DotNetNuke Version 04.04.00 zu betreiben.

Im Forum gab es zur letzten Version 105 Änderungen / Erweiterung / Fehlerkorrekturen. Einzelheiten zu den aktuellen Änderungen findet man hier.

Download Link Forum Modul

Store Modul:

Das Store Modul setzt voraus das man mindestens DotNetNuke Version 04.04.01 installiert hat.

Information über die aktuellen Änderungen des Store Moduls findet man hier.

Download Link Store Modul

Im Zusammenhang mit einem DotNetNuke Update (Version 3.1.1 --> Version 4.5.3) welches ich für einen Kunden durchführe ist folgendes Problem aufgetaucht:

In der DotNetNuke Installation 3.1.1 war unter anderem das FAQ Module von SpohnSoftware in der Version 1.06.00 eingesetzt.

Während des Update des DotNetNuke Portals auf die Version 4.5.3 traten auch keine merklichen Probleme mit diesem Modul auf. Selbst bei den ersten Tests (es handelt sich um ein umfangreiches Portal) wurden zuerst noch keine Probleme festgestellt. Dann aber stellte man fest, dass beim Versuch durch anklicken der Frage die Antwort zu öffnen nur eine Meldung "Fehler auf dieser Seite" vom Browser ausgegeben wurde, aber der Antwort nicht angezeigt wurde.

Nach einer kurzen Recherche im Internet war klar, es gibt eine neue Version (mittlerweile die Version 03.00.00) die auch laut Angaben des Herstellers für DotNetNuke 4.X funktioniert.

Also neue Version des Moduls gekauft (wie sich kurz drauf herausstellen sollte, Gott Sei Dank gleich die Source Version) und auf einem Test-Portal installiert.

• Frage und Antwort eingegeben
• Seite aufgerufen
• Auf die Frage geklickt um die Antwort anzuzeigen

Und der Browser zeigt in der Statuszeile an: Fehler auf dieser Seite

Wie bereits erwähnt, ich hatte die Source Version gekauft. Also das Modul in einem Entwicklungsportal installiert und die Source in das Projekt integriert.

Fehlersuche......!

Nach einigen Minuten war klar, das Problem liegt daran dass beim Aufruf von Java Script Funktionen kein gültiges Objekt der Seite an diese als Parameter übergeben wurden, aber warum.

Aber auch diese Frage war nach kurzer Zeit geklärt:

SpohnSoftware hat in seinem Modul eine Funktion GetTableName die dazu verwendet wird den durch das APS.NET Framework generierten Namen für das Control zu ermitteln. Die Funktion sieht so aus:

        Public Function GetTableName() As String
            Try
                Return Replace(UniqueID & "_tblQA", ":", "_")

            Catch ex As Exception
                ProcessModuleLoadException(Me, ex)
            End Try
        End Function

Wenn wir uns nun den Replace anschauen sehen wir auch sehr schnell das eigentliche Problem:

Die UniqueID enthält den eindeutigen Namen, welcher vom NET Framework erzeugt wurde. Das NET Framework 2.0 verwendet hierbei zur Trennung zwischen den einzelnen Namen das $ Zeichen und nicht das : Zeichen.

Das kann nicht gehen und ich frage mich wie das Modul jemals funktioniert haben soll.

Hier nun die Funktion wie sie richtig ist und auch funktioniert:

        Public Function GetTableName() As String
            Try
                Return Replace(UniqueID & "_tblQA", "$", "_")

            Catch ex As Exception
                ProcessModuleLoadException(Me, ex)
            End Try
        End Function

Ich habe hierzu auch sehr intensiv im Internet recherchiert, konnte aber keine Erklärung finden, warum das jemals so funktioniert haben soll.

Mal sehen, eventuell gibt es ja jemand der meinen Artikel liest und mir darauf eine Antwort geben kann.

Seit dem letzten Sicherheitsupdate von Microsoft kommt es zu einem Fehler beim Einsatz des Blog Moduls wenn dieses auf einer 4er Version (also unter dem NET Framework 2.0) von DotNetNuke eingesetzt ist.

Der Fehler tritt auf, wenn man einen neuen Blog Eintrag erstellen, oder einen vorhandenen Eintrag bearbeiten möchte.

Die genaue Fehlermeldung lautet:

Fehler: Edit Entry ist zur Zeit nicht verfügbar.

ModuleControlSource: DesktopModules/Blog/EditEntry.ascx

InnerException: The server tag is not well formed.

RawURL: /Weblog/tabid/140/ctl/Edit_Entry/mid/576/EntryID/261/Default.aspx

Message: DotNetNuke.Services.Exceptions.ModuleLoadException: The server tag is not well formed. ---> System.Web.HttpParseException: The server tag is not well formed. ---> System.Web.HttpException: The server tag is not well formed. at System.Web.UI.TemplateParser.ProcessError(String message) at System.Web.UI.TemplateParser.DetectSpecialServerTagError(String text, Int32 textPos) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath) at System.Web.UI.TemplateParser.ParseInternal() at System.Web.UI.TemplateParser.Parse() at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType() at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(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 ---

Die Lösung für das Problem liegt an einem Sonderzeichen welches sich in der Datei EditEntry.ascx befindet.

In der Zeile 21 wird das Wort ResourceKey falsch geschrieben.

Der Test in der Datei lautet ResourcêKey man achte auf das ê anstelle eines normalen e.

Also einfach die Datei öffnen das ê gegen ein e austauschen speichern - fertig.