Ontrex Software Package Atelier Teamblog » Operating System

.NET Installation Repaketieren

Stefan Hotan — Tue, 27 Apr 2010 08:20:41 +0000

Seit vielen Jahren gibt es Programme, welche auf das Microsoft .NET Framework aufbauen. Deren Anzahl wächst täglich und sind dabei die klassischen 32Bit Com Objekt orientieren Applikationen zu verdrängen. Dementsprechend kommt es häufiger vor, dass eine .NET Framework Applikation repaketiert wird.

Je nach Applikation kann das interpretieren der Ressourcen sehr komplex ausfallen. Speziell dann, wenn Assemblies ins Global Assembly Cache installiert, Interop Registrationen durchgeführt, Native Images erstellt, VC++ Runtimes bereitgestellt und vielleicht noch an den .NET Securities gedreht wird.

Wer .NET Applikationen repaketiert muss die Welt deren Ressourcen verstehen lernen. Eine einfache .NET Applikation aus Sicht der .NET Ressourcen ist einfach zu repaketieren, kommen jedoch weitere .NET Ressourcengebiete dazu, dann ist ohne Grundwissen ein Überblick schwer zu erhalten.

Die .NET Ressourcen können im Grossen und Ganzen in fünf Segmente unterteilt werden:

Nicht jede .NET Applikation benötigt zwangsweise eine komplexe Integration. Im besten Falle besteht die Applikation aus privaten Assemblies und benötigt keine der dargestellten .NET Ressourcen.

Die Herausforderung in der Repaketierung besteht darin, die Ressourcen anhand des Deltas dem richtigen Ressourcen-Typ zuzuordnen und die optimale Installationsmethode zu verwenden. Wir haben uns diesem Problem angenommen und diesen Teil in den ‘Wise – MSI Blackbelt III’ Kurs eingebunden. Diesen Eintageskurs führen wir 1-2 mal pro Jahr durch. Neben dem Thema .NET werden weitere interessante Themen für Fachkräfte im Bereich der Software Paketierung besprochen.

Zusätzliche Special Folders

Fabio Di Lorenzo — Thu, 11 Mar 2010 11:38:34 +0000

Die Windows Installer Technologie bietet bereits von Haus aus diverse Directory Properties um auf “Special Folders” Werte zugreifen zu können.

Leider gibt es jedoch immer wieder der Fall, dass man auf zusätzliche, nicht durch den Windows Installer bereits zu Verfügung gestellte Werte zugreifen muss.

Mit folgendem VBScript kann man sich diese Werte allerdings schaffen. In unserem folgenden Beispiel ermitteln wir den “Common Documents” Folder.

Folgendes Skript fügen wir als “CALL VBScript From Embedded Code” Aktion im Immediate Bereich ein:

Const CSIDL_COMMON_DOCUMENTS = &h2e
Set objShell = CreateObject(“Shell.Application”)
Session.Property(“ONTX_COMMON_DOCUMENTS”) = objShell.Namespace(CSIDL_COMMON_DOCUMENTS).Self.Path
Set objShell = nothing

Zu beachten ist, das wir diese Aktion vor “CostFinalize” durchführen müssen.

Um den Wert auch für Komponenten verwenden zu können, sollte man noch einen Eintrag in der Directory Tabelle erfassen:

Danach kann man das Property/Directory wie üblich verwenden.

Eine Liste aller Special Folders befindet sich im Anhang dieses Artikels.

Anhang: Liste aller Special Folders

