Video Screencast Help
Endpoint Management Community Blog
Showing posts tagged with Wise Packaging
Showing posts in English
R-Vijay | 12 Sep 2007 | 5 comments

Here are some rules I picked up through my time spent packaging software.

I live by them. Your mileage may vary.

  • Don't exclude any file from Setup capture Inclusion List.
  • Keep the default directory immediate to the Program Files.
  • In Merge module dialogue, uncheck all the merge modules and proceed.
    Adding Merge module should be done to a particular feature, but modifying or deleting have to done keeping all features into constraint.
    WFP Files will never be replaced.
  • When assigning key Path, avoid keeping it as ODBC, Its preferable to have it as a File Key path.
  • When a key path is missing for a component, it turns to be a broken component.
  • It's preferable to use installation expert to delete the file.
  • Always create a "shared" folder in local directory, to...
WiseUser | 12 Sep 2007 | 4 comments

Windows® File Protection (WFP) prevents the replacement of essential system files installed as part of Windows. Applications should not overwrite these files because they are used by the system and other applications. Protecting these files prevents application and operating system failures.

Protected File List

WFP protects files with the following extensions that are installed by Windows: .dll, .exe, .ocx, and .sys. In addition, the TrueType fonts Micross.ttf, Tahoma.ttf, and Tahomabd.ttf are also protected.

At the end of the Windows installation, WFP runs a scan of all protected files to ensure they have not been modified by applications installed through unattended installation. WFP also copies verified versions of these system files to the cache directory. When an application attempts to replace a protected file, WFP...

WiseUser | 11 Sep 2007 | 3 comments

Have you ever had a package that always goes for self heal? If so, here are a few points to check ...

If a key file is found to be missing on launch, Windows Installer will trigger a reinstallation of the parent feature. Having a "clean" package is key.

To find out just what the problem is, look in your Application Event log. Or for more detail, turn on Windows Installer logging and search for the word "error" in the resulting log file (found in %TEMP%).

Some common reasons why this may occur:

Missing Files or Registry Keys

Look closely- some files are deleted by the application itself. If your package contains such a file it will self-heal in order to restore the file each time.

Temporary Files Included In MSI

If any temporary files left on the system are captured in your package, they may cause self repairs to occur in order to restore them.

Correct Path for the components.

Sometimes the component will have a...

WiseUser | 06 Sep 2007 | 0 comments

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.

You can condition custom actions that are sequenced after InstallValidate to handle major upgrades by using the UPGRADINGPRODUCTCODE property:

  1. If you want a custom action to run during an uninstallation of the product, but not during the removal of the product by a major upgrade, use this condition.
    REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE
    
    
  2. If you want a custom action to run only during a major upgrade, use this condition.
    UPGRADINGPRODUCTCODE
    
WiseUser | 06 Sep 2007 | 0 comments

Here's some useful information that explains how Windows Installer handles file replacement logic for versioned and unversioned files.

Hope it helps.

  1. In the case when the source and destination files are both versioned files, these rules are straightforward - if the key path file does not exist in the destination location or if it exists in the destination location and it is of a lower version, Windows Installer will install the component (and all of the files in it, including the key path). If the key path file exists in the destination location and it is of an equal or higher version, Windows Installer will not install the component but instead only reference counts the component. It becomes trickier when only one of the files is versioned or neither of them are.
  2. In the case when only one file is versioned, Windows Installer will install the component (and all of the files in it, including the key path file) if the...
WiseUser | 04 Sep 2007 | 0 comments

On Windows Installer 2.0 and later, you can prevent confidential information, for example passwords, from being entered into the log file and made visible. Read on to learn how.

  1. You can prevent the Installer from writing the property that is associated with an Edit Control into the log by setting the Password Control Attribute.
  2. You can prevent the Installer from writing a property into the log by including the property in the MsiHiddenProperties property.
  3. The Installer does not write information entered on a command line into the log unless the Debug system policy is set. To write command lines to the log, set the Debug system policy to a value of 7. This does not display properties included in the MsiHiddenProperties property or associated with an Edit Control that has the Password Control Attribute.
  4. ...
WiseUser | 31 Aug 2007 | 1 comment

Shortcuts not created (or 1909 error)?

Note that if a non-advertised shortcut doesn't get created at all (no message) or you get a runtime error "1909" it is possible that the "Target" parameter of the Shortcut was invalid (ensure you supplied the full path to it).

WiseUser | 22 Aug 2007 | 0 comments

I've become a big fan of the Test Expert Tool that comes with Wise Package Studio. Here are a few very cool tasks you can perform with the tool.

  1. Verify proper installation, uninstallation and installation with user privileges.
  2. Application verfication tests such as launching the shortcuts and opening help files.
  3. Uninstall tests – We can find the created files, created registry entries, destroyed files, destroyed registry entries, residual files, and residual registry entries after uninstallation of the application.
  4. Machine capture – It Records the pre_ installation state of the PC to facilitate both install and uninstall tests.
    • Setting directories to be watched for uninstall tests.
    • Setting a file, wildcard or directory to be ignored.
    • Setting registry entries ignored during uninstall tests.
  5. Adding a user defined test case – We can define our own test case and check manually whether it passes or...
WiseUser | 21 Aug 2007 | 3 comments

The SelfReg table contains information about modules that need to be self registered. The installer calls the DllRegisterServer function during installation of the module; it calls DllUnregisterServer during uninstallation of the module. The installer does not self register EXE files.

If you're thinking of using the SelfReg table in the Installer Database, here are a few reasons to rethink your strategy.

  1. Rollback of an installation with self-registered modules cannot be safely done using DllUnregisterServer because there is no way of telling if the self-registered keys are used by another feature or application.
  2. The ability to use advertisement is reduced if Class or extension server registration is performed within self-registration routines.
  3. The installer automatically handles HKCR keys in the registry tables...
WiseUser | 16 Aug 2007 | 3 comments

We use deferred custom actions to perform actions and manipulate system files. Here's an example where I learned something new about these actions and Installshield \ VB Script.

One of my applications needs to append a value to the Autoexec.bat file, and we use VBScript to do this work. I wrote a custom action to append a value in the .bat file. Since the file is present in "c:\" I used "WindowsVolume" but it was not recognized in the deferred custom action. This is because deferred custom actions doesn't recognize installer properties like SourceDir or WindowsVolume.

To solve this issue, here are the steps we took. This is not an issue if you use WiseScript. But not all projects use WiseScripts.

  1. Create a custom action which has embedded VB code in it that appends the value to the .bat file. Let the custom action name be "APPBAT" and set the custom action as deferred system context and leave the sequence blank -- to be modified later
  2. Create...