Der Open Source VMFS Driver ist ein nützliches Tool um auf das Dateisystem eines VMware ESXi Servers zuzugreifen.

Das Tool lässt sich unter http://code.google.com/p/vmfs kostenlos runter laden.

Zur Ausführung wird Java benötigt.

Zuerst schließt man die Festplatte an den Windowsrechner an und öffnet die Datenträgerverwaltung. Dort erkennt man die Festplatte daran, dass bei den Partitionen kein Dateisystem angezeigt wird. Wichtig ist hier die Datenträger Nummer, diese ist links zu finden. Die müssen wir uns merken.

Jetzt öffnen wir eine Konsole im Administrator Modus.

Mit dem Befehl

java -jar fvmfs.jar \\.\PhysicalDrive4 info

können wir uns Informationen über das Laufwerk anschauen. (Hier die richtige Datenträgernummer nutzen)

Es stehen folgende Befehle zur Verfügung:

info
dir path
dirall path
fileinfo path
filecopy path [newname position size]
filedump path position size
webdav [host port]

eine genau Anleitung findet man unter: http://code.google.com/p/vmfs/wiki/CLI

Ich habe mich die letzten Tage mal wieder mit Drucken in .NET beschäftigt und habe dabei wieder festestellen müssen, dass Probleme, die schon seit langem bekannt sind, nach wie vor vorhanden sind.

1) PrintDialog und die x64 Welt…

Wer kennt ihn nicht, den guten alten Drucken-Dialog.

PrintDialog

Eigentlich denkt man sich, hier kann man nicht viel falsch machen.

PrintDialog pd = new PrintDialog();
pd.Document = myPrintDocument;
var result = pd.ShowDialog();

Das funktioniert auch alles wunderbar - solange man entweder in x86; oder aber auf AnyCPU kompiliert und die Anwendung auf einem 32-Bit Betriebssystem ausführt. Aber wehe, man kommt auf die Idee etwas x64 oder AnyCPU-kompiliertes auf einem 64-Bit Betriebssystem aufrufen zu wollen. Denn dann passiert beim Aufruf von ShowDialog() nämlich überhaupt nichts…

Es gibt ein Workaround:

pd.UseEXDialog = true;

Damit wird der alte XP Style für diesen Dialog verwendet und dann wird das Drucken Dialogfenster auch unter x64 korrekt aufgerufen:

Drucken-Dialog XP Style

Was wirklich traurig ist, dass dieses Fehlverhalten bereits seit dem .NET 2.0 Framework existiert. Es wurde weder in 3.0, noch in 3.5 oder 3.5 SP1 behoben. Aber: jetzt kommt die gute Nachricht, in .NET 4.0 hat man sich der Problematik endlich angenommen und es funktioniert dort nun auch ohne den XP Style Trick… Das wurde auch Zeit

2) PageSetupDialog und die metrische Welt

Seite einrichten Dialog

Auch beim PageSetupDialog denkt sich vielleicht der ein oder andere, dass man nicht viel verkehrt machen kann:

PageSetupDialog psd = new PageSetupDialog();
pd.Document = myPrintDocument;

Das funktioniert auch einwandfrei, aber wenn man nun den Dialog nacheinander mehrmals startet und mit OK bestätigt, werden die Ränder bei jedem mal kleiner, obwohl man keinerlei Änderungen (Links / Oben / Rechts / Unten) gemacht hat. Grund ist ein interner Umrechnungs-Fehler.

Das Problem ist seit langem bekannt, es gibt sogar einen Microsoft KnowledgeBase Artikel zu dieser Problematik: BUG: The margin value decreases every time PageSetupDialog is displayed.

Es wird darin allen Ernstes empfohlen, dass der Benutzer der Anwendung die Regionaleinstellungen seines Betriebssystems auf das Angloamerikanische Maßsystem umstellen soll, um den Fehler zu umgehen. Wenn man das aus Sicht des Entwicklers liest, fragt man sich aber, ob das so wirklich Sinn macht… *g

