Blog Home  Home Feed your aggregator (RSS 2.0)  
HP's Blog - Wednesday, March 04, 2009
Hans-Peter Schelian's Weblog
 
# Wednesday, March 04, 2009

Für alle die sich noch immer mit Windows XP beschäftigen “müssen”, oder einfach nur als Memo für mich.

Unter Windows XP Prof wird unter bestimmten Voraussetzungen, im Datei Explorer unter dem Begriff “Auf diesem Computer gespeicherte Dateien” Verknüpfungen zu “Dateien von …” und zu den “Gemeinsamen Dateien” angezeigt.

Auf diesem Computer gespeicherte Dateien

Wen dies stört, kann dies mithilfe der Gruppenrichtline einfach abstellen.

Hierzu startet man den Richtlinien Editor “Start\Ausführen\gpedit.msc” und öffnet den Zweig:

Benutzerkonfiguration\Windows-Komponenten\Windows Explorer

Dort findet man die Richtlinie:

Gemeinsame Dokumente vom Arbeitsplatz entfernen

Diese aktiviert man und beim nächsten öffnen eines Datei Explorers sind die Ordner mitsamt der Gruppe “Auf diesem Computer gespeicherte Dateien” nicht mehr sichtbar.

Dies und Jenes
Wednesday, March 04, 2009 2:10:51 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [3]  
Autor: Hans-Peter Schelian  |  Trackback
# Monday, March 02, 2009

Auch wenn wir uns im Zeitalter von NET Framework 3.5 befinden ist dieser Beitrag in der Überschrift mit .NET 2.0 beschrieben, da sich in an dem Konzept der Anwendungseinstellungen seit .NET 2.0 keine Änderungen ergeben haben.

Mit dem Konzept der Anwendungseinstellungen wurde ein mehr oder weniger durchgängiges Konzept zur Speicherung und Verwendung von Anwendungs- und Benutzerspezifischen Daten eingeführt.

Bei der Einstellungen für eine Anwendung wird dabei zwischen zwei Bereichen (Benutzer / Anwendung) unterschieden.

Im Bereich Benutzer können die Einstellungen aus dem Programmcode sowohl gelesen als auch geschrieben werden.

Beispiel (Überprüfen ob eine Einstellung korrekt ist, wenn nicht dann aktualisieren und speichern):

// Lagereinheit Report
reportName = Settings.Default.Lagereinheit_ReportName;
if (!File.Exists(reportName))
{
    string tempName = File.GetFilenName(reportName);
    tempName = Application.StartupPath + "\\Reports\\" + tempName;
    if (File.Exists(tempName))
    {
        Settings.Default.Lagereinheit_ReportName = tempName;
        Settings.Default.Save();
    }
}

Im Bereich Anwendung können die Einstellungen aus dem Programmcode lediglich gelesen werden (Schreibgeschützt), der obige Programmcode würde also einen Fehler erzeugen, da die Anwendungseinstellungen Schreibgeschützt sind.

Was aber, wenn man eine Einstellung die als Anwendungseinstellung definiert ist, durch Programmcode ändern und in die Config Datei zurückschreiben muss.

Dann kann man dazu folgende statische Methode verwenden:

private static void setAppSetting(string SettingdName, string SettingValue)
{
    Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
    XmlDocument xmlDoc = new XmlDocument();
    xmlDoc.PreserveWhitespace = true;
    xmlDoc.Load(config.FilePath.Trim());
    XmlNode appSettingNode = xmlDoc.SelectSingleNode("configuration/applicationSettings");
    XmlNode settingNode = appSettingNode.SelectSingleNode(string.Format("//setting[@name='{0}']", SettingdName));
    XmlNode valueNode = settingNode.SelectSingleNode("value");
    valueNode.InnerText = SettingValue;
    xmlDoc.Save(config.FilePath.Trim());
}

Nachfolgend ein Beispiel wie man diese Methode im Programmcode einsetzt um eine “normerweise Schreibgeschütze” Einstellung zu ändern.

