.NET und PDF Software

Alles Gute hat ein Ende, so auch meine Software WordToPDF und der Shareware-Ableger WordToPDF (Pro). Ich habe diese Software immer als Hobby betrachtet, schaffe es aber leider nicht mehr, die Software im notwendigen Umfang zu pflegen.

Die aktuelle Marktlage macht es auch schlicht nicht erforderlich. Die meisten Office-Programme können PDFs zwischenzeitlich in guter Qualität nativ erzeugen. Tools, wie eDocPrintPro, bieten außerdem einen immensen Funktionsumfang zum Nulltarif.

Wer auf die letzte Version von WordToPDF (Pro) updaten möchte, kann dies gern mit diesem Setup tun. Eine Unterscheidung zwischen WordToPDF und WordToPDF Pro gibt es nicht mehr.

Noch einen Nachsatz: Diese Version bietet eine Unterstützung bis einschließlich Office 2013. Office 2016 wird lediglich als unbekannte Version erkannt. Ich biete keinen Support mehr für diese Software an. Die Seite http://www.smile-to-me.de wird von mir nicht mehr betrieben.

Auf einem frisch installierten Windows 8.1 Rechner kam es bei der Nutzung des signtool’s zur Fehlermeldung

Signtool requires CAPICOM version 2.1.0.1

Die CAPICOM kann man bei Microsoft herunterladen, allerding bleibt der Fehler dann bestehen.

Die Lösung ist die manuelle Registrierung der CapiCom.dll:

regsvr32 "C:\Program Files (x86)\Microsoft CAPICOM 2.1.0.2 SDK\Lib\X86\CapiCom.dll"

Beim Öffnen großer Formulare in Visual Studio Formular Designer (WinForms) tritt teilweise das Problem auf, dass Visual Studio 2012/2013 wegen eines Problems beendet wird. In der Ereignisanzeige wird dabei ein Problem in der KERNELBASE.dll vermerkt.

Die Lösung ist dann eigentlich trivial: Es muss der Dienst Performance Logs & Alerts (pla) gestartet werden.

Es besteht nun die Vermutung, dass der Formulardesigner einfach eine Performance-Warnung melden wollte und das nicht konnte, weil der Dienst nicht aktiv war.

Seit einigen Monaten nervte in einer Microsoft SQL 2008 Datenbank ein Problem, welches gelegentlich auftrat. Auf die betreffende Datenbank waren ab einem scheinbar zufälligen Zeitpunkt keine schreibenden Zugriffe mehr möglich, lesende Zugriffe aber schon. Ein einfacher Blick nach der Verfügbarkeit reichte also nicht, um die Lauffähigkeit der Datenbank zu testen.

Ein Blick in die Log-Dateien brachte die Erkenntnis, dass diese Datenbank ziemlich oft gestartet wurde (im Gegensatz zu den anderen Datenbanken) und plötzlich ein Fehler 1205 auftrat:

Transaction (Process ID …) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Danach war die Datenbank schreibend nicht mehr verfügbar, der Fehler 9001 trat auf:

The log for database ‚…‘ is not available. Check the event log for related error messages. Resolve any errors and restart the database.

Select – Abfragen waren davon aber nicht betroffen, da diese ja keine Log-Einträge erzeugen.

Die Lösung wurde in SQL ServerCentral.com beschrieben: Abschalten der Option AutoClose in den Eigenschaften der Datenbank! Da diese Eigenschaft weder bewußt gesetzt worden war, noch benötigt wurde, konnte das Problem so einfach gelöst werden.

Vor kurzem wurde ich von einer Anfrage eines Kunden überrascht. Eingaben auf meiner MVC Seite nach einer längeren Wartepause, die durchaus im Bereich von Stunden liegen kann, führten wieder zum Login. Da wir keine Daten in Sessions gespeichert haben, konnte ich mir das Verhalten erst nicht erklären. Ich bin immer davon ausgegangen, dass ein POST alle notwendigen Daten überträgt. Bei den Login-Informationen passte hier wohl etwas nicht wie erwartet. Also habe ich das ganze analysiert:

Bei einer MVC 3 oder 4 Webseite mit Formular-Authentifizierung wird folgender Code zum Setzen der Authentifizierungsinformationen aufgerufen:

FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe);

Wählt der Anwender nun die Option Speichern nicht aus, so wird beim Authentifizierungscookie automatisch die Verfallsinformation auf Session gesetzt. Da Sessions in der Standardeinstellung nach 20 Minuten Inaktivität verfallen, erklärt es auch, warum nach längerer Pause die Anmeldung ungültig wurde:

FormsAuthentication.SetAuthCookie(model.UserName, false);

