Category Archives: Tools

ALLUSERS Profile Auflösung

April 24, 2009 12:24 ⋅ Leave a Comment ⋅

Das Wise Package Studio bzw. das SetupCapture Tool scheint Files/Ordner welche ins ALLUSERS Profile geschrieben werden nicht richtig aufzulösen (Eine Ausnahme bildet natürlich der CommonAppDataFolder Wert).

Bei einer Installation der repaketierten Applikation werden ohne Änderungen diese ins aktuelle Benutzerprofil des installierenden Users kopiert.

Um diesem Bug entgegen zu wirken baut man am besten folgende CustomAction im Immediate Bereich vor der CostFinalize Aktion ein:

screenie1

Diese „biegt“ den entsprechenden Directory-Table Eintrag auf die Envirenmontvariable %ALLUSERSPROFILE%, welches in den meisten Fällen ein zufriedenstellendes Resultat produziert.

Doch wieso existiert dieser Bug?

WPS scheint es gut zu meinen, und kreiert ein entsprechenden Eintrag in der Directory Table namens „ALL_USERS“, dieser basiert auf den Werten “ProfilesFolder” & “All Users”.
ProfilesFolder wird aber zur Laufzeit auf das Userprofiles des Benutzers aufgelöst, was natürlich nicht das gewünsche Resultat ist.

Fabio Di Lorenzo
Member of the Ontrex SPA Team

Posted in: Best Practices, Wise Package Studio

Type 1 Fonts Registration mit Windows Installer

February 27, 2009 16:41 ⋅ Leave a Comment ⋅

Die Windows Installer (MSI) Datei hält eine Font Tabelle für die Installation von Schriften bereit. Diese ermöglicht den manuellen Registrationsprozess für eine Schrift zu automatisieren. Der manuelle Weg ist bestens bekannt, einfach mit drag-and-drop die Schriften-Dateien ins Fonts Verzeichnis verschieben und gut ist.

Wenn man das gleiche mit einer Postscript Schrift (PFM und PFB Datei) durchführt,  so ist dies bei einer manuellen Registration kein Problem. Will man diesen Vorgang jedoch repaketieren, also über das Snap-Shot Verfahren aufzeichnen, so wird die Schriftart erst nach einem Neustart des Rechners ansprechbar.

Der Grund für dieses Verhalten liegt in der Tatsache, dass die Font Tabelle nur für TrueType Schriften (.TTF Dateien) gedacht ist. Diese Tabelle ist nicht mit Postscript Schriften kompatibel.

Der Snap-Shot der Registration wird pro Schriftart einen Registry-Key erstellen:
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionType 1 InstallerType 1 Fonts
Name der Schrift, T[~]<Datei>.PFM[~]<Datei>.PFB
Dieser Eintrag in der Registry ist soweit in Ordnung, nach der Installation ist die Schrift registriert, jedoch nicht aktiviert. Ein Reboot wäre in diesem Fall nötig.

Was aber, wenn man nach der Installation direkt auf die neue Schriftart ohne Reboot zugreiffen will?
Dies ist technisch möglich, benötigt jedoch einen API-Call auf die Datei atmlib.dll, sprich eine Custom Action muss her.

Eine Möglichkeit diesen API-Call durchzuführen ist die verwendung des Wise Script Editors.
Folgender Print-Screen zeigt die benötigte ‘Call DLL function’:

 

wisescript3

Das erste Argument übergibt den Schriften-Namen, der zweite definiert den Schrift-Typ, der dritte und vierter die Schrift. Die benötigten Informationen kann man beim Snap-Shot aus der Registry entnehmen.
Die kompilierte .EXE Datei ist danach im Deferred Context der Installation durchzuführen. Nach der Installation steht die Postscript Schriftart sofort dem Endanwender zur Verfügung.

Die Dateierweiterung PFM steht für Postscript Font Metrich und die PFB Datei steht für Postscript Font Binary. Beide Dateien müssen ins Fonts Verzeichnis kopiert werden, bevor der API-Call durchgeführt wird. Bei Postscript Schriften können auch noch AFM (Adobe Font Metric) und INF (Type I LaserJet font information) beiliegen, welche nicht benötigt, oder einfach mit ins Fonts Verzeichnis kopiert werden können.

Stefan Hotan
Member of the Ontrex SPA Team

Posted in: Fonts, Wise Package Studio

Obsolete default merge module directory