// auf normalem Weg lesend auf die Anwendungseinstellung zugreifen
if (Properties.Settings.Default.ApplicationVerladestelle == "DDC") 
{
	// Und hier mit Hilfe der setAppSetting Methode einen neuen Wert zuweisen und in die config Datei schreiben
    setAppSetting("ApplicationVerladestelle", "DCW");  
}

Settings.Default.Reload();  // Nicht vergessen, die aktuellen Werte noch mal zu laden
Code | Tips und Tricks
Monday, March 02, 2009 4:43:27 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [7]  
Autor: Hans-Peter Schelian  |  Trackback
# Friday, February 20, 2009

Bei meinem Dell Notebook “Precision M90” ist plötzlich folgendes Problem aufgetreten:

Nach dem Start des Rechners fährt Windows XP SP 3 ganz normal hoch, jedoch die Netzwerkverbindung über WLAN wird nicht hergestellt.

Das Taskleistensymbol der Intel PROSet/Wireless Netzwerkkarte verbindet sich nicht mit einem der vorkonfigurierten Profile sondern bleibt gelb (nicht verbunden).

Ich öffne also die Steuerung der Intel PROSet/Wireless und sehe das einige WLAN Netzwerke vorhanden sind, auch mein WLAN im Büro.

Ich markiere also das gewünschte Netzwerk und betätige den Button “Verbinden”.

Aber anstelle die Verbindung herzustellen, öffnet sich das Eigenschaft Fenster des ausgewählten Profils, mit dem Profil-Namen und der SSID den Netzwerkes usw. Ich denke, OK, dann gebe ich die Daten halt noch mal ein bzw. bestätige die Daten und speichere das Profil noch einmal. Aber genau dabei tritt das Problem auf.

Ich bekomme eine Meldung:

image

Klar ist das Profil schon vorhanden, und ja ich möchte das existierende Profil überschreiben, beim verwenden des vorhandenen Profils ist ja irgendein Problem aufgetreten (denke ich zu diesem Zeitpunkt jedenfalls noch).

Also auf ”Ja” geklickt und …. schon ist das nächste Problem da !

image 

Ein Profilkennwort Surprised

Ich habe gar kein Kennwort !!!!!

Bei weiteren Versuchen das System irgendwie auszutricksen kommt es dann auch mal zu folgender Meldung

image

Nach vielem hin und her, habe ich dann versucht was geschieht, wenn man sich mit einem anderen Benutzer (oder einen neuen) Benutzer an diesem Rechnern anmeldet. Und siehe da, das (mein) Problem muss wohl irgend etwas mit meinem auf diesem Rechner gespeicherten Profil zu tun haben.

Ich suche also unterhalb von meinen persönlichen Daten in “C:\Dokumente und Einstellungen\[USERNAME]\Anwendungsdaten\” nach dem möglichen Speicherort der Profileinstellungen meiner Intel PROSet/Wireless Karte und werde schnell im Unterverzeichnis “Intel” fündig.

Nachdem ich noch die DAteiberechtigungen geprüft habe aber dabei auch nicht wirklich ein Problem feststellen kann, entschließe ich mich dazu das Verzeichnis Intel einfach zu löschen und hoffe dass ich danach so vorgehen kann als wenn ich bei einem neuem Benutzer die Konfiguration durchführe, und ich sollte damit recht haben.

Das Löschen des Verzeichnis C:\Dokumente und Einstellungen\[USERNAME]\Anwendungsdaten\Intel wobei [USERNAME] für den jeweiligen Benutzernamen steht, brachte den gewünschten Erfolg und ich konnte die neuen Profile einfach wieder anlegen.

Natürlich hatte ich das Verzeichnis bevor ich es gelöscht hatte, erst einmal gesichert, man weiß ja nie !

Ich bin mir nicht sicher wodurch dieses Problem entstanden ist und war bisher auch nicht in der Lage dieses Problem zu reproduzieren, aber eventuell hilft diese Beschreibung ja doch jemand anderem bei der Problembehebung.

Allgemein | Tips und Tricks
Friday, February 20, 2009 9:12:34 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback
# Wednesday, February 18, 2009

Ende letzten Jahres bin ich bei der Recherche nach einer nicht so schwergewichtigen Groupware wie MS Exchange auf die Meldung gestoßen, dass die Software teamXchange der Firma VIPCom unter dem Namen Conversation als Open Source über die Organisation OpenMapi.org veröffentlicht werden soll.

