Kindle Uploader

Der Kindle als eBook Reader macht vieles richtig. Nur beim Übertragen von eigenen Dokumenten wird es schwierig. Es gibt zwar die Möglichkeit Dokumente per Mail oder USB auf den Kindle zu bringen, allerdings wird das in manchen Fällen etwas umständlich.

Der Kindle Paperwhite im ausgeschalteten Zustand

Der Kindle Paperwhite im ausgeschalteten Zustand

So bietet Amazon eine Konvertierung von PDFs in ein auf dem Kindle lesbares Format an. Um das ganze zu vereinfachen, habe ich eine kleine Anwendung namens „Kindle Uploader“ geschrieben. Nach der Konfiguration kann man ganze Ordner oder auch einzelne Dateien an seinen Kindle senden. Mit Hilfe der Option „-convert“ ist es möglich die Konvertierung in das AZW Format (für bessere Lesbarkeit) anzustoßen:

kindleuploader.exe -convert test.pdf folder test.txt

Die Anwendung ist dabei freie Software unter der GPLv3 und kann auf GitHub „besichtigt“ werden. Alternativ kann das ganze als ausführbare Datei heruntergeladen werden.

MonoDevelop und die invalide Warnungsnummer

Manchmal ist Mono Develop etwas undurchsichtig. So bekam ich bei einem Projekt welches ich neu kompilieren wollte mehrmals die Fehlermeldung:

Error CS1904: `' is not a valid warning number (CS1904) (CSCL)

Der Compiler beschwert sich hierbei darüber, das eine spezifizierte Warnungsnummer nicht existiert. Allerdings ist es schwierig eine nicht vorhandene Nummer zu finden.

Die Compiler Optionen

Die Compiler Optionen

Die Lösung lag in den Compiler Optionen des Projektes. Hier befand sich unter „Warnungen ignorieren“ die Zeile:

0168 ; 0169; 0414; 0618; 0649

Das Problem an dieser Zeile waren die Leerzeichen, welche von MonoDevelop als zu ignorierende Warnungen interpretiert wurden. Und eine Warnung ohne Nummer kennt das System natürlich nicht. Nach dem Entfernen der Leerzeichen, kompilierte auch das Projekt wieder.

de4dot

Ein Programm welches in C# geschrieben wird, wird beim kompilieren in ein Intermediate-Assembly umgewandelt. Das bedeutet das der Code in einer Zwischensprache darauf wartet auf seinem Zielsystem in nativen Code umgewandelt zu werden. Der Vor- und auch Nachteil dieser Vorgehensweise ist, das sich der Quellcode sehr einfach aus dem IL-Code zurückwandeln lässt. Im Idealfall verliert man bloß einige Variablennamen.

Um das zu verhindern gibt es sogenannte Obfuscatoren, welche versuchen den entsprechenden Quelltext zu verschleiern, so das er nicht mehr einfach zurückgewandelt werden kann. Aber wie so oft im Leben gibt es auch hier einen Wettlauf mit der Zeit. So gibt es einige Tools welche den obfuskierten Quelltext wieder deobfuskieren. Eines dieser Projekte ist „de4dot“ welches unter https://bitbucket.org/0xd4d/de4dot/ zu finden ist. Das unter der GPL stehende Projekte, erkennt dabei den verwendeten Obfuscator und versucht seine Änderungen soweit wie möglich rückgängig zu machen. Dabei werden eine stattliche Anzahl von Obfuscatoren, wie der Dotfuscator, Goliath.NET und Skater.NET unterstützt.

Controls im Visual Studio zur Designzeit debuggen

Die Entwicklung von Controls unter .NET und Windows Form geht eigentlich relativ leicht von der Hand. Kompliziert wird das ganze immer dann wenn Fehler auftreten. So lassen sich Controls welche im Designmodus Exceptions werfen, nur schwer debuggen. Aber wie immer gilt, wo ein Wille ist, da ist auch ein Weg.

Das Attach to Process Fenster

Das Attach to Process Fenster

Um ein Control zu debuggen, sollte man das entsprechende Projekt bzw. die Solution zwei mal öffnen. In dem einen Visual Studio öffnet man nun den Designer. Im anderen Visual Studio wählt man im Debugmenü den Punkt „Attach to Process…“ aus. Das sich öffnende Fenster zeigt alle Prozesse an, an welche sich der Debugger anhängen kann. Hier wird das erste Visual Studio (das mit dem Designer) ausgewählt. Nun kann man im Quelltext des Controls Breakpoints setzen und somit die Ausführung überwachen. Allerdings sollte man sich dabei nicht wundern, das dass Control im Debugger größer erscheint als es eigentlich ist. Der Grund dafür liegt darin, das genau genommen nicht das Control sondern das gesamte Visual Studio debuggt wird.

Threadsicheres Dictionary unter .NET

Das Dictionary unter .NET ist eine schöne Datenstruktur mit der man effizient Schlüssel- und Wertepaare verwalten kann:

Dictionary<uint, byte[]> idToValues=new Dictionary<uint, byte[]>();
idToValues.Add(1, data);

Problematisch wird das ganze, sobald in mehreren Threads gearbeitet wird, welche alle auf das gleiche Dictionary zugreifen. Hier müssen die Zugriffe auf das Wörterbuch kontrolliert und entsprechend gesperrt werden. Einfacher wird es mit der 4er .NET Framework. Dort gibt es ein ConcurrentDictionary welches von Haus aus threadsicher ist und dem Entwickler eine Menge Arbeit erspart.

ConcurrentDictionary<uint, byte[]> idToValues=new ConcurrentDictionary<uint, byte[]>();
idToValues.TryAdd(1, data);

Das „ConcurrentDictionary“ kann dabei im Großen und Ganzen wie ein normales Dictionary genutzt werden, so das die Umstellung nicht allzu schwer fallen sollte.