Andere Entwickler sahen das auch so und haben sich das ein oder andere dazu einfallen lassen, siehe z.B. hier in einem Artikel von 2004 über VB .NET, in dem eine Korrektur-Umrechnungsformel entwickelt wurde.

Was aber wirklich hilft, und auf was Microsoft eigentlich auch viel eher in ihrer KnowledgeBase hinweisen sollte, ist:

psd.EnableMetric = true;

Damit werden die Werte der Ränder auf einem metrischen System auch von Anfang an korrekt 1:1 angezeigt und nicht umgerechnet. Es empfiehlt sich, dieses Flag fallweise auf Grund der aktuell eingestellten Regionseinstellungen zu setzen, damit die Anwendung wirklich international funktioniert, also konkret:

psd.EnableMetric = System.Globalization.RegionInfo.CurrentRegion.IsMetric

PS: Diese “spezielle” Verhalten ist bis einschließlich .NET 4.0 vorhanden, ich denke mal Microsoft sieht das nicht als Fehler, da es im amerikanischen Raum eh nicht auftritt - und wer für Europa programmiert, muss das halt einfach wissen.

rch das geniale Extension-Konzept der 2010er Version lässt sich Visual Studio nach Belieben um Funktionalitäten erweitern. Es gibt bereits eine Vielzahl verfügbarer freier Erweiterungen, auf die man zurückgreifen kann.

Folgende Extensions halte ich persönlich für die tägliche Arbeit äußerst hilfreich:

• Collapse Selection In Solution Explorer
  Fügt einen zusätzlichen Knopf (und eine Tastenkombination) in den Solution Explorer ein, der es ermöglicht alle Elemente (ab dem derzeit selektierten) einzuklappen.
• HelpViewerKeywordIndex
  Integriert Index und Suchfeld für die lokal installierte Hilfe (siehe auch diesen Blogeintrag).
• PowerCommands for Visual Studio 2010
  Erweitert VS2010 um sehr viele kleine nützliche Funktionen (Open Containing Folder, Close All, Copy Class, etc.)
• Regex Editor
  Erleichtert das Schreiben von regulären Ausdrücken.
• Visual Studio Color Theme Editor
  Ermöglicht die farbliche Anpassung des “neuen” Visual Studio 2010 Designs.

Die Installation der Extensions ist denkbar einfach, entweder man lädt diese auf den angegebenen Seiten herunter und startet die entsprechende VSIX-Datei. Oder aber man ruft in Visual Studio 2010 über das Menü Tools den Extension Manager auf. Anschließend auf “Online Gallery” gehen und die gewünschte Erweiterung installieren (ggf. vorher über die Suchfunktion oben rechts filtern).

Wenn ich auf neue, äußerst hilfreiche Extensions stoße, werde ich diesen Blogeintrag entsprechend ergänzen

Was sich in Visual Studio 2010 drastisch geändert hat, ist die integrierte Hilfe. Diese läuft inzwischen entweder nur noch ausschließlich online auf dem Microsoft Webserver, oder alternativ (sofern man dies einstellt) auf einem Webservice auf der eigenen Maschine. Wählt man letzteres, so kann man ausgewählte Hilfsthemen lokal installieren.

Allerdings ist Ausgestaltung der Funktionalität in der derzeitigen Version leider noch recht mager - zumindest, wenn man sie an der früheren Hilfe misst. Es gibt kein Gesamtinhaltsverzeichnis (Table of Contents) mehr, keinen Index, keinen Filter, etc. Lediglich eine Volltextsuche ist noch vorhanden.

Es gibt aber glücklicherweise 3rd Party Tools, die zumindest Teile dieser Funktionalitäten wieder möglich machen.