CSLID	Hex Value	Description
CSIDL_ADMINTOOLS	0×0030	The file system directory that is used to store administrative tools for an individual user. The Microsoft Management Console (MMC) will save customized consoles to this directory, and it will roam with the user.
CSIDL_ALTSTARTUP	0x001d	The file system directory that corresponds to the user’s nonlocalized Startup program group. This value is recognized in Windows Vista for backward compatibility, but the folder itself no longer exists.
CSIDL_APPDATA	0x001a	The file system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data. This CSIDL is supported by the redistributable Shfolder.dll for systems that do not have the Microsoft Internet Explorer 4.0 integrated Shell installed.
CSIDL_BITBUCKET	0x000a	The virtual folder that contains the objects in the user’s Recycle Bin.
CSIDL_CDBURN_AREA	0x003b	The file system directory that acts as a staging area for files waiting to be written to a CD. A typical path is C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\CD Burning.
CSIDL_COMMON_ADMINTOOLS	0x002f	The file system directory that contains administrative tools for all users of the computer.
CSIDL_COMMON_ALTSTARTUP	0x001e	The file system directory that corresponds to the nonlocalized Startup program group for all users. Valid only for Microsoft Windows NT systems. This value is recognized in Windows Vista for backward compatibility, but the folder itself no longer exists.
CSIDL_COMMON_APPDATA	0×0023	The file system directory that contains application data for all users. A typical path is C:\Documents and Settings\All Users\Application Data. This folder is used for application data that is not user specific. For example, an application can store a spell-check dictionary, a database of clip art, or a log file in the CSIDL_COMMON_APPDATA folder. This information will not roam and is available to anyone using the computer.
CSIDL_COMMON_DESKTOPDIRECTORY	0×0019	The file system directory that contains files and folders that appear on the desktop for all users. A typical path is C:\Documents and Settings\All Users\Desktop. Valid only for Windows NT systems.
CSIDL_COMMON_DOCUMENTS	0x002e	The file system directory that contains documents that are common to all users. A typical paths is C:\Documents and Settings\All Users\Documents. Valid for Windows NT systems and Windows 95 and Windows 98 systems with Shfolder.dll installed.
CSIDL_COMMON_FAVORITES	0x001f	The file system directory that serves as a common repository for favorite items common to all users. Valid only for Windows NT systems.
CSIDL_COMMON_MUSIC	0×0035	The file system directory that serves as a repository for music files common to all users. A typical path is C:\Documents and Settings\All Users\Documents\My Music.
CSIDL_COMMON_OEM_LINKS	0x003a	This value is recognized in Windows Vista for backward compatibility, but the folder itself is no longer used.
CSIDL_COMMON_PICTURES	0×0036	The file system directory that serves as a repository for image files common to all users. A typical path is C:\Documents and Settings\All Users\Documents\My Pictures.
CSIDL_COMMON_PROGRAMS	0×0017	The file system directory that contains the directories for the common program groups that appear on the Start menu for all users. A typical path is C:\Documents and Settings\All Users\Start Menu\Programs. Valid only for Windows NT systems.
CSIDL_COMMON_STARTMENU	0×0016	The file system directory that contains the programs and folders that appear on the Start menu for all users. A typical path is C:\Documents and Settings\All Users\Start Menu. Valid only for Windows NT systems.
CSIDL_COMMON_STARTUP	0×0018	The file system directory that contains the programs that appear in the Startup folder for all users. A typical path is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. Valid only for Windows NT systems.
CSIDL_COMMON_TEMPLATES	0x002d	The file system directory that contains the templates that are available to all users. A typical path is C:\Documents and Settings\All Users\Templates. Valid only for Windows NT systems.
CSIDL_COMMON_VIDEO	0×0037	The file system directory that serves as a repository for video files common to all users. A typical path is C:\Documents and Settings\All Users\Documents\My Videos.
CSIDL_COMPUTERSNEARME	0x003d	The folder that represents other computers in your workgroup.
CSIDL_CONNECTIONS	0×0031	The virtual folder that represents Network Connections, that contains network and dial-up connections.
CSIDL_CONTROLS	0×0003	The virtual folder that contains icons for the Control Panel applications.
CSIDL_COOKIES	0×0021	The file system directory that serves as a common repository for Internet cookies. A typical path is C:\Documents and Settings\username\Cookies.
CSIDL_DESKTOP	0×0000	The virtual folder that represents the Windows desktop, the root of the namespace.
CSIDL_DESKTOPDIRECTORY	0×0010	The file system directory used to physically store file objects on the desktop (not to be confused with the desktop folder itself). A typical path is C:\Documents and Settings\username\Desktop.
CSIDL_DRIVES	0×0011	The virtual folder that represents My Computer, containing everything on the local computer: storage devices, printers, and Control Panel. The folder can also contain mapped network drives.
CSIDL_FAVORITES	0×0006	The file system directory that serves as a common repository for the user’s favorite items. A typical path is C:\Documents and Settings\username\Favorites.
CSIDL_FONTS	0×0014	A virtual folder that contains fonts. A typical path is C:\Windows\Fonts.
CSIDL_HISTORY	0×0022	The file system directory that serves as a common repository for Internet history items.
CSIDL_INTERNET	0×0001	A virtual folder for Internet Explorer.
CSIDL_INTERNET_CACHE	0×0020	The file system directory that serves as a common repository for temporary Internet files. A typical path is C:\Documents and Settings\username\Local Settings\Temporary Internet Files.
CSIDL_LOCAL_APPDATA	0x001c	The file system directory that serves as a data repository for local (nonroaming) applications. A typical path is C:\Documents and Settings\username\Local Settings\Application Data.
CSIDL_MYDOCUMENTS	Use CSIDL_PERSONAL	The virtual folder that represents the My Documents desktop item. This value is equivalent to CSIDL_PERSONAL.
CSIDL_MYMUSIC	0x000d	The file system directory that serves as a common repository for music files. A typical path is C:\Documents and Settings\User\My Documents\My Music.
CSIDL_MYPICTURES	0×0027	The file system directory that serves as a common repository for image files. A typical path is C:\Documents and Settings\username\My Documents\My Pictures.
CSIDL_MYVIDEO	0x000e	The file system directory that serves as a common repository for video files. A typical path is C:\Documents and Settings\username\My Documents\My Videos.
CSIDL_NETHOOD	0×0013	A file system directory that contains the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Documents and Settings\username\NetHood.
CSIDL_NETWORK	0×0012	A virtual folder that represents Network Neighborhood, the root of the network namespace hierarchy.
CSIDL_PERSONAL	0×0005	The virtual folder that represents the My Documents desktop item. This is equivalent to CSIDL_MYDOCUMENTS.
CSIDL_PRINTERS	0×0004	The virtual folder that contains installed printers.
CSIDL_PRINTHOOD	0x001b	The file system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is C:\Documents and Settings\username\PrintHood.
CSIDL_PROFILE	0×0028	The user’s profile folder. A typical path is C:\Users\username. Applications should not create files or folders at this level; they should put their data under the locations referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. However, if you are creating a new Known Folder the profile root refered to by CSIDL_PROFILE is appropriate.
CSIDL_PROGRAM_FILES	0×0026	The Program Files folder. A typical path is C:\Program Files.
CSIDL_PROGRAM_FILES_COMMON	0x002b	A folder for components that are shared across applications. A typical path is C:\Program Files\Common. Valid only for Windows NT, Windows 2000, and Windows XP systems. Not valid for Windows Millennium Edition (Windows Me).
CSIDL_PROGRAM_FILES_COMMONX86	0x002c
CSIDL_PROGRAM_FILESX86	0x002a
CSIDL_PROGRAMS	0×0002	The file system directory that contains the user’s program groups (which are themselves file system directories). A typical path is C:\Documents and Settings\username\Start Menu\Programs.
CSIDL_RECENT	0×0008	The file system directory that contains shortcuts to the user’s most recently used documents. A typical path is C:\Documents and Settings\username\My Recent Documents. To create a shortcut in this folder, use SHAddToRecentDocs. In addition to creating the shortcut, this function updates the Shell’s list of recent documents and adds the shortcut to the My Recent Documents submenu of the Start menu.
CSIDL_RESOURCES	0×0038	Windows Vista. The file system directory that contains resource data. A typical path is C:\Windows\Resources.
CSIDL_RESOURCES_LOCALIZED	0×0039
CSIDL_SENDTO	0×0009	The file system directory that contains Send To menu items. A typical path is C:\Documents and Settings\username\SendTo.
CSIDL_STARTMENU	0x000b	The file system directory that contains Start menu items. A typical path is C:\Documents and Settings\username\Start Menu.
CSIDL_STARTUP	0×0007	The file system directory that corresponds to the user’s Startup program group. The system starts these programs whenever any user logs onto Windows NT or starts Windows 95. A typical path is C:\Documents and Settings\username\Start Menu\Programs\Startup.
CSIDL_SYSTEM	0×0025	The Windows System folder. A typical path is C:\Windows\System32.
CSIDL_SYSTEMX86	0×0029
CSIDL_TEMPLATES	0×0015	The file system directory that serves as a common repository for document templates. A typical path is C:\Documents and Settings\username\Templates.
CSIDL_WINDOWS	0×0024	The Windows directory or SYSROOT. This corresponds to the %windir% or %SYSTEMROOT% environment variables. A typical path is C:\Windows.