Da ich seit dieser Meldung fast jeden Tag auf der Webseite der OpenMapi.org nachgeschaut habe, ob die Software bereits veröffentlicht ist, habe ich dann im Januar diese Meldung gefunden, welche davon spricht, dass die Software Anfang Februar (genauer gesagt in early February) als Download verfügbar sein wird.

Heute ist der 18. Februar und leider ist noch immer kein Download verfügbar.

Ich bin auf jeden Fall gespannt und kann es kaum noch erwarten mit diese Lösung einmal näher ansehen zu können.

Kommentare von Kennern der Szene (teamXchange) sowohl zum Produkt als auch zu näheren Informationen zur Veröffentlichung würde ich begrüßen.

Allgemein
Wednesday, February 18, 2009 12:39:36 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback

Letzte Nacht wurde die erste CE Version von DotNetNuke Veröffentlicht, ein einfacher Stabilization Release, also nichts neues.

Mehr zu CE und was das soll gab es schon hier in meinem Blog Beitrag.

Die Version 4.9.2 kann man hier auf Codeplex herunterladen.

Und unter support.dotnetnuke.com findet man mehr zu der einen Hand voll Änderungen in dieser Version

DotNetNuke
Wednesday, February 18, 2009 9:35:00 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [2]  
Autor: Hans-Peter Schelian  |  Trackback
# Monday, February 16, 2009

Wer Vorgestern (Valentinstag) die Seite www.dotnetnuke.com besuchen wollte, wurde von einer netten Meldung “Diese Seite ist zur Zeit wegen geplanter Wartungsarbeiten nicht ONLINE, versuchen Sie es später” darüber informiert, dass irgendwelche Update Arbeiten durchgeführt werden. Das war sicherlich nicht das erste mal, dass diese Meldung auf www.dotnetnuke.com oder einer anderen Webseite zu lesen war, aber diese Meldung Vorgestern war dann doch etwas besonderes.

Denn plötzlich ist alles anders (oder doch nicht). –> DotNetNuke geht nun auch Professional (Das ging auch schon vorher und das sogar ohne die PE und ohne die DNN Corp.)

imageAb sofort gibt es also 2 Versionen eine Community Edition (CE) und einer Professional Edition (PE).

Die Frage die sich stellt ist doch: Was ist denn der Unterschied zwischen den Versionen ?

Laut Aussage auf der Webseite www.dotnetnuke.com soll die Professional Edition folgendes sein:

  • Stable (Stabil)
  • Secure (Sicher)
  • Certified (Zertifiziert)
  • Supported (Unterstützt …)

Laut Aussage der DNN Corp. auf www.dotnetnuke.com soll aber auch:

Die CE und die PE keine andere Programmversion sein (Upgrade von CE auf PE ohne Programmupdate möglich)

Die PE ist eine zertifizierte Fehlerbereinigte CE Version – Dabei stellt sich mir die Frage von wem Zertifiziert ? – Von DNN Corp Wink

Und nicht zu vergessen, man erhält auch noch Garantien zur Performance und …. noch eine Menge mehr Marketing Sprüche !

Ich finde es unglücklich dass man hier versucht ein Produkt zu erfinden, welches es “so” gar nicht gibt, wenigstens nicht dann, wenn DNN Corp. das macht was sie sagen/schreiben. Es wäre sicherlich richtiger dieses Produkt zum Beispiel:

DotNetNuke Professional Services (Kann ich diesen Begriff jetzt mit © H-P Schelian verwenden)

zu nennen.

Da wüsste man auch anhand des Namens gleich um was es sich eigentlich handelt.

Aber was hat diese “Neue” PE Version für Auswirkungen auf die Community und vor allem was hat das für Auswirkungen auf den nicht englisch Sprachigen (Insbesondere den Deutschsprachigen) Raum.

Da ich selbst seit vielen Jahren Professionelle Dienste wie Portal und Modulentwicklung, First und Second Level Support, Umsetzung von Mehrsprachigen Portalen sowie Hosting rund um DotNetNuke und vor allem im Deutschsprachigen Raum anbiete sehe ich dieser Entwicklung im Hinblick auf das Geschäft in eben diesem Deutschsprachigen Raum so gut wie gar nicht betroffen.

