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" |
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.