Side-by-side configuration is incorrect

Stefan Hotan — Thu, 30 Jul 2009 13:05:02 +0000

In letzter Zeit ist die Meldung ‘The application has failed to start because its side-by-side configuration is incorrect’ anzutreffen. Dies bei Windows Vista ohne SP2.

Wer versucht das Problem über die Ereignisanzeige zu lösen, wird sich in den Tiefen von .Net wohl verirren.

Ich möchte hier nicht wirklich tiefgründig werden, da dieses Problem mit SP2 oder Windows 7 behoben wurde, braucht man lediglich unter Windows Vista SP1 die folgenden zwei Hotfixes zu installieren:
Windows6.0-KB958481-x86
Windows6.0-KB958483-x86

Nach der Einspielung dieser Hotfixes wird die Applikation funktionieren.

Stefan Hotan
A member of the Ontrex SPA

RegSvr32 failed – Invalid access to memory location

Stefan Hotan — Mon, 20 Jul 2009 12:41:59 +0000

Und auf einmal war sie da – Die Meldung ‘LoadLibrary .dll failed’ die nie zuvor gesehen war.

Das Analysieren mit dem Dependency Walker jedoch zeigt keinerlei Probleme mit dieser Datei, denn es handelt sich um eine Sicherheitserweiterung des Betriebssystemes. Die Data Execution Prevention (DEP) ist für diesen Umstand verantwortlich. DEP wurde gegen Viren und andere sicherheitsrelevanten Funktionen entwickelt. Unter anderem wird DEP die Registration von 16-bit COM Objekten verhindern.

