Deutsche DotNetNuke Community

DotNet-News - Visual Studio - Der Projektspeicherort ist nicht vertrauenswürdig (auf lokalem Laufwerk)

Vorwort:

Ich möchte an dieser Stelle jetzt keinen Vortrag über ADS (Alternate Data Streams) im NTFS Dateisystem halten, dazu gibt es bereits eine Fülle von Informationen im Internet, wer hierzu nähere Informationen haben möchte kann diese über eine Internetrecherche mit der SDV (Suchmaschine deines Vertrauens) erhalten.

Hintergrund dieses Beitrags:

In letzter Zeit haben sich die Anfragen bei mir gehäuft, warum nach dem herunterladen aktueller DotNetNuke Versionen (4.9.X und 5.X) von Codeplex und dem anschließenden Entpacken des ZIP Archivs beim Öffnen der Visual Studio Solution ständig die Meldung “Der Projektspeicherort ist nicht vertrauenswürdig” erscheint, obwohl man die Projektdaten auf einem lokalen Laufwerk gespeichert hat und nicht (wo diese Meldung üblicherweise herkommt) auf einem Netzwerklaufwerk.

Zuerst sei einmal gesagt, dass dies weder etwas mit den neuen Versionen, noch mit Codeplex oder DotNetNuke zu tun hat.

Der Grund für diese Meldungen ist, dass beim herunterladen über einen Browser (Früher war das nur wenn man den IE benutzt hat, Heute ist es aber auch mit Firefox so) einer Datei auf ein NTFS Laufwerk sogenannten Alternate Data Streams erzeugt werden, die in diesem speziellen Fall eine unsichtbare Datei [Dateiname]:Zone.Identifier auf dem Laufwerk erstellt und fest verknüpft mit der heruntergeladenen Datei speichert.

Vereinfacht gesagt, teilt diese “unsichtbare” Datei dem Betriebssystem mit “Du Achtung die Datei kommt aus dem Internet und könnte gefährlich sein, gib lieber mal eine Warnung aus”.

Eine der Lösungen (die in diesem Beitrag beschriebene) ist:

Wir löschen die “unsichtbaren” Dateien [Dateiname]:Zone.Identifier.

Seit Vista gibt es zwar für den Kommandozeilenbefehl DIR eine neue Option /R welche diese “unsichtbaren” ADS Dateien anzeigt, aber leider habe ich noch keinen weg gefunden diese mit “Bordmitteln” löschen zu können (Außer die Daten auf ein nicht NTFS Laufwerk zu speichern und anschließend wieder auf das NTFS Laufwerk zu kopieren).

Aber wie so häufig gibt es dafür ein Freeware Tool (sicherlich gibt es auch noch andere, hinterlasst einfach einen Kommentar) welches genau das kann.

Das Programm AlternateStreamView von NirSoft ist so ein Tool (Das übrigens auch unter WIN 7 und da sogar auf X64 funktioniert).

Die Verwendung des Programms ist; denke ich selbsterklären.

5/11/2010 9:25:14 AM - http://blog.schelian.de/2010/05/11/VisualStudioDerProjektspeicherortIstNichtVertrauensw%c3%bcrdigAufLokalemLaufwerk.aspx

Author: - Comments ()

DotNet-News - DotNetNuke Module – DMX von Bring2Mind Problem mit DNN 5.X – SQL Hack

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.

3/24/2010 11:56:00 AM - http://blog.schelian.de/2010/03/24/DotNetNukeModuleDMXVonBring2MindProblemMitDNN5XSQLHack.aspx

Author: - Comments ()

DotNet-News - DotNetNuke 5.2.0 – Breaking Changes – Part I – Der Begin der echten Portal Lokalisierung

Eigentlich wurde ja bereits mit der Version 5.0 erwartet, dass DotNetNuke nun endlich mehr Internationalität erhält.

Dem war aber nicht so, und mit der Version 5.0 wurden keinen echten Schritte in die Richtung Mehrsprachigkeit gegangen.

Mit der Version 5.2 beginnt nun aber tatsächlich der erste große Schritt in “diese Richtung” ich wollte eigentlich “richtige Richtung” schreiben, aber da bin ich mir noch nicht sicher, warten wir es ab. Leider, oder wie ich sagen würde, wie erwartet, geschieht dies nicht ohne das es dabei zu gravierenden Änderungen (Breaking Changes) in der Datenbankstruktur kommt.

Mit der Version 5.2.0 wird nun folgende gravierende Änderung vollzogen:

Die Tabelle Portals wird International.

Alle Informationen der Tabelle welche Lokalisierbar sein müssen wurden, in eine neue Tabelle PortalLocalization verschoben und alle Einstellungen aus der Tabelle wurden zusammen mit einem Sprachcode in die Portalsettings Tabelle verschoben.

Das ganze führt bei einigen Programmen (Beispielsweise sei hier das Document Exchange Module von Bring2Mind genannt) dazu, dass diese nicht mehr ohne Update mit DNN 5.2.X und höher betrieben werden können.