Wo ich das gerade aufschreibe, fällt mir auf, dass mit Ausnahme das ich noch nie versucht habe mich selbst zu zertifizieren Thinking, der Rest bereits nach DNN PE klingt.

DNN Corp. hat wie viele andere rein Amerikanische Unternehmen / Gruppierungen bis heute nicht verstanden was wir (in nicht englischen Sprachräumen) eigentlich wollen und benötigen. Sie verstehen das Theater um Lokalisierung und Mehrsprachigkeit von Anwendungen noch immer nicht wirklich, oder besser gesagt, es interessiert sie einfach nicht wirklich.

Also ich freue mich endlich mal eine stabile Version zu bekommen, ohne dass ich dazu noch eigene Änderungen am Code durchführen muss, der, selbst wenn ich ihn hundert mal einreichen würde nicht in das Core Produkt eingebaut bekommen würde, ich spreche halt die falsche “Mutter”Sprache.

To be continued … Sarcastic Entschuldigung – Fortsetzung folgt …

DotNetNuke
Monday, February 16, 2009 8:35:05 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [1]  
Autor: Hans-Peter Schelian  |  Trackback
# Friday, February 13, 2009

Von Zeit zu Zeit kommt es vor, dass man ein Verzeichnis welches sich unter Versionskontrolle (Subversion – TortoiseSVN) befindet,  einfach kopieren und aus dieser Kopie die Versionskontrolle entfernen möchte (Entfernen aller .svn oder _svn Verzeichnisse und deren Inhalt). Ich möchte damit eine echte Kopie aller Dateien (mit Ausnahme der Dateien der Versionskontrolle) erhalten welche sich in dem Projekt befindet, damit meine ich auch die Dateien und Verzeichnisse welche von der Versionskontrolle ausgeschlossen sind.

Klar kann man das mit dem Explorer Suchfunktion machen.

Projekt Kopieren und dann in der Kopie nach den Verzeichnissen mit _svn oder .svn (je nach eingestellter Option) suchen und diese dann anschließend markieren und löschen.

Explorer Suchfenster

Ein wie ich finde eleganterer Weg aber ist es dies durch TortoiseSVN selbst erledigen zu lassen.

Und hierzu gibt es eine ganz einfache Methode:

Man markiert das kopierte Verzeichnis, Rechtsklick mit der Maus und Kontextmenü TortoiseSVN und dort das Untermenü Export aufrufen.

Wenn man nun als Zielverzeichnis das Quellverzeichnis selbst angibt, dann stellt TortoiseSVN dies fest uns fragt:

Wollen Sie die Arbeitskopie aus der Versionskontrolle entfernen?

Wenn man nun mit Ja dieses Dialogfeld bestätigt, dann entfernt TortoiseSVN aus dem Verzeichnis alle Dateien und Verzeichnisse der Versionskontrolle.

Als Ergebnis erhält man also eine Arbeitskopie ohne Bezug auf die Versionskontrolle.

Note | Tools
Friday, February 13, 2009 8:04:53 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [5]  
Autor: Hans-Peter Schelian  |  Trackback
# Thursday, February 12, 2009

Nachdem man, Vorausgesetzt man hat das DotNetNuke Starterkit installiert, mit Visual Studio 2008 eine neue Webseite “DotNetNuke Application Framework” erstellt und konfiguriert hat, kommt es dazu (eventuell kommt es auch nur in bestimmten Fällen dazu), dass nach dem ersten Aufruf der fertig eingerichteten Webseite beim nächsten Start (Kompilierung) folgende 6 Fehler in Visual Studio angezeigt werden und die Webseite nicht mehr aufgerufen werden kann:

Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fcklinkgallery" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckCSS" konnte nicht geladen werden Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.FckHtmlEditorOptions" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckinstanceoptions" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckimagegallery" konnte nicht geladen werden.	Der Typ "DotNetNuke.HtmlEditor.FckHtmlEditorProvider.fckStyles" konnte nicht geladen werden.