In der Repaketierung kann dieses Problem behoben werden, indem die Self-Registration über die Registry-Tabelle durchgeführt wird.
Um die DLL oder OCX Datei wieder registrieren zu können, muss DEP konfiguriert werden. Die Konfiguration zu DEP findet man unter ‘System Properties’ – ‘Performance’.
Unter ‘Data Execution Prevention’ ist die Option ‘Turn on DEP for all programs and services except those I select:’ anzuwählen und die RegSvr32.exe im System32 Ordner zu wählen.

Mit dieser Einstellung kann nun die Self-Register Information ausgelesen werden und die entsprechende Registration über die Windows Installer Tabellen erfolgen. Auf diese Weise muss bei den Endanwendern keine DEP Konfiguration durchgeführt werden.

Stefan Hotan
A member of the Ontrex SPA

Verzögerter Start eines Dienstes dank MsiServiceConfig Tabelle

Stefan Hotan — Thu, 25 Jun 2009 13:04:41 +0000

Ab Microsoft Windows Installer 5.0 kann die MsiServiceConfig Tabelle verwendet werden, um einen Dienst verzögert zu starten.
Der Service Control Manager (SCM) wurde mit dieser Option in Windows Vista erweitert.
Mit der MsiServiceConfig Tabelle können diese neuen Funktionalitäten des SCM für einen Dienst konfiguriert werden.