Eine Variante ist der H3Viewer, ein externes Programm, welches sich auf die lokale Hilfe verbindet und die wichtigsten “Hilfsmittel” wieder zur Verfügung stellt (TOC, Index, Lesezeichen, u.s.w.) - es liest einem bei Bedarf sogar die Hilfe vor, wenn man dies denn möchte…

H3Viewer - Anzeige der Visual Studio 2010 Hilfe

Eine Alternative oder Ergänzung ist die VisualStudio 2010 Erweiterung HelpViewerKeywordIndex. Diese integriert sich direkt in Visual Studio 2010 und bietet zumindest wieder einen Index.

Visual Studio 2010 Extension: HelpViewerKeywordIndex

P.S.: Die Möglichkeit, Visual Studio 2010 mittels vorhandener Extensions beliebig zu erweitern und auch selbst welche zu schreiben, halte ich für eine der besten neuen Errungenschaften der 2010er Version.

Der neue Team Foundation Server 2010 Server ist schon eine tolle Sache, und man muss zugeben, dass sich seit der letzten Version einiges getan hat. Auch im Bereich vereinfachter Installation (selbst im “Advanced” Modus). Und er unterstützt endlich auch x64 Betriebssysteme wie Windows Server 2008 R2 x64.

Über eine Sache bin ich dennoch gestolpert, und zwar was das Anlegen von neuen Projekten aus dem Visual Studio 2010 Team Explorer unter bestimmten Benutzern angeht:

Visual Studio 2010 - Fehler beim Anlegen von TFS Projekten

Sprechen Sie auch Germisch? Ich “liebe” immer diese halb deutschen, halb englischen Sachen…

Folgende URL konnte mir bei der Behebung des Problems helfen:
How to: Set Administrator Permissions for Reporting Services

Denjenigen, die auch einmal ein bisschen mit dem neuen TFS 2010 herumspielen wollen, kann ich folgende Installations-Anleitung sehr ans Herz legen.

Wenn man Projekte im Team abwickelt, kommt es vor, dass die gleichen Dateien von mehreren Leuten gleichzeitig bearbeitet werden. So hat man selbst schon Änderungen vorgenommen, es liegen aber gleichzeitig bereits neue, widersprüchliche Änderungen in der Quellcodeverwaltung (Team Foundation Server, etc.) vor.

Visual Studio bietet hier bereits einige sehr brauchbare Mechanismen, insbesondere auch den automatischen Abgleich (Merge), der recht gut funktioniert.

Ab und an kommt man aber nicht umher, Dinge auch manuell abzugleichen bzw. Änderungen zwischen Versionen visuell zu inspizieren. Hier konnte ich mich noch nie wirklich mit dem in Visual Studio integrierten Tool anfreunden. Ein Kollege hatte mir vor kurzem einen guten Tipp gegeben:
das Freeware-Programm WinMerge.

WinMerge beim Vergleich/Abgleich von zwei Quelltexten

Es lässt sich auch vollständig in Visual Studio integrieren: Menü Tools / Options / Source Control / Visual Team Foundation Server / Configure User Tools…

Und hier dann zwei neue Einträge anlegen:

Visual Studio - WinMerge Integration Compare

Hier nochmal copy/paste freundlich: /x /e /ub /wl /dl %6 /dr %7 %1 %2

Visual Studio - WinMerge Integration Merge

Hier nochmal copy/paste freundlich: /x /e /ub /wl /dl %6 /dr %7 %1 %2 %4

Ab jetzt lässt sich WinMerge sowohl zum Vergleich von Quelltexten (z.B: über die History-Funktion), als auch zum Abgleich von widersprüchlichen Quelltexten (über Merge beim Checkin) verwenden.

Microsoft Outlook, sowie auch Microsoft Exchange haben die schlechte Angewohnheit unter bestimmten Umständen anstatt einem regulären Dateianhang eine so genannte TNEF-codierte winmail.dat Datei anzuhängen, in der dann die eigentlichen Dateianhänge, Nachrichten, etc. enthalten sind.

