Video Screencast Help
Endpoint Management Community Blog
Showing posts tagged with Wise Packaging
Showing posts in English
ropree | 04 Oct 2007 | 2 comments

Here are the steps I followed to create an .EXE which contains MSI and MST. Hopefully this will help other application packagers faced with the same challenge.

  1. Launch WPS
  2. In Tools, double click on Windows Installer Editor.
  3. Double click on Run Wise Script from Installation at "Untitled -- Windows Installer Editor."
    1. Create a new WSE.
    2. Save it in the same location as the package files or on the desktop.
    3. Close Windows Installer Editor screen.
  4. Launch the .wse file just created.
  5. On the left pane, double click on Install File(s).
    1. Select the source where the MSI is located (use the location from where Authenticated Users can get to such as the WISE sharepoint).
    2. Destination should be the temp directory on the user's PC.
    3. Select the other options as they apply for e.g. check of '...
R-Vijay | 04 Oct 2007 | 0 comments

Concurrent Installations, also called Nested Installations, install another Windows Installer package during a currently running installation.

The use of concurrent installations is not a good practice because they are difficult for customers to service. Patching and upgrading may not work with concurrent installations. The recommended alternative to using concurrent installations is to instead use a setup application and external UI handler to install several Windows Installer packages sequentially.

Concurrent installations are sometimes used in controlled corporate environments to install applications that are not intended for the public.

Follow these guidelines if you decide to use concurrent installations.

  • Do not use concurrent installations to install or update a shipping product.
  • Concurrent installations should not share components.
  • An administrative installation should not contain a concurrent installation.
  • ...
WiseUser | 03 Oct 2007 | 3 comments

Source Resiliency: Applications that rely on network resources for installation-on-demand are susceptible to source failures if the source location should change for any reason or become damaged.

The Microsoft® Windows® Installer provides source resiliency for features that are installed on-demand by using a source list.

The source list contains the locations searched by the installer for installation packages. The entries in this list can be

1) Network locations
2) Uniform Resource Locators (URLs),
3) Compact discs.

If one of these sources fails, the installer can quickly and seamlessly try the next.

R-Vijay | 03 Oct 2007 | 0 comments

Here's a nice tip that explains the advantages (and disadvantages) of two capture mechanisms and how to use them both to create the best possible installation packages.


This Setup Capture mechanism monitors and records the installation's operations as they happen. This method is faster than snapshot comparisons, because it doesn't require a time-consuming scan of the computer. SmartMonitor records the following operations:

  1. Copying, moving, deleting, or opening a file.
  2. Replacing files even if they are the same size, modification date, and version.
  3. Creating or removing a directory.
  4. Creating, starting, stopping, or deleting a service.
  5. Setting or deleting a registry value, creating or deleting a registry key.
  6. Overwriting existing registry keys with the same value.
  7. Installing ODBC drivers or configuring ODBC data sources.
  8. Changing .INI files regardless of their location.
  9. ...
R-Vijay | 02 Oct 2007 | 1 comment

Components are collections of resources that are always installed or removed as a unit from a user's system. A resource can be a file, registry key, shortcut, or anything else that may be installed. Every component is assigned a unique component code GUID.

Few Component Rules are listed below:

  1. Two components must not have the same key path file. The key path value points to a particular file or folder belonging to the component that the installer uses to detect the component. If two components had the same key path file, the installer would be unable to distinguish which component is installed.
  2. No file, registry entry, shortcut, or other resources should ever be shipped as a member of more than one component. This applies across products, product versions, and companies.
  3. Never create two components that install...
WiseUser | 02 Oct 2007 | 2 comments

A number of MSIExec processes can be running during an installation. The reason for this is that Windows Installer uses a client-server model for performing installations. Additionally for security reasons, Windows Installer hosts DLL and script custom actions in a "sandbox" process.

Depending on how the install was initiated, one of the MSIExec processes can be the client process. Another MSIExec process is Windows Installer service.

Any remaining MSIExec processes are usually sandbox processes for hosting custom actions. The determination as to which MSIExec process will serve as the sandbox process for a script or DLL custom action depends in part on whether the custom action will run elevated or impersonated and whether the custom action is 32-bit or 64-bit.

R-Vijay | 02 Oct 2007 | 1 comment

You can use the Windows Installer to detect missing components or files and then reinstall features containing the missing components. Because the installer installs features, and not components, it must first resolve to which component a missing file belongs and then install the feature containing that component.

If more than one feature is linked to that component, the installer installs the feature requiring the least disk space. Calling MsiGetComponentPath verifies that the key file of a component is present; however, it is still possible that other files belonging to the component are missing.

In this case, call MsiInstallMissingFile. The installer then resolves to which component the file belongs and installs the feature that is linked to the component that requires the least disk space. If the MsiGetComponentPath function...

WiseUser | 01 Oct 2007 | 0 comments

Here are the command line options that can be used for advertising a product.

/j [u|m]Package - Advertises a product. This option ignores any property values entered on the command line.
[u|m]Package /t Transform List
u - Advertises to the current user.
m - Advertises to all users of machine.
t - Applies transform to advertised package.

Note: Do not use the TRANSFORMS Property to apply a transform as /j will ignore any property value entered in the command line. Use /t instead to apply the transform.
WiseUser | 27 Sep 2007 | 0 comments

Stumped by whether an upgrade actually succeeded or not? You can check the upgrade success status by using the msi log file.

Read on to learn a couple of techniques.

1. UPGRADINGPRODUCTCODE Property in the Log File

The UPGRADINGPRODUCTCODE property is set by Windows Installer when an upgrade removes an application. The installer sets this property when it runs the RemoveExistingProducts action. This property is not set by removing an application using the Add or Remove Programs in Control Panel. An application determines whether it is being removed by an upgrade or the Add or Remove Programs by checking UPGRADINGPRODUCTCODE.

For example:

RemoveExistingProducts: Application: {0AC95D97-1B75-4AC7-B061-F21E379FF809}, Command line: UPGRADINGPRODUCTCODE={DD4CEE59-5192-4CE1-8AFA-1CFA8EB37209} REMOVE=ALL

In this...

R-Vijay | 26 Sep 2007 | 0 comments

Hi All,

This is a microsoft MSDN extract, I have still posted it because many of us do not follow these rules while packaging .NET applications.

Hope it is useful.

The Installer can install, remove and update Win32 and .NET assemblies, including side-by-side and private assemblies in Windows XP. To avoid common problems, follow these rules when using assemblies:


  • A component should contain no more than one assembly.
  • All of the files in an assembly should be in a single component.
  • Each component that contains an assembly should have an entry in the MsiAssembly table.
  • The strong assembly cache name of each assembly should be authored into the MsiAssemblyName table.
  • Use the Registry table instead of the Class table when you register COM Interop for an assembly.
  • Assemblies that have the same strong name are the same assembly. When the same assembly is installed by different applications, the...