Categories
Events Microsoft Windows Installer, Application Compatibility and Deployments

Webinar: Best Practices for Building Installation in Visual Studio 2010

Long-time Visual Studio developers understand that the Visual Studio Installer (VSI) tool is not ideal for most installation projects. It may look OK at first glance, but you soon realize VSI has many deficiencies, including:

  1. Visual Studio 2010 LogoCan’t manage components and features
  2. Can’t customize dialog boxes
  3. Can’t validate MSIs for Microsoft® Logo Guidelines
  4. Limited support for custom actions
  5. Can’t create updates and patches

Watch this Webinar from Flexera software to learn best practices for building reliable Windows Installer (MSI) installations inside the Visual Studio 2010 interface. Long-time Visual Studio developers understand that the Visual Studio Installer (VSI) tool is not ideal for most installation projects.

This Webinar explains how the world’s top software companies build reliable MSI installations inside Visual Studio 2010 using InstallShield. If you use Visual Studio 2010 to develop applications – and especially if you work in a large enterprise-level development environment – this Webinar is for you.

Learn best practices for building reliable Windows Installer (MSI) installations inside the Visual Studio® 2010 interface.

  • Webinar: Best Practices for Building Installations in Visual Studio 2010
  • Presenter: Robert Dickau, Flexera Software
  • Date: Available now for viewing

View this webinar now : Click here

PS: You will need to enter your contact information, looks more for product marketting purpose!

You would also be interested in reading –

Categories
Guest Posts How-to Windows Installer, Application Compatibility and Deployments

Create a Minor Upgrade for an application using InstallShield

Upgrades are little complex compared to the new installer. This guest article from Bhuvana aims at providing the requirement for minor upgrade, the steps to create it and options to install the same. Minor upgrade is a type of Product upgrade that Windows Installer supports. A minor upgrade can be used to add new features and components but cannot reorganize the feature-component tree.

Requirement for Minor upgrade:

Add a new subfeature

If the new subfeature consists of new components only, you can use a minor upgrade. If the new subfeature consists of existing components, you must use a major upgrade.

Add a new component to a new feature

In general, a minor upgrade should not include a new top-level feature. However, new subfeatures of existing features are allowed. If you are adding a new subfeature for a minor upgrade, set two of the subfeature’s properties as follows so that they are installed correctly during a minor upgrade:
o    Remote Installation—Set this property to Favor Parent.
o    Required—Set this property to Yes.
The user interface of a minor upgrade does not usually show the feature tree; however, maintenance mode for the updated installation typically does expose the feature tree. If you want the new subfeature to be excluded from the feature tree so that end users cannot deselect it, set the subfeature’s Display property to Not Visible.

Add a new component to an existing feature

A new component can be added to an existing feature if the version of Windows Installer is 2.0 or later

Add, remove, or modify any of the following: files, registry keys, or shortcuts.

If the file, registry key, or shortcut is in more than one component and the component is shared by two or more features, a major upgrade must be used.

Codes Associated with the Minor Upgrade:

Package CodePart of the Summary Information Stream, the package code identifies a particular database. The package code is not a Windows Installer property. Any two .msi databases with identical package codes must have identical contents. So it is recommended to change the package code for each and a must for Minor Upgrade.

ProductVersion—This is a Windows Installer property that contains the product version. Note that Windows Installer uses only the first three fields of the ProductVersion property for version comparisons. For example, for a product version of 1.2.3.4, the 4 is ignored. (Note that this is true for comparisons of ProductVersion values, and not for file versions.)

Package code and Product Version needs to be changed for Minor Upgrade.

Steps to create Minor Upgrade:

  1. Change the Package code and Product Version to create a minor upgrade
  2. Add feature / component by following the guide lines in Section: Requirement for Minor upgrade
  3. Add Remove or Modify files, registry keys and shortcuts.
  4. Add minor upgrade item in upgrades view (this is optional).
  5. Build and use the installer for upgrade.

Running a Minor Upgrade:

With Setup.exe

If you build a release that includes Setup.exe, your latest installation will be minor upgrade enabled. Setup.exe can detect when a previous version of your application exists on a target machine. When Setup.exe detects a previous version, it will run the rest of your installation in minor upgrade mode.
If you have selected the option “Create installation launcher (setup.exe)” when you built the release and if you get an error as Figure1, while running the installer, then you will have to specify these parameters in the generated Setup.ini file:

[Startup]
CmdLine=REINSTALLMODE=vomus REINSTALL=ALL

Without Setup.exe

If you intend to distribute your installation without wrapping it in Setup.exe, there is a manual process that your end users must follow to start the installation. For this reason, you should consider using Setup.exe; however, you can achieve similar results without it. The Installer properties REINSTALL and REINSTALLMODE must be set from the command line to start an installation in upgrade mode. In all but the most advanced scenarios, the property REINSTALLMODE should be set to vomus and the property REINSTALL should be set to ALL. A typical command line can look like the following: msiexec.exe /i \product.msi REINSTALLMODE=voums REINSTALL=ALL

If the update contains features that you do not want to update, you should set REINSTALL to a comma-separated list of the features that you want to update, as in the following command: msiexec /i \product.msi REINSTALLMODE=voums REINSTALL=F1,F3,F5

The feature names you use in the REINSTALL property are case-sensitive.

If you try to install two msi packages with different package codes, but with the same product code, you will get an error message as shown in the below figure,
fig
To overwrite the existing product with a newer version, you should perform a small or minor update. This requires that you set the following properties on the msiexec command line: msiexec /i Yourapp.msi REINSTALLMODE=vomus REINSTALL=ALL

