Search AppDeploy

Home > Reviews > Package Studio Professional 5.0
  

Package Dependencies Support

In Software Manager, you can define package dependencies. Package dependencies represent the packages that must be installed for a specific package to function and the order in which the dependency packages must be installed.

• When you make a package available, check its dependencies. You might not want to make a package available unless its dependencies are available also.

• Before distributing a package, check its dependencies to see if you first need to distribute any dependency packages.

• Before testing a package, check its dependencies so you can install the dependency packages on the test computer.

• Before installing a package, check its dependencies and install them in the correct order. When a package changes, test the packages that are dependent on the changed package, to make sure they still work.

The fact that Wise bothered to address the issue of package dependencies and ordering shows that they know the needs of administrators. There is a very fine line (that seems to move quite a bit) separating the packaging and deployment processes. Like the other Meta data you can provide in Software Manager, this provides a logical place to document package dependencies. However, I would really like to see this feature taken a step further and support the insertion of custom actions or installation conditions into packages to help actually solve the problem of package dependencies. Also keep in mind that while you can set package dependencies in Package Studio Professional, it does require the Enterprise edition to have this dependency information displayed in a Software Manager pane where it is easily viewed.

Preflight Deployment

The Preflight package installs silently with no prompts- or I should say it “performs its operations” silently with no prompts- for the application does not install. As the name implies, this feature lets you create versions of your package to deploy as a test. The key idea being, that by not actually installing the software- you can test in a live environment.

But wait! If the package doesn't do anything, how does it help me determine a successful deployment?

This is where your thin, moving line between packaging and deployment processes makes all the difference. In an environment where you have a strong deployment and reporting mechanism, Preflight Deployment will be of fairly little value. However, if you do not have a consistent or well-documented baseline you are pushing against, this feature has the potential to become quite valuable.

The Preflight version of your package that is created has no user interface sequence at all, and the remaining actions are primarily custom action calls to a Wise diagnostics DLL. The Preflight package performs the following checks:

• Launch Conditions - Records which launch conditions succeed and which fail.
• .NET Framework - Determines if the .NET Framework is required by this installation, and if so, whether or not the .NET Framework is installed on the target computer.
• Connectivity to URL - Extracts URLs from any Launch Web Page, Download File From Internet, or Post Data to HTTP Server custom actions that are found in the original .MSI. It puts them in a table, which is processed on the target computer.
• Open Document Check - Builds a list of document extensions from any OpenDocument custom actions and saves the list in a table. When the preflight package runs, this test checks the registry for support for each extension.
• File Association Check - Checks that any extensions in the preflight package do not overwrite or reassign those already on the target computer.
• Disk Space Check - Evaluates the disk costing and identifies target computers that don't meet the requirements.
• File Security - For read access, it cycles through the files that are installed and queries the target computer for permissions to access the files. For write access, it cycles through the files that are installed and queries the target computer for permissions to create and update files.
• Registry Security - For read access, it cycles through the registry entries that are installed and queries the target computer for permissions to access them. For write access, it cycles through the registry entries that are installed and queries the target computer for permissions to create and update them.
• File Searching - Cycles through the AppSearch table and evaluates conditions attached to each AppSearch action. It then records if any items items specified in AppSearch exist on the target computer.
• Local File Execution - Evaluates custom actions that launch a file via the command line that is expected to exist on the target computer. 

Even better, the results of the Preflight package are reported to a Preflight Deployment database via an http call to a DLL which Package Studio installs on an IIS server. Then, from within the workbench application, you can use the Preflight Analysis tool to view the results as they are reported by each execution of your package.

[Page 4 of 5]     1 | 2 | 3 | 4 | 5

• Log on
• Register
• Survey Results