Besser sieht es jedoch auch, wenn die Anmeldeinformationen gespeichert werden dürfen:

FormsAuthentication.SetAuthCookie(model.UserName, true);

Dann wird das Authentifizierungscookie automatisch mit dem Verfallsdatum des Timeouts der Web.config gesetzt, hier 2880 Minuten => 2 Tage.

  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>
  </system.web>

Mir persönlich fehlt jetzt noch die Option, dass Authentifizierungscookie bis zum Ende der Browsersitzung behalten zu können, aber man kann scheinbar nicht alles haben.

Gestern stand ich vor dem Problem, dass nach einem Festplattenfehler an einem Windows Server 2012 mit dem Tausch einer Festplatte, Windows keinen Spiegel mehr aufbauen konnte. Es kam zu einer klaren Fehlermeldung:

Error – All disks holding extents for a given volume must have the same sector size, and the sector size must be valid.

zu der es auch viele interessante Frage und Antwort Threads gab. Leider brachte mich anfangs kein Tipp wirklich weiter, also hieß es: Ursache suchen und verstehen.

Dabei hat mir das Tool smartctl geholfen. Damit kann man die technischen Daten der Festplatten anzeigen lassen.

Hier die alte Festplatte:

C:\Program Files (x86)\smartmontools\bin>smartctl -x sda
smartctl 6.2 2013-07-26 r3841 [i686-w64-mingw32-2012(64)] (sf-6.2-1)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda LP
Device Model: ST31000520AS
Serial Number: 5VX0WWJD
LU WWN Device Id: 5 000c50 02511506c
Firmware Version: CC32
User Capacity: 1.000.204.886.016 bytes [1,00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 5900 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4
SATA Version is: SATA 2.6, 3.0 Gb/s

und hier die neue Ersatzfestplatte:

C:\Program Files (x86)\smartmontools\bin>smartctl -x sdb
smartctl 6.2 2013-07-26 r3841 [i686-w64-mingw32-2012(64)] (sf-6.2-1)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Seagate Barracuda 7200.14 (AF)
Device Model: ST1000DM003-1CH162
Serial Number: Z1D4RCQ0
LU WWN Device Id: 5 000c50 063a48af4
Firmware Version: CC47
User Capacity: 1.000.204.886.016 bytes [1,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)

Hier wurde sofort klar, dass die Fehlermeldung das Problem sehr genau beschrieb, die physikalischen Sektorgrößen waren unterschiedlich, genauer gesagt kann ich keine Partition, die auf einer 512’er Sektor-Größe liegt, auf eine 4096’er Sektor-Größe spiegeln, weil das Raster passen kann, aber nicht muss. Ein Anruf beim Support mit der Bitte um Ersatz gegen eine neue Austaschplatte mit 512er Sektoren war dann einfach und löste das Problem.

Und hier noch eine Übersicht über die gefundenen Ratschläge, die auf zu finden waren:

Man kann nur identische Festplatten spiegeln, also beide Platten tauschen

Absoluter Quatsch ohne jede Basis. Identische Platten reduzieren nur die Stolperfallen, machen aber eine Clonen oder Neuaufsetzen vom System erforderlich! Man muss nur darauf achten, dass die Kapazität bis auf das Byte genau ausreichend ist, da die normalen Dialoge meist nur MB anzeigen.

Alles Partitionen löschen und gleich neu als Mirror anlegen

Das funktioniert natürlich, aber löst das Problem sehr aufwendig. In dem Falle geht es dann nur, weil das RAID über den kleinsten Nenner geht (Basis auf 4096’er Sektor) und der 512’er Sektor alle Bedingungen erfüllt. Ein Vermeiden der Mischung 4096er/512er Sektoren ist natürlich sinnvoller.

Manchmal ist man in der Situation, dass man keinen Zugriff mehr auf einen SQL Server mehr hat, obwohl man selbst Administrator der darunter liegenden Windows-Version ist. In diesem Fall hat Microsoft dafür gesorgt, dass man recht einfach die Administrationsrechte für den SQL Server erlangen kann. Der meiner Meinung nach einfachste Weg geht so:

Man startet den SQL-Server-Konfigurationsmanager und öffnet die Eigenschaften des gewünschten SQL-Dienstes. Bei aktuellen Version hat man nun die Möglichkeit, direkt den Parameter -m hinzuzufügen. Dieser Parameter startet den SQL-Server Einzelbenutzermodus und gibt allen lokalen Administratoren Zugriff. Alternativ muss man bei älteren Versionen auf der Seite erweitert den Parameter direkt in der Auflistung angeben. Aber Achtung, dort werden die Parameter mit ; getrennt. Es muss dann also lauten:

-m;--dC:\Program Files\Microsoft S...

Anschließend muss der Dienst neu gestartet werden. Nun kann man sich mit dem SQL Server Managementstudio direkt verbinden. Aber auch hier Achtung: Das Programm muss dazu unbedingt als Administrator gestartet werden, selbst wenn unter Windows als Admin angemeldet ist! Nun kann man seinen Admin-Login hinzufügen und mit den notwendigen Rechten versehen. Zum Abschluss nicht vergessen, den Parameter -m wieder zu entfernen, damit der Server normal zur Verfügung steht.

Ich benötigte für eine Überprüfung von Dateien auf einem Server das exakte Datum der Erstellung. Ein Blick in die Optionen von DIR oder die Eigenschaften der Datei zeigte aber immer nur Informationen auf die Minute genau an, ich brauchte aber zur sinnvollen vergleichenden Bewertung der Performance die Sekunden-Bruchteile.

Nach etwas erfolgloser Suche habe ich mir das in der Powershell selbst zusammengebastelt:

Get-ChildItem | Sort-Object CreationTime |
 Format-Table Name,@{Expression={$_.CreationTime};FormatString="mm/ss/ff"}

Damit bekommt man wie bei Dir auch alle Dateien in einem Verzeichnis angezeigt, dass ganze wird nach dem Erstelldatum sortiert und mit dem Erstelldatum in Minuten/Sekunden/Sekundenbruchteilen ausgegeben. Bei der Formatierung der Uhrzeit hat man so natürlich viele Möglichkeiten.

Nachdem ich in den letzten beiden Teilen bereits von den Problemen bei der Migration von Mozilla Thunderbird nach Office365 berichtet haben, konnte ich nun einen Durchbruch erzielen. Dazu habe ich einen alten virtuellen PC genutzt, in dem noch Office 2003 installiert war (Office 2013 funktioniert im Moment im ersten Schritt noch nicht!). Dort habe ich MailStore Home installiert. Diese Software ist eigentlich dazu da, Emailprogramme zu sichern und bei Bedarf auch wiederherzustellen. Ich habe als ein MailStore-Backup von Thunderbird (diese Software lässt sich problemlos auf einem USB-Stick betreiben) in den alten Rechner mit Outlook 2003 übertragen. Danach war nur noch die pst-Datei in mein reales Outlook 2013 zu übertragen und Outlook mit Office365 zu verbinden. Office365 läuft für Outlook wie ein Exchange und auch die Übertragung großer Ordnerstrukturen ist so kein Problem.

Wie ich im letzten Beitrag bereits geschrieben habe, versuche ich gerade meine Emails in die Office365 Cloud umzuziehen. Leider ist die Thunderbird-IMAP-Schnittstelle zur Office365-IMAP-Schnittstelle nur bedingt kompatibel. Konkret äußert sich das so:

Problem 1: Kopiert man einen Ordner, der Unterordner enthält, in Richtung Office365, so wird erst der Hauptordner ordentlich angelegt, dann werden dessen Emails übertragen. Der erste Unterordner wird ebenfalls angelegt. Danach erfolgt leider ein Abbruch mit der Servermeldung, dass der Ordner in Office365 nicht vorhanden sei. Im Nachgang lassen sich die Dateien aber problemlos in den Ordner kopieren. Im Endeffekt bedeutet das aber, dass ich alle Ordner einzeln transferieren muss.

Problem 2: Enthält ein Ordner Zeichen wie beispielsweise einen Slash: „12/2012“, so hat man ein echtes Problem: In Office365 wird nur der Ordner 12 angelegt und unterhalb der Ordner 2012 angezeigt. Scheinbar wird der Slash als Trennzeichen gewertet. Auf dem Server landet also erst einmal nur die 12. Löschen lässt sich der Ordner nicht mehr, es kommt ein Fehler. Die einzige Hilfe ist hier, den übergeordneten (!) Ordner zu löschen, was aber auch nur geht, wenn der Papierkorb nicht bereits vom ersten Versuch einen gleichnamigen Ordner enthält.

Zwischenstand: Ich werde den Transfer direkt mit Mozilla Thunderbird erst einmal abbrechen. Wenn ich jeden Ordner einzeln übertragen muss, werde ich noch Wochen beschäftigt sein, da man mit einer weiteren Aktion immer erst den Abschluss der vorangegangenen Aktion abwarten muss. Wenn ich an die vielfältigen Email-Konfigurationen von Kunden denke, würde ich momentan sicher erst einmal vor einem Wechsel in Office365 warnen, wenn man keinen erprobten Migrationspfad hat. Vielleicht ist ja aber auch Outlook wirklich das Mittel der Wahl. Ich werde meinen Test darum darauf verlagern.