The important part is the “v” in the reinstall mode settings. It forces the use of the new msi file instead of the cached copy. Therefore it can’t be set inside the package. The rest of the REINSTALLMODE flags make sure that existing files get updated, new files get installed, registry entries are re-written and shortcuts are created. REINSTALL=ALL means that only those features, that were selected by the user during the install of the old version get updated. Unselected features should not be added.

Difference between Small and Minor update:
Small and minor updates are very similar. The only difference is that in a minor update the product version is increased (in any of the first thee fields), while a small update leaves the version number unchanged or increases only the fourth field of the number. You can update your product with a small or minor update package only if the product code is unchanged. To replace an existing application with a package that has a different product code, a major upgrade is required.

Bhuvana specializes in InstallShield & MSI Installers and her primary responsibility at work is “Build & Release” which includes creating Setups and Source Control Management. If you want to get in touch, her LinkedIn Profile is – Here. (PS: Do mention in the Linkedin request that, you read her article on msigeek. We do not want to give her un-necessary Spams )

Do comment on this article, if you have any inputs / suggestions for Minor upgrade!

Categories
How-to Windows Installer, Application Compatibility and Deployments

Merge – Merge Module Contents to an MSI

There is always a need for a merging tool when we want to add the components in a merge module to our Installation Package(MSI). All the major packaging tools offer this functionality. There’s also an utility called MsiMerg.exe that ships as part of the Windows Installer SDK. 

The syntax for using this utility – msimerg.exe {base db} {ref db}

It turns out that the base database is the Installer package that we’re merging to, and the reference database is the merge module that we want to add to the package. 

Eg: msimerg ABC10EN.msi comcat.msm 

This will add the information from the comcat merge module to the ABC10EN Installer package. If there are any errors during the merge, it will create a table named _MergeErrors for our further inspection.

Categories
How-to Windows Installer, Application Compatibility and Deployments

Installing Specific Features in a MSI Package

The ADDLOCAL, ADDSOURCE, and ADVERTISE properties can be used to install only a certain number of known features.

The following command-line script would be used to install the “Word” and “Excel” features of the example.msi package locally on the machine. Feature names are case-sensitive.

msiexec /i example.msi ADDLOCAL=Word,Excel /qb

The following command-line script would advertise the “Excel” feature and install the “Word”feature to run from source.

msiexec /i example.msi ADVERTISE=Excel ADDSOURCE=Word /qb

Categories
How-to Windows Installer, Application Compatibility and Deployments

What is a Restricted Public Property? How can I use that?

There are 3 types of properties in Windows Installer; namely: Public Property, Private Property and Restricted Public Property.

Public property can be changed from command line while installing the package whereas private properties cannot be changed from command line. Restricted public properties can be only changed by a system administrator or by a user who has elevated privileges. To include public properties in Restricted public properties, add them to the SecureCustomProperties property.

Generally we add INSTALLDIR as Restricted public property.

Categories
Best Practices Windows Installer, Application Compatibility and Deployments

Application Packaging Advantages & Installer Benefits

Application packaging bundles applications and operating systems into a single file called a distribution unit (.msi), which makes it easier to deploy and install them on user’s computers. Packaging reduces the total cost of ownership for the customers by enabling them to efficiently install and configure the applications. This results in an application package, which provides the product with new capabilities like advertise features without installing them, installs products on demand, add user customizations etc.

Advantages of Packaging(creating MSI packages)

    1. Customize Applications to suit the user needs.
    2. Simplify the Installation and Un-installation Procedures.
    3. Saves Time in both Installation and Un-installation.
    4. Once packaged, applications can be quickly installed on a range of desktops in multiple locations, saving administrative costs, simplifying the manage of licensing fees and minimizing support and repair expenditures.
    5. Saves Space of the product by doing apt modifications to applications.
    6. Has a great flexibility of obtaining the lost files through a phenomenon called Self Heal, this reduces the down time of application. If a critical file (a .DLL or .EXE file, for example) that is part of the distribution is corrupt or is deleted, the user can be prompted to repair the installation by presenting the original .MSI distribution. Additionally, if the installation media is available (for example, on a network share), the repair simply happens automatically.
    7. Can be advertised. So that on demand installation could take place.
    8. Upgrading of the application can be done with ease.
    9. Clean installation and Un-Installation is achieved by a process called Roll-Back.
    10. Simplifies management of new user set-up along with the revision and distribution of software repairs and new applications to existing users. Application recovery can also be improved.
    11. Helps eliminate uncontrolled software downloads and installation, enables applications to be safely removed and reduces non-business traffic on a corporate network.
    12. Using .MSI format, can automate software distribution process and ensure that the installation doesn’t break other applications that have already been installed.
    13. Application is installed via an OS service.
    14. State management is maintained. In the past, it’s been difficult to know whether an application is installed on a machine. You would have to query for a .DLL with a specific version number or determine whether an .EXE file with a specific name was present. Windows Installer provides an application programming interface (API) that lets programmers and administrators see whether a specific application is installed on a machine.
    15. Scriptable API. This whips together a VBScript to help us with the MSI file manipulations. The API to manipulate MSI files is so powerful that it can create, validate and update packages, trigger installs and uninstalls, examine the MSI repository data on computers, and perform some custom actions.
    16. Served installs. Because MSI files can be housed in a share point and delivered via a server, we can keep our installation files all in one place or move them around — closer to the users if necessary.

Hope this article helps the people who keep their first steps in packaging… 🙂