Einen Dienst verzögert zu starten soll helfen die Zeitspanne eines Systemstartes zu optimieren. Wenn ein Dienst nicht unmittelbar zum Zeitpunkt des System Start benötigt wird, so kann dieser zu einem späteren Zeitpunkt gestartet werden. Ein Dienst der verzögert gestartet wird, wird innerhalb von 2 Minuten nach dem System Start gestartet. Ein Setup Autor kann nun bei einem Dienst entscheiden, ob dieser sofort zur Verfügung stehen muss, oder ob es sich um einen Dienst einer Anwendung handelt, welcher auch zu einem späteren Zeitpunkt gestartet werden kann.

Der Dienst selber wird wie gewohnt über die ServiceInstall Tabelle installiert und über die ServiceControl Tabelle gestartet, ggf. gestoppt oder gelöscht.

Sollte die MsiServiceConfig Tabelle nicht im Schema der Installation sein, so kann die Tabelle mit Orca 5.0 oder einem Setup Authoring Tool (welches die Windows Installer 5.0 Technologie unterstützt) erstellt werden.

Die Felder sind für einen verzögerten Start wie folgt auszufüllen:

ServiceConfigure: ist ein Identifier
Name: Name des Dienstes der in der ServiceInstall Tabelle steht, oder der Name eines bereits installierten Dienstes.
Event: 1
ConfigType: 3
Argument: 1
Component_: Name einer Komponente aus der Installation

Der nächste und auch der letzte Punkt ist dem Windows Installer mit der MsiConfigureServices Aktion mitzuteilen, dass ein Service mit den neuen Optionen zu konfigurieren ist.

Die MsiConfigureServices Aktion wird zwischen der InstallServices und der StartServices gestellt.

Weitere Informationen zu den neuen SCM Funktionen:
http://msdn.microsoft.com/en-us/library/bb203962(VS.85).aspx

Stefan Hotan
Member of the Ontrex SPA Team

Einfacher Weg zum LocalLow Verzeichnis

Stefan Hotan — Thu, 07 May 2009 09:08:40 +0000

Mit der Einführung der Integrity Access Level (IL) Funktionalität unter Windows Vista und Windows 7, wurde ein neues Verzeichnis, das LocalLow Verzeichnis eingeführt.

Das LocalLow Verzeichnis wir für Prozesse verwendet, die als Low-Level Prozess ausgeübt werden. In der Regel betrifft dies Prozesse, welche unter dem Internet Explorer Prozess gestartet werden, wie das Apple Quicktime Plugin oder Sun Java Runtime Environment. Diese Prozesse können nur noch Dateien in diesem Ordner schreiben oder modifzieren.

Wird eine Applikation repaketiert, welche in diesem Ordner eine Datei erstellt, dann wird schnell klar, dass der Windows Installer Dienst dieses neue Verzeichnis nicht auflöst. Eigentlich gehört das LocalLow Verzeichnis wie die restlichen ‘Special-Folders’ aufgelöst. Das neue Verzeichnis jedoch ist weder in MSI 4.0, 4.5 noch 5.0 Bestandteil der Directory Tabelle.

Es gibt hierzu eine einfache Lösung, wenn Wise Package Studio 7 SP3 oder höher eingesetzt wird. Ab dieser Version von Wise Package Studio wird mit der CustiomAction WiseSetProfilesFolder das Root-Verzeichnis des aktuellen Benutzers aufgelöst (ebenfalls eine Schwachstelle des Windows Installer Dienstes). Aufbauend auf diesem Verzeichnis (ProfileFolder) kann nun mit zwei Einträgen in die Directory Tabelle das LocalLow Verzeichnis dynamisch aufgelöst werden.

Stefan Hotan
Member of the Ontrex SPA Team

Type 1 Fonts Registration mit Windows Installer

Stefan Hotan — Fri, 27 Feb 2009 15:41:07 +0000

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[~].PFM[~].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’:

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

Applikation startet nicht nach .NET Installation

Stefan Hotan — Tue, 17 Feb 2009 17:03:58 +0000

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:

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