Sollte ein eigenes Modul von einer solchen Änderung betroffen sein, so sollte man sich die ebenfalls neuen Views (ja DNN verwendet nun auch Views)

vw_Portals (Alle Sprachen)
vw_PortalsDefaultLanguage (Standard Sprache entspricht der Lösung vor DNN 5.2)

ansehen.

Durch Verwendung einer dieser Views kann man durch einfache Änderung des Zugriffs von der Portals Tabelle auf eine dieser Views die notwendigen Informationen für sein Modul erhalten, ohne gleich die gesamte Lokalisierungsfunktionalität zu implementieren.

Fortsetzung folgt!!!

1/5/2010 12:11:00 PM - http://blog.schelian.de/2010/01/05/DotNetNuke520BreakingChangesPartIDerBeginDerEchtenPortalLokalisierung.aspx

Author: - Comments ()

DotNet-News - DotNetNuke 4.09.04 Source Version und IE 8

Wenn man die Source Version von DotNetNuke Version 4.09.04 in Visual Studio ausführt und als Browser den Internet Explorer 8 einsetzt, kommt es beim überfahren der Menüs (Admin und Systemmenü) mit der Maus zu folgendem Fehler:

Dieser Fehler tritt in der Datei dnn.dom.positioning.js auf.

Die Zeile in welcher der Fehler auftritt lautet:

oIFR.style.zIndex=iIndex-1

Was geschieht ist, dass in der Variablen iIndex anstelle eines Wertes, das Wort “Auto” enthalten ist. Wenn nun versucht wird von dem String “Auto” den Wert 1 abzuziehen, kommt es natürlich zu einem Fehler.

Ich habe eine Lösung gefunden, die für mich funktioniert und nicht die Zeile einfach auskommentiert.

Die Lösung sieht wie folgt aus:

Ich füge am Ende der Datei dnn.dom.positioning.js die Funktion IsNumeric ein:

function IsNumeric(sText)

{
   var ValidChars = "0123456789.";
   var IsNumber=true;
   var Char;

 
   for (i = 0; i < sText.length && IsNumber == true; i++) 
      { 
      Char = sText.charAt(i); 
      if (ValidChars.indexOf(Char) == -1) 
         {
         IsNumber = false;
         }
      }
   return IsNumber;
   
   }

Und verwende diese Funktion wie folgt um den Inhalt der Variable iIndex zu prüfen und im Falle das darin kein numerischer Wert enthalten ist, führe ich die Subtraktion nicht aus.

Anstelle der Zeile (250) mit dem Inhalt oIFR.style.zIndex=iIndex-1;

füge ich nachfolgende 4 Zeilen ein, das sieht dann so aus:

if (IsNumeric(iIndex))
    oIFR.style.zIndex = iIndex - 1;
else
    oCont.style.zIndex = 1;

Nun einfach die Datei dnn.dom.positioning.js speichern und auch Fehlerfrei mit dem IE 8 und der Source Version von DotNetNuke arbeiten.

7/22/2009 8:52:05 AM - http://blog.schelian.de/2009/07/22/DotNetNuke40904SourceVersionUndIE8.aspx

Author: - Comments ()

DotNet-News - DotNetNuke 4.09.04 Source Version übersetzen

Wenn man versucht die Source Version von DotNetNuke 4.09.04 in Visual Studio 2008 zu öffnen und anschließend zu übersetzen, kommt es zu folgender Fehlermeldung:

$Fehler 1 Datei "Controls\AJAX\bin\System.Web.Extensions.dll" kann nicht in "..\Website\bin\System.Web.Extensions.dll" kopiert werden. Ein Teil des Pfades "Controls\AJAX\bin\System.Web.Extensions.dll" konnte nicht gefunden werden. C:\dnn494\Library\DotNetNuke.Library.vbproj 987 5 DotNetNuke.Library$

Das Problem entsteht dadurch, dass versucht wird nach dem Übersetzungslauf die Datei System.Web.Extensions.dll aus dem Verzeichnis Controls\AJAX\bin\ in das BIN Verzeichnis von DotNetNuke zu kopieren.

Dies ist aber gar nicht notwendig, da sich die Datei System.Web.Extensions.dll im GAC befindet.

Um den Fehler zu beheben, kann man die Datei DotNetNuke.Library.vbproj im Library Verzeichnis von DotNetNuke mit einem Texteditor öffnen, und nach dem Eintrag

suchen, der Steht normal in der Zeile 987.

Diese Eintrag entfernt man und speichert anschließend die Datei ab.

Wenn man nun das Source Projekt mit Visual Studio öffnet und übersetzt sollte das Problem gelöst sein.

7/21/2009 10:23:55 AM - http://blog.schelian.de/2009/07/21/DotNetNuke40904SourceVersion%c3%9cbersetzen.aspx

Author: - Comments (1)