Install driver using DIFx (Driver Install Frameworks)

No Comments »

When installing a driver using DIFx, an MSI package is usually the best solution. Since you need to create an MSI installer, you first need to get a good Windows Installer setup tool.

Advanced Installer is one of the best, but you can also try a different tool.

In Advanced Installer configuring a driver is easy:

  • create a new Enterprise or Architect project
  • go to Files and Folders page and add your driver files
  • go to Drivers page and add your driver
  • set driver install options

Some of the options you can set are:

  • Force the installation of a new PnP function driver on a device
  • Do not prompt the user to connect the device to the computer
  • Do not create an Add or Remove Programs entry for the component
  • Install unsigned driver packages and driver packages that have missing files
  • On uninstall remove the binary files that where copied to the system when installed

Please note that if you are installing multiple drivers it’s best to use a separate folder for each of them.

Install third-party packages as features

No Comments »

Usually third-party packages are installed as prerequisites of your main installer. This process usually shows a checkbox list of prerequisites or it simply executes the prerequisite one after another before the main installation starts.

But what if you want the prerequisites to be handled as features? For example, SQL Server can be a sub-feature for one of your product features that uses databases. Most installers do not support this and simply install the prerequisite based on a simple detection criteria, without allowing any control from your main package.

However, Advanced Installer supports feature-based prerequisites. Although they are available only for the licensed versions, feature-based prerequisites are very easy to create. It’s a simple option you select in the prerequisite properties pane.

A feature-based prerequisite doesn’t use an EXE bootstrapper and is handled directly by the MSI through an actual product feature. They are installed during your main installation, with an integrated progress indicator.

This allows more flexibility over how the third-party packages are installed. Target users will understand and control a product feature easier than unexpected installers launched automatically when trying to install your product.

Linking a prerequisite to a feature also allows dynamic installs. Basically, you can install a third-party package based on conditions evaluated by your main package.

Advanced Installer also has another cool feature: you can schedule the feature-based prerequisite to be installed after your main product. This is usually the best approach for application plugins which the user can select during your main install.

So installing third-party packages has a lot of advantages. I haven’t found any disadvantages yet, but let me know if you find one.

Hide your product in Control Panel

No Comments »

There are two approaches for hiding your product in Programs and Features applet in Control Panel:

  1. Set ARPSYSTEMCOMPONENT property to “1″. This way your product is not displayed in Control Panel. It is still however registered with Windows Installer.
  2. Remove PublishFeaturesPublishProductRegisterProduct and RegisterUser actions fromInstallExecuteSequence table. This way your product is not registered with Windows Installer, so it won’t be shown in Control Panel.

If your product is not registered with Windows Installer, you cannot repair or uninstall it. So I recommend using ARPSYSTEMCOMPONENT.

Advanced Installer

In Product Details page simply check Do not show in list option from “Add or Remove Programs” section.

Visual Studio setup project

Unfortunately Visual Studio setup projects do not offer support for this. However, you can set ARPSYSTEMCOMPONENT or remove the registration actions using Orca.

WiX

Simply add a new Property element which sets ARPSYSTEMCOMPONENT to “1″.

32-bit and 64-bit installers

No Comments »

When unsure about handling 64-bit machines, always start with some questions:

1. Does your application really need 64-bit resources and locations?

A lot of developers build their application as 64-bit because they think they should. However, most applications do not require 64-bit resources or locations and can run as 32-bit without a problem.

A 32-bit application works on a 64-bit machine. So build your application as 64-bit only if you need to.

2. Do you want separate 32-bit and 64-bit packages or a mixed package which handles both?

Separate packages for each platform work best when you have different 32-bit and 64-bit source files. In this case each package is handled independently.

But if you have an AnyCPU application, a mixed 32/64-bit installer is better. It adapts to the platform type during install and uses the appropriate configuration. It also tends to be more complex because of its dynamic elements, but it’s usually worth it.

3. Which setup authoring tool do you want to use?

Visual Studio setup projects are very limited when it comes to 32-bit and 64-bit handling. They support only separate packages and only by creating a different project for each platform.

WiX offers a bit more control, but it’s also limited. As a side note, this limitation actually comes from Windows Installer, not from WiX or Visual Studio.