Geht die E-Mail von Outlook zu Outlook, bekommt der Benutzer das im Normalfall niemals mit, für den Empfänger sieht die E-Mail und auch all ihre Dateianhänge ganz normal aus.

Aber wehe, die E-Mail geht an Empfänger anderer E-Mail Clients, wie Lotus Notes, TheBat!, etc. Hier kommt es regelmäßig vor, dass derjenige dann nur eine winmail.dat bekommt, mit der er dann recht wenig anfangen kann.

Ich habe vor kurzem ein nützliches Tool im Internet gefunden, welches genau bei dieser Problematik hilft - den Winmail Opener. Das kostenfreie Programm ermöglicht es, die
winmail.dat zu öffnen, deren Inhalte zu sichten und im Bedarfsfall auch abzuspeichern
(ähnlich wie ein Dateiarchiv).

Winmail Opener: Geöffnete winmail.dat

Das Programm lässt sich auch als Standard-Programm für alle .dat-Erweiterungen einstellen
(sofern man über ausreichende Rechte auf dem Windows-Rechner verfügt):

Winmail Opener: Als Standard einstellen

Dies hat den Vorteil, dass man dann direkt per Doppelklick auf eine solche winmail.dat sofort in dem Program landet und sich die Dateianhänge ansehen und ggf. woanders hin speichern kann.

Mehr zu dem Thema winmail.dat, und wie man es Outlook unter bestimmten Umständen auch ganz austreiben kann, solche Dateien überhaupt zu versenden, unter folgenden externen Blogs:

• How to Prevent Winmail.dat Attachments from Being Sent in Outlook
• Outlook: Winmail-Dat-Problem

Seit Anfang 2010 markiert SpamAssassin jede eingehende Mail fälschlicherweise als SPAM…
Man könnte es fast als immer wiederkehrende “Neujahresgrüße” bezeichnen, wenn es nicht so gravierend wäre und Systeme weltweit betreffen würde. Selbst große E-Mail-Dienstanbieter wie 1&1 und GMX waren davon beeinträchtigt…

Schuld daran ist eine veraltete Standard-Regel in der Datei /usr/share/spamassassin/72_active.cf:

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

Damit wird jede E-Mail ab dem 01.01.2010 als “grob fahrlässig aus der Zukunft” gewertet und als [*****SPAM*****] eingestuft:

pts rule name            description
--- -------------------- ----------------------------------
3.2 FH_DATE_PAST_20XX    The date is grossly in the future.

Das Problem scheint schon seit längerem bekannt zu sein und wurde wohl auch bereits am 21.Jul.2009 korrigiert, wie man hier nachlesen kann.

Nur dass scheinbar vergessen wurde, dass Problembeseitigung nicht das Ende vom Lied ist. Man muss auch sicherzustellen, dass alle bereits auf der Welt laufenden Server diese verbesserte Regel in einer automatisierten Form erhalten können.

Eigentlich existiert eine Automatik dafür, mittels sa-update lassen sich geänderte Regeln abgleichen. Aber die Regel scheint (bisher) leider nicht wichtig genug zu sein, als dass sie in aktualisierter Form in diesen Updates eingeschlossen wird.
 

Daher folgende 2 manuelle Lösungsmöglichkeiten:

1. Man ändere die Regel in der /usr/share/spamassassin/72_active.cf auf:

   header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]

   Damit hat man den offiziellen Stand eingespielt, welcher das Problem aber eigentlich auch nur wieder verschiebt, nämlich auf den 01.01.2020, denn dann greift die neue Regel wieder. Ich schätze, die Entwickler haben sich wohl gedacht “so können wir das erst mal aufschieben, und wie überlegen uns dann später, wie wir das Problem programmiertechnisch lösen, in dem wir z.B. das tatsächliche Datum mit einbeziehen…”
   Allerdings gibt es bei dieser Lösungsvariante (zumindest zum Zeitpunkt dieses BLOG-Eintrages) noch die Problematik, dass die Regel über sa-update wieder auf den alten Stand zurückgesetzt wird.