February 24, 2009 08:51 ⋅ Leave a Comment ⋅
Wer kennt diese Meldungen von Wise Produkten schon nicht? Immer wieder kommt es vor, dass Produkte von Symantec Wise Package Studio oder Wise Installation Studio mit einem Nachrichtenfenster daherkommt, wo man die Nachricht zweimal lesen muss, aber nicht wirklich den Sinn dieser Nachricht versteht.
Ich möchte an dieser Stelle in unserem SPA-Teamblog, alle Nachrichtenfenster, die von Wise Produkten erstellt werden, und deren Bedeutung nicht ohne Hintergrundwissen zu verstehen sind, aufgreiffen und den Grund der Meldung, sowie die Best Practices aufzeigen.
Im ersten Blog über die Wise Nachrichtenfenster, möchte ich auf das ‘This installation contains references to an obsolete default merge module directory. Do you want to automatically change these references to the new default directory?’ eingehen.
obsoltemergemodule1
Die Ursache:
Dieses Fenster erscheint, wenn die Installation Dateien in ein ‘Modules’ Verzeichnis kopiert.
Warum:
Der Wise Windows Installer Editor geht davon aus, das die WSI Projekt Datei mit einer alten Version erstellt wurde, wo die Referenz in das Merge Module Verzeichnis noch ‘Modules’ genannt wurde.
Die Auswirkung:
Sollten Sie diese Frage mit ‘Ja’ beantworten, so werden in der WiseSourcePath Tabelle alle Dateien, die in das Modules Verzeichnis zeigen, in das Merge Module Verzeichnis des Windows Installer Editors umgebogen.
module1
Diese Änderung ist fatal, Sie können danach die Installation nicht mehr kompilieren, da die Quelldateien im Merge Module Verzeichnis gesucht werden.
Best Practices:
Wenn Sie mit einer aktuellen Version des Windows Installer Editors arbeiten, so können Sie die Frage mit ‘Nein‘ beantworten. Sie müssten eine schon sehr alte Wise Projekt Datei öffnen, wo dieses Problem nach einem Update des Windows Intaller Editors bestehen könnte.
Hide Message:
Erstellen Sie folgenden Registry-Key bei der Installation von Wise Package Studio oder Wise Installation Studio, damit diese Meldung nicht erscheint:
HKCUSoftwareWise SolutionsWindows Installer EditorHideMessages
Name: 34650
Type: REG_DWORD
Value: 7
Stefan Hotan
Member of the Ontrex SPA Team
Posted in: Message Boxes

Applikation startet nicht nach .NET Installation

February 17, 2009 18:03 ⋅ Leave a Comment ⋅

Seit im Jahr 2006 das Microsoft .NET Framework 2.0 installierbar ist, können ältere Programme, die mit dem .NET Framework 1.0 oder 1.1 entwickelt wurden, nach der .NET Framework 2.0 installation, auf einmal nicht mehr starten.

Der Grund liegt in der Programmierung selber. Da das .NET Framwork die Side-by-Side Technologie unterstütz, werden Programme in der .NET Version ausgeführt, worin diese entwickelt worden sind. Nach Microsoft Richtlinien, ist der Applikation anzugeben, mit welchem .NET Framework diese ausgeführt werden kann. Leider gibt es fehlbare Applikationen, die diese Information nicht beinhalten (sogenannte Unmanaged Applications) und diese Applikationen bekommen Probleme, sobald eine neuere Version von einem .NET Framework auf den PC installiert wird.

Um dieses Problem zu lösen, empfiehlt es sich, eine aktuelle Version der Applikation zu verwenden. Dieses Problem tritt vorallem bei Applikationen die vor der Veröffentlichung des .NET Framework 2.0 herausgegeben wurden.

Ist keine neuere Version erhältlich, so kann eine .Config Datei erstellt werden, welche dem Betriebsystem angibt, mit welchen .NET Framework die Applikation zu laufen hat.

Beispiel LiveLink 9.5:

Dateiname: alviewer.exe.config
Inhalt der Textdatei:

<configuration>
<startup>
   <supportedRuntime version=”v1.1.4322″ />
   <supportedRuntime version=”v1.0.3705″ />
</startup>
</configuration>

Mit diesem einfachen Trick, lassen sich ältere Unmanaged .NET Applikationen in einer Multi .NET Framework Umgebung betreiben.

Posted in: .NET Framework