Da ich an dieser Stelle keine umfangreiche Abhandlung über die Gründe dieses Problems halten möchte folgt hier einfach kurz und knapp ein Workaround.

Man kopiert die Datei “DotNetNuke.FckHtmlEditorProvider.dll” aus dem BIN\Provider Verzeichnis der DotNetNuke Installation in das BIN Verzeichnis der DotNetNuke Installation.

Nun einfach das Projekt neu übersetzen “Webseite erstellen” – Fertig !!!!

Dieser Workaround trifft auf folgende Konfiguration zu:

  • Windows XP SP3
  • Visual Studio 2008 SP1
  • DotNetNuke Version 5.00.00
  • FckHtmlEditorProvider Version 2.0.2.1
DotNetNuke | Entwicklung
Thursday, February 12, 2009 2:55:25 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [0]  
Autor: Hans-Peter Schelian  |  Trackback
# Wednesday, February 11, 2009

Während der Installation von DotNetNuke 5 wird die Verwendung von Ajax 1.0 automatisch eingerichtet.

Das geschieht unter anderem dadurch, dass eine System.Web.Extension DLL Datei in das BIN Verzeichnis von DotNetNuke kopiert wird.

Wenn man sich später am Portal als Host Administrator anmeldet und die Host Einstellungen öffnet findet man dort einen Link mit dem man das Portal auf das aktuelle Framework (Ajax Version 3.0 welches mit dem ASP.NET Framework 3.5 ausgeliefert wird) umstellen kann (siehe nachfolgende Abbildung).

Update Site to current Framework

Mit dem betätigen des Links werden 2 Dinge durchgeführt:

  • Die Web.Config wird für Ajax 3.0 eingerichtet
  • Die System.Web.Extension DLL wird aus dem BIN Verzeichnis von DotNetNuke gelöscht.

Das ganze funktioniert, soweit ich das bisher beurteilen kann, sehr zuverlässig.

Und trotz der Zuverlässigkeit dieser Funktion kann es später unter bestimmten Umständen sehr leicht zu folgendem Fehler kommen:

An error has occurred. DotNetNuke.Services.Exceptions.PageLoadException: Object reference not set to an instance of an object. ---> System.NullReferenceException: Object reference not set to an instance of an object. at DotNetNuke.UI.Utilities.MSAJAX.get_IsInstalled() at DotNetNuke.UI.Utilities.MSAJAX.RegisterStartupScript(Page objPage, String Key, String Script) at DotNetNuke.UI.Utilities.ClientAPI.RegisterStartUpScript(Page objPage, String key, String script) at DotNetNuke.Framework.DefaultPage.InitializePage() in C:\dnn5\Website\Default.aspx.vb:line 202 at DotNetNuke.Framework.DefaultPage.Page_Init(Object sender, EventArgs e) in C:\dnn5\Website\Default.aspx.vb:line 452 at System.Web.UI.Control.OnInit(EventArgs e) at System.Web.UI.Page.OnInit(EventArgs e) at DotNetNuke.Framework.PageBase.OnInit(EventArgs e) in C:\dnn5\Library\Framework\PageBase.vb:line 545 at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) --- End of inner exception stack trace ---

Die Ursache für dieses Problem ist. das nach der Umstellung des Framework, aus welchem Grund auch immer, die System.Web.Extension DLL Datei wieder im BIN Verzeichnis von DotNetNuke vorhanden ist.

Das geschieht natürlich nicht aus versehen oder von selbst, aber durch eine Sicherung die man zurückspielt oder durch Verwendung einer Versionsverwaltung kann das ganz schnell geschehen.

Abhilfe schafft das einfache löschen dieser System.Web.Extension DLL Datei aus dem BIN Verzeichnis von DotNetNuke.

Eventuell muss man noch den Applikation Pool abschießen oder alternativ einfach die web.config mit einem Editor öffnen und speichern, damit dadurch das Portal neu gestartet wird.

DotNetNuke | Installation
Wednesday, February 11, 2009 5:42:57 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [1]  
Autor: Hans-Peter Schelian  |  Trackback
Copyright © 2010 Hans-Peter Schelian - Schelian IT Beratung. All rights reserved.