Advanced Installer has great support for 32-bit and 64-bit packages in the Free version. Mixed 32/64-bit package are also supported in the licensed versions.

Although more expensive, InstallShield also supports 32-bit and 64-bit installers.

Preserve old data during install

No Comments »

Preserving data from older versions of your product is not an easy task in Windows Installer. There isn’t much support for it, so the usual solution is using custom actions. You will need two of them:

  1. The first is executed before RemoveExistingProducts action and creates backups for the old data.
  2. The second restores the backups and is executed towards the installation end, for example after RegisterProduct action.

This is pretty much it.

Conditioning resources based on existing files and registry entries is not really an option because of the way major upgrades work. Additionally, during an uninstall Windows Installer removes only what it installed. So for a clean uninstall you need to make sure that all resources in the installation folder are actually installed by your package.

For sample custom actions you can check-out the Advanced Installer user guide. It has some how-to’s which discuss this approach:

You can easily adapt the code for your installer.

Conditional install path

No Comments »

Conditional install paths in MSI-based installations are somewhat easy. Because this path is stored in an installer property, you can always modify that property value dynamically.

After setting your default path, you can create some type 51 custom actions (property set with formatted text). These actions can modify your installation path property and you can condition them.

Since the custom actions modify an installer property associated a directory, they need to be scheduled before CostFinalize action. If you want to modify your installation path after this action, you will need a type 35 custom action (directory set with formatted text).

When you add your custom actions, make sure that they are in both InstallUISequence and InstallExecuteSequence. This way they will update the default path in your folder selection dialog and also work for silent installs. Just make sure you set the msidbCustomActionTypeFirstSequence flag for them.

Visual Studio setup projects do not support this, but other setup authoring tools do.

Wise Package Studio alternative

No Comments »

Symantec recently made an official announcement about discontinuing Wise Package Studio and switching to AdminStudio from Flexera. Whatever their reasons are, you now have to make a tough decision.

Do you switch to AdminStudio or try to find a better or cheaper alternative?

The switch involves a conversion process. Depending on your projects, this conversion may be easy or it may be hell.

I liked that existing licenses are converted for free. But the more expensive AdminStudio maintenance plan is just around the corner. So you may end up paying more.

You should also consider App-V packages and virtualization support. I wrote about this recently, comparing the two major players: Advanced Installer and InstallShield.

So what will you do?

Using properties in a merge module

No Comments »

Inside an MSI package you can access installer properties through their name. For example, MY_PROPERTY. However, inside a merge module this doesn’t really work as expected.

When adding a merge module to your MSI, there is no longer a separation between the MSI and the MSM. They are merged into a single MSI database. To avoid conflicts, all elements from the MSM are appended with the merge module GUID. This includes installer properties.

So any installation elements that need to access a property from the MSM will have to append the module GUID to the property name. For example:

MY_PROPERTY.123D3E73_1118_4B28_BBD4_807CCB854EC6

Accessing MY_PROPERTY without the module GUID will actually use the MSI property, if there is one. This is why your merge module elements should always append the module GUID to the properties they access.

Convert an EXE to MSI

No Comments »

Most system administrators know the pain of trying to deploy an EXE through Active Directory. Group Policy objects support only MSI installers, so some kind of conversion is required.

The most used solution is to repackage that EXE into an MSI. A repackaging process will monitor an EXE installation and generate an MSI which includes the captured data.

There are a lot of repackagers available. The best I used is in Advanced Installer. Besides support data filters and capture profiles, it also interprets the captured data. For example, instead of capturing a service configuration, it actually imports the service data to use native Windows Installer support.

For a repackaging process some tinkering may be required to get a working installer. So make sure you choose a tool which also offers setup authoring features.

Create an App-V package

No Comments »

Creating virtualized App-V packages is not an easy task, especially when you want full control over the process. This is why most companies use a dedicated tool.

If you’re feeling rich, you can go for the InstallShield solution. Its application virtualization package allows you to create App-V packages for any of your products. It’s a bit pricey, but it works.

A better option is Advanced Installer. It offers more features for a lower price. This tool is also oriented towards usability, so you don’t need to know everything about virtualization to create some App-V packages.

Microsoft Community Contributor Award