InstallShield uses a tool to extract COM information (spying on the registry) called IsRegSpy.exe. It is trying to register COM libraries and watching what happens in the registry to capture all the keys and values written during registration.
After adding some our own internal libraries I noticed that the IDE startet to hang when extracting COM information from the components in the setup project. After inspecting what was happening using ProcExplorer from Microsoft (http://www.sysinternals.com) I saw that the IDE spawned IsRegSpy.exe but IsRegSpy.exe never seemed to return.
After digging back and forth for a while, I tried to extract the COM information from within the InstallShield IDE to avoid getting this error each time we built the project. The same thing happened, the IDE launched IsRegSpy.exe and stopped responding.
I tried killing IsRegSpy.exe from within ProcExplorer, and noticed that InstallShield managed to add the correct COM information to the IDE! It also turned off the "Extract COM at build" setting for the component! Doing this for all COM components in the Setup project I managed to get past the problem of hanging the IDE when building.
EDIT: The last paragraph was obviously written in a very optimistic tone.. Some of the information was saved, some was not. My final solution was to export the registry hives before and after registering the dlls and then diffing the output...
Tuesday, February 23, 2010
Wednesday, February 17, 2010
Localization
Seems to be rather easy using InstallShield. There are several different options to choose from. You can add all the languages you want to support to your installation, or you can build seperate installations for each language.
NOTE: The language of the installer itself and the language your application is set up to run in are not the same.
I chose to build sepearate deployment packages for each language our application is using. The reasoning behind this is that each language component weights in at around 10 megs which could be a problem to distribute to remote users when updating or servicing the application.
Using different releases and configurations under the Media/Releases node gives me the opportuntity to build more than one setup.exe from my project. I have also integrated the build of each setup into our build system using some custom code for spawning Install Shield.
To get automatic resolving of which features that should go into which of my language dependant distributions, I have set the languages property for these features to a specific language (not Language Independent). When setting a release configuration 's data languages, ui languages and default language to a given language, only those features with either the same language as the configuration (or language independent) will be included in the setup!
NOTE: The language of the installer itself and the language your application is set up to run in are not the same.
I chose to build sepearate deployment packages for each language our application is using. The reasoning behind this is that each language component weights in at around 10 megs which could be a problem to distribute to remote users when updating or servicing the application.
Using different releases and configurations under the Media/Releases node gives me the opportuntity to build more than one setup.exe from my project. I have also integrated the build of each setup into our build system using some custom code for spawning Install Shield.
To get automatic resolving of which features that should go into which of my language dependant distributions, I have set the languages property for these features to a specific language (not Language Independent). When setting a release configuration 's data languages, ui languages and default language to a given language, only those features with either the same language as the configuration (or language independent) will be included in the setup!
Transforms and Setup.exe
When starting out with the deployment project, I tried to define some areas where I had to do some research to be certain that we had a solution that was scalable and easy to maintain.
One of the first issues I ran into was the need for using transforms to change some property values in the MSI package. The background for this requirement is that our app is a typical client/server-based application where our clients perform a server installation where they customize the installation against their database setup and file locations etc.
The cusomization performed in the server setup must be replicated into the client setup so that end users shouldn't have to select odbc connections or file locations upon installation.
The first issue here is how we can make the Server Setup process modify the client installer so that it depolys the client package with the predefined settings. To make this work, we've decided to use transform files.
A transform file is a simple msi database that contains tables just like another msi file. It is used to override values in the msi file it is transforming.
Creating a transform (.mft) file is simple using InstallShield. Just select new project and choose the Transform project template. InstallShield will ask you to provide the msi-file for which you are creating a transform, so you have to have it built already.
After creating the transform file, add it to your installation project under the support file section. You can now tell setup.exe to run it by providing command lines to the msi file in the setup.exe package. Select your setup release in InstallShield (this post is about transforms, so if you only have an msi project, please stop reading..) and switch to the Setup.exe tab. In the MSI Command Line Arguments property, enter TRANSFORMS=name of your mst file.
When we're ready to start generating our own transformation files that lives outside setup.exe, we can remove the transformation file from our setup project and provide it alongside the setup itself.
One of the first issues I ran into was the need for using transforms to change some property values in the MSI package. The background for this requirement is that our app is a typical client/server-based application where our clients perform a server installation where they customize the installation against their database setup and file locations etc.
The cusomization performed in the server setup must be replicated into the client setup so that end users shouldn't have to select odbc connections or file locations upon installation.
The first issue here is how we can make the Server Setup process modify the client installer so that it depolys the client package with the predefined settings. To make this work, we've decided to use transform files.
A transform file is a simple msi database that contains tables just like another msi file. It is used to override values in the msi file it is transforming.
Creating a transform (.mft) file is simple using InstallShield. Just select new project and choose the Transform project template. InstallShield will ask you to provide the msi-file for which you are creating a transform, so you have to have it built already.
After creating the transform file, add it to your installation project under the support file section. You can now tell setup.exe to run it by providing command lines to the msi file in the setup.exe package. Select your setup release in InstallShield (this post is about transforms, so if you only have an msi project, please stop reading..) and switch to the Setup.exe tab. In the MSI Command Line Arguments property, enter TRANSFORMS=name of your mst file.
When we're ready to start generating our own transformation files that lives outside setup.exe, we can remove the transformation file from our setup project and provide it alongside the setup itself.
Welcome back...
I'm currently working on a new MSI-based installer for our main product, and since I tend to forget how I solve the different parts of building an installation from the last time I built one, I've decided to document some of the more important solutions I find here.
Subscribe to:
Posts (Atom)