2. Oder man ergänze folgenden Zusatzeintrag in der /etc/spamassassin/local.cf Datei:

   score FH_DATE_PAST_20XX 0.0

   Damit wird diese Regel komplett ignoriert, unabhängig davon, wie diese in Zukunft auch aussehen mag.

Man fragt sich, was in der Softwareentwicklung als nächstes kommt. Zuerst die große Panik um Y2k (Jahr 2000), jetzt 2010… Wahrscheinlich weiß nur Murphy wirklich, wo das alles endet

Es hat Spaß gemacht, mit Torsten Borth an einem Schlüsselprojekt rund ums ERP zu arbeiten. Engagiert konstruktives Mitdenken und umsetzen - bei hoher Fachkompetenz zu jeder Zeit.
Kurz: Gerne wieder :-) 

 

Wolfgang Weigelt
Manager I.T., Applications
Tupperware Deutschland GmbH

Projektart: Mitentwicklung eines neuen Client/Server-basierten Anwendungsframeworks & ERP-Systems.

Agentur: runtime Software GmbH, Waiblingen

Technologien: .NET 3.5 SP1, C#, VB .NET, Microsoft Smart Client Software Factory (SCSF), Model/View-Presenter (MVP), MSSQL Server 2005/2008,
ADO .NET Entity Framework, LINQ

Angefangen hat es mit meinem in die Tage gekommen Laptop mit Vista, dieser ist teilweise nach 5-10 Minuten wieder aus den Energiesparmodus aufgewacht. Das ist natürlich beim Transport nicht so gesund, wenn das Gerät in der Tasche angeht. Also war jedes mal vor dem Transport langwieriges Herunterfahren und danach noch langwierigenderes Booten notwendig. Nun hab ich allerdings das gleiche Problem bei meinem neuen Laptop mit Windows 7.

Hier ein paar Tipps wie man das Problem beseitigen kann.

Wonach man zuerst schauen sollte ist die Ereignisanzeige.

Unter dem Punkt Windows-Protokolle/System am besten nach Power-Troubleshooter filtern.

Hier findet man Informationen was den Rechner einschaltet hat.

Ist es ein Gerät kann man die Funktion Das Gerät kann den Computer aus dem Ruhezustand aktivieren im Gerätemanager oder mit Powercfg deaktivieren.

Oft wird allerdings nur RTC oder unbekannt angzeigt.

In diesem Fall können wir und in der Console mit dem Befehl Powercfg helfen.

powercfg -lastwake zeigt Informationen zum letzten Aufwachen an.

powercfg -DEVICEQUERY wake_armed zeigt alle Geräte an die den Computer aus dem Energiesparmodus aufwecken können.

powercfg -DEVICEDISABLEWAKE <Gerätename> entzieht dem Gerät das Recht den Computer aus dem Ruhezustand aufzuwecken.

Hat man die Funktion bei allen Geräten deaktiviert sollte  das Problem in den meisten Fällen behoben sein.

Ist das nicht der Fall gibt es noch die Möglichkeit das Aufwachen per Registry-Eintrag zu deaktivieren.

Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\BD3B718A-0680-4D9D-8AB2-E1D2B4AC806D

und allen Unterordnern gilt es alle Einträge von 1 auf 0 umzustellen.

Dadurch wird die Wake-On-Timer Funktion komplett deaktiviert.

Das bedeutet allerdings auch kein Task mehr in der Aufgabenplanung, wie z.B. die Mediacenter recording Funktion, kann den PC aus dem Energiesparmodus aufwecken.

Allerdings sollte man an dieser Stelle sein System doch mal gründlich nach Trojaner untersuchen, denn es existieren einige die sich diese Funktion zunutze machen um den PC erreichbar zu halten.

Quellen: Microsoft Microsoft Technet