Software implementation installer mechanism6418554Abstract A method and mechanism for automatically installing software implementations such as applications and COM classes as they are needed from an external source. When a software implementation is needed, the mechanism first looks to the local system (e.g., registry) for that software implementation, and if found, returns the information such as a local path needed to use the software implementation. If the implementation is not found, the mechanism looks to another source, such as a CD-ROM or a centralized class store of a network, to locate the needed implementation. When located, the implementation is downloaded and locally installed from the source, and a local path is returned in a manner that is essentially transparent to the user. Software implementations such as application products may be divided into features and components to improve on-demand installation thereof. Claims What is claimed is: Description FIELD OF THE INVENTION
UINT MsiAdvertiseProduct(
LPCTSTR szPackagePath // Fully qualified path to a
package
LPCTSTR szScriptFilePath // If NULL, product is advertised
locally
LPCTSTR szTransforms // Semi-colon delimited list of
transforms
LANGID idLanguage // Language of product being
advertised
);
Upon successful completion, the result is the advertise script 82 containing records for creating advertisement information, e.g., including shortcuts, icon files, and OLE and shell activation registry entries. Note that in the network environment, szScriptFilePath may specify a file stored in the applications folder of the group policy object 66.sub.2 as represented in FIG. 4. In general, the advertise script 82 comprises information corresponding to a series of commands, API calls, or the like, such as resulting in standard API calls to write various information to the registry 74 at certain keys, add application shortcuts to the Start Menu, and so on. For purposes of simplicity, the usage of well-documented APIs to write information to a registry and add shortcuts to menu folders will not be described herein in detail. As shown in FIG. 2, packages such as the packages 80 are stored and cataloged under the class stores 70, and may be available from various vendors for different platforms, activation modes, access control, setup, and installation information. For example, the package 80 may include an entire application (e.g., Microsoft.RTM. Word or Excel), a set of binary component implementations packaged together, or a standalone COM (Component Object Model) component (e.g., an ActiveX.TM. control). Once the advertise script 82 is generated and stored in the group policy template 62.sub.2, a user having the group policy template 62.sub.2 applied thereto (e.g., at logon) receives the advertise script 82 in their user profile 78. Logon code 86 then calls the managed software installer mechanism 84b to process the advertise script 82, the result of which is the creation of a collection of advertisement information 88 including shortcuts on the Start Menu and registry entries required for shell and OLE activation. Advertisement information references the managed software installer mechanism 84b, and, as described below, the operating system 35 knows what to do when it encounters such information. Lastly, in accordance with one aspect of the present invention and as described in detail below, the managed software installer mechanism 84b is involved is when activation occurs, i.e., the managed software installer mechanism 84b is called when an application is activated to install one or more components as needed to service the activation request. In general, executing the advertising script 82 makes the application appear to be available to the user, including writing information to the system registry 74 and adding script information such as shortcuts to assigned programs to the user profile 78 (e.g., the Start Menu or desktop) on the workstation. FIG. 6 shows the steps taken by the logon process 86 at user logon, beginning at step 600 wherein as part of applying the group policy template 62.sub.2 (and any other templates), the logon process 86 writes the advertising script 82 (and any other scripts) to the user profile 72 in the local workstation 20.sub.1. At step 602, an advertise script is selected from the user profile. To resolve potential conflicts in accordance with policy settings, the selection may be in a prioritized order, (as described in the aforementioned "Group Policy" patent application). In any event, once selected, the installer mechanism 84b is called at step 604 to process the script, e.g., populate the registry with information such as file-extension associations, write application shortcuts to the user's Start Menu or desktop and so on as represented by step 606. Step 608 repeats the processing of scripts (one of which will be the script 82) until there are no more to process. More particularly, each of these advertise scripts associated with the directory containers 64 to which the user belongs are handed to the managed software installer mechanism 84b for processing, via the MsiAdvertiseScript() API, as set forth in the table below:
UINT WINAPI MsiAdvertiseScript (
LPCTSTR szScriptFile, // path to script from
MsiAdvertiseProduct
DWORD dwFlags, // the SCRIPTFLAGS
bit flags that control the script execution
PHKEY phRegData, // optional parent registry key
BOOL fRemoveItems); // TRUE if
specified items are to be removed
Possible bits for the "dwFlags" argument include:
Typedef enum tagSCRIPTFLAGS
{
SCRIPTFLAGS_CACHEINFO = 0x00000001L, // set if the
icons need to be
// created/ removed
SCRIPTFLAGS_SHORTCUTS = 0x00000004L, // set if the
shortcuts needs to
// be created/
deleted
SCRIPTFLAGS_MACHINEASSIGN = 0x00000008L, // set if product
to be
// assigned to
machine
SCRIPTFLAGS_REGDATA_APPINFO = 0x00000010L, // set if the app
advt
// registry data needs to be
written/ removed
SCRIPTFLAGS_REGDATA_CNFGINFO = 0x00000020L, // set if the
product cnfg
//mgmt. registry data needs to be
written/ removed
SCRIPTFLAGS_REGDATA = SCRIPTFLAGS_REGDATA_APPINFO .vertline.
SCRIPTFLAGS_REGDATA_CNFGINFO, // for source level
backward compatibility
SCRIPTFLAGS_VALIDATE_TRANSFORMS_ LIST = 0x00000040L
} SCRIPTFLAGS;
The MsiAdvertiseScript() serially executes the list of advertise script information 82 in accordance with the above parameters. Once successfully processed, an advertise script stores information in the user's profile and the system registry that is used to manage advertised applications. This set of per-user information includes attributes for each advertised product, source list information, feature-to-product associations, and descriptors for each advertised component. Note that the script need not necessarily store its data in the registry, but may alternatively store it elsewhere on the local workstation, and the operating system made aware of the location. In accordance with one aspect of the present invention, assigned and published applications may be installed on the local workstation 20.sub.1 on an as-needed basis (on demand) by the managed software installer mechanism 84b. For example, the first time that a user activates such an application (e.g., via the Start Menu), the managed software installer mechanism 84b looks for it on the local machine but does not find it, after which the managed software installer mechanism 84b installs the application, such as via a software implementation 60 maintained in the class store 70 and/or via an application image 90 (FIG. 3) on a network server 92. Note that the network server 92 may be the same server 49 on which the application package 80 was loaded, which may or may not be the domain controller 68, however as can be appreciated, this is not necessary. Thereafter, the application remains on the local workstation 20.sub.1 and need not be re-installed, unless deleted in some manner. However, even if deleted, the application will be re-advertised the next time policy is applied, e.g., at the next user logon, whereby if again activated, the application will again be re-installed. Note that if the application is installed but damaged, e.g., key files are deleted, the application may perform self-repair at this time. In this manner, assigned applications are automatically deployed in accordance with a policy, but for purposes of efficiency, initially may be only advertised rather than installed. Similarly, a standalone user may have programs advertised without taking up substantial storage on the user's machine. Thus, as can be readily appreciated, installing programs only if and when activated provides substantial benefits, including efficient use of workstation resources, rapid user-logon, and balancing of the load on the network servers. To manage the advertised applications, the managed software installer mechanism 84b uses the identifiers set forth in the following table:
{ProductCode} A standard GUID which uniquely identifies
a product.
FeatureID A string which represents a feature. A FeatureID
should be human readable and need only be
unique within a given product.
{ComponentCode} A standard GUID which uniquely identifies
a component.
[Descriptor] A descriptor is comprised of a {ProductCode}, a
FeatureID and a {ComponentCode} within square
brackets, e.g., [{ProductCode}FeatureIDdelim-
iter{ComponentCode}]. A delimiter exists between
the FeatureID and the {ComponentCode} since a
FeatureID is variable in length.
Delimiter ASCII value 2, chosen so as to not collide
with characters that might appear as part of a
FeatureID
In certain cases "compressed" descriptors, which have a slightly different format, may be used. Products, features components and descriptors are described in more detail below with particular respect to FIG. 13. The per-user configuration manager information is stored below the registry key HKEY_CURRENT_USER.backslash.Software.backslash.Microsoft.backslash.Install er. General properties for each advertised product are stored under a Products key by {ProductCode}. An association between the managed software installer mechanism 84b and the operating system 35 (e.g., shell and essentially OLE) enables on-demand installation of software implementations. For example, as represented in FIG. 7, shell and OLE activation code (collectively 85), as well as many shell and OLE-related registry entries, are preferably installer mechanism-aware. To this end, managed shortcuts include a descriptor (based on a shortcut, classID, file extension and so on) that the shell activation code (of the operating system 35) detects, and hands to the managed software installer mechanism 84b, (to await resolution in the form of a path, which it may then process). Similarly, OLE activation is aware of such descriptors, and calls an API of the managed software installer mechanism 84b to resolve them. Both of these operations are represented in FIG. 7 by the circled numeral one. By way of a first example, FIG. 8 shows the general operation taken by the installer 84b when a user attempts to activate an advertised application (e.g., 98) by clicking a shortcut corresponding thereto, beginning at step 800. At step 802, the operating system 35 communicates with the managed software installer mechanism 84b to determine if the application 98 is locally installed, one of the possible states of an advertised application as described below. As represented by the circled numeral two in FIG. 7, the managed software installer mechanism 84b looks to the system (i.e., the registry or similar database) to determine if the state is locally installed (or broken, for purposes of self-repair), and receives this state information as represented by the circled numeral three. At step 804 (FIG. 8), if the application 98 is not locally installed, the installer 84b installs it (or at least some core portion thereof) at step 806, as also represented by the circled numeral four in FIG. 7, wherein the dashed line beside the circled numeral four indicates an optional operation, and as described in more detail below. Also, the state of the application 98 is changed to locally installed, so that the next time activation thereof is requested, installation is not necessary. Lastly, the managed software installer mechanism 84b provides the operating system/OLE 35 with the information needed to execute the application (circled numeral five in FIG. 7), and at step 808 (FIG. 8) the operating system 35 executes the application. Note that except for possible installation delay times, in typical situations, the installation is essentially invisible to the requesting user. Of course, if the source cannot be located, e.g., the network is down or a CD-ROM source is not in the drive, the install may fail and/or the user may see a prompt requesting some user action. More particularly, see the aforementioned U.S. patent application entitled "System and Method for Managing Locations of Software Components Via a Source List." An administrator may also choose to publish an application, essentially to make the application available to a user if needed. Published applications are just as manageable as assigned applications, however unlike assigned applications, a published application has no presence on a user's machine until invoked. Thus, a published application has no attributes on the client machine, but rather has its attributes stored in the Active Directory 66. A published application can be located in the Active Directory in a number of ways, including via an application name, a class ID serviced by the application, a program ID serviced by the application, a file extension serviced by the application, and MIME type or content type serviced by the application. To this end, each of the above attributes may be used as the key to locate a published application in the Active Directory 66. Then, once a published application is located, the application's user-friendly (human readable) name is available, as well as enough information to assign the application to the user. Thus, until needed, a published application is not installed, nor does it appear to the user to be installed. For example, there are no shortcuts present to use for activating the application. Instead, published applications may be activated by the above-attributes such as file extension, in a two-step process as described below with particular reference to FIGS. 9-10. First the operating system 35 shell (or similarly OLE) attempts to locate the application activation information in the local machine's registry 74. If the information is not found (as with a published application), an Active Directory 66 lookup occurs (as described in the aforementioned "Class Store Schema" patent application. This is alternatively shown by circled numerals one and two in FIG. 7. Note that the administrator may prioritize which application in the class stores handles which extension. If found, the application script is advertised as described above, i.e., the application is effectively assigned to the user, the registry is populated, the item added to the Start Menu, and so on as if the application was assigned. The process then launches the application. Conversely, if no associated application is found in the class stores 70, an appropriate error is returned (e.g., no association for this application for this user). Note that the user may be given a roaming profile, whereby such information roams with the user regardless of where the user logon takes place. If not, the information stays on the machine that triggered the assignment. In this manner, published applications as well as assigned applications essentially follow the user around. Once the application is assigned, activation continues as with normal assigned applications. By way of another example of the on-demand installation of applications, both assigned and published applications may be activated by invoking (e.g., double-clicking) a file (document) having an extension with an associated application registered in the registry. FIGS. 9 and 10 show how such an action may lead to the file being installed if needed, beginning at step 900 which represents the double-clicking (or similar operation such as right-click, open) of the document. At step 902, the operating system shell 85 looks to the local registry 74 for file extension information, i.e., an application associated with the file extension. If the information is found, step 904 branches to step 906 which then calls the installer 84b to locate the associated application and return a file system path thereto (FIG. 10) as described below. Note that the administrator may prioritize which application handles which extension since multiple applications may be capable of handling the same file type. If not found in the local registry 74 at step 904, then an application corresponding to the extension has not been assigned, however an application corresponding to the extension may still be published to the requesting user. Published applications are just as manageable as assigned applications, however unlike assigned applications, a published application has no presence on a user's machine until invoked. Thus, a published application has no attributes on the client machine, but rather has its attributes stored in the Active Directory 66. Note that a published application can be located in the Active Directory in a number of ways, including via an application name, a class ID serviced by the application, a program ID serviced by the application, a file extension serviced by the application, an interface identifier serviced by the application and MIME type or content type serviced by the application. To this end, each of the above attributes may be used as the key to locate a published application in the Active Directory 66. Then, once a published application is located, the application's user-friendly (human readable) name is available, as well as enough information to assign the application to the user. Thus, until needed, a published application is not installed, nor does it appear to the user to be installed. For example, there are no shortcuts present to use for activating the application. Thus, when a possibly-published application is invoked, step 904 branches to step 910 to look for the extension information in the Active Directory 66, i.e., the class stores 70 associated with this user. To determine this, at step 910, the operating system calls an application management service 84 to find the appropriate script or scripts and look in the scripts for the file association. To this end, a class store manager 86 is called by the application management service 84 to query the class stores 70 for an appropriate application as described in the aforementioned "Class Store Schema" patent application. This is alternatively shown by circled numerals one and two in FIG. 7. Note that the administrator may similarly prioritize which application in the class stores handles which extension. If found, the application script is advertised at step 914 as described above, i.e., the application is effectively assigned to the user, the registry is populated, the item added to the Start Menu, and so on as if the application was assigned. The process then returns to step 902 so that the application may be launched. Conversely, if no associated application is found in the class stores 70 at step 912, an appropriate error is returned (e.g., no association for this application for this user) at step 916. Note that if the directory lookup is successful, the return information is used to assign the application to the user's profile. As a result, the user may be given a roaming profile, whereby such information roams with the user regardless of where the user logon takes place. If not, the information stays on the machine that triggered the assignment. In this manner, published applications as well as assigned applications essentially follow the user around. Once the application is assigned, activation continues as with normal assigned applications. To launch an application, managed shortcuts include a descriptor (based on a shortcut, classID, file extension and so on) that the shell activation code (of the operating system 35) detects, and hands to the managed software installer mechanism 84b, (to await resolution in the form of a path, which it may then process). Similarly, OLE activation is aware of such descriptors, and calls an API of the managed software installer mechanism 84b to resolve them. FIG. 10 shows the steps taken by the installer 84b to locate the application, and install it as needed. When the installer 84b receives the extension information, (step 1000), the managed software installer mechanism 84b determines if the application is locally installed at step 1002, one of the possible states of an advertised application. As represented by the circled numeral three in FIG. 7, the managed software installer mechanism 84b looks to the system (i.e., the registry or similar database) to determine if the state is locally installed, and receives this state information as represented by the circled numeral four. If the application is not locally installed, the installer 84b installs it, (e.g., into a program files folder 75, FIG. 5, of the file system), as shown by circled numeral five and at step 1004, (or at least some core portion of the application), as also described in the aforementioned copending United States Patent Application entitled "Method and System for On-Demand Installation of Software Implementations" hereby incorporated by reference herein in its entirety. Also, at step 1006, the state of the application is changed to installed, so that the next time activation thereof is requested, installation is not necessary. As part of the process that returns the file system path, the installer 84b also verifies that the application in question has been installed and/or has its key files intact, as represented by step 1008. If the application is not installed, or is determined to be damaged, the installer will install and/or repair the application by installing any needed files, as represented by steps 1010 and 1012. Lastly, at step 1014, the installer returns the application path to the operating system. Regardless of whether previously installed or not, and assuming no other errors, security problems and so forth, the application is launched at step 908 (FIG. 9 and circled numeral six, FIG. 7), and the application appropriately opens the document. Note that many file extensions are capable of being handled by multiple applications. The administrator or user may prioritize which applications open which files. To this end, each application sets forth the file extensions it is capable of handling, and this information is stored in the Active Directory 66. When a file extension is selected, a suitable mechanism may be employed to scan the application information in the Active Directory to locate those applications that handle that file type. Via a suitable user interface, the administrator may then determine which application association gets written into the registry for that file type, and also may rank the order of searching for a suitable application in the class store 70 to open the file in the event that the association is not found in the registry. The ability to recognize applications which service the same extension, and therefore the ability to prioritize them, stems largely from two features of the installer, i.e., the ability to create advertise scripts, and the fact that the extensions serviced by a given product can easily be read from .MSI packages. In addition to installing applications, the managed software installer mechanism 84b may install other software implementations such as an application's object classes 94 (FIG. 2). To this end, the class store 70 maintains the classes 94 (or the information needed to locate the classes on the network). When the operating system 35, OLE or the like receives a request for an object class, it first communicates with the managed software installer mechanism 84b to determine if the object class is locally installed. If not found locally, the managed software installer mechanism 84b looks for the object class in the class store 70. If found, the managed software installer mechanism 84b installs the object class therefrom, instead of returning an error. The managed software installer mechanism 84b may also install software implementations based on information such as component categories 96. For example, a category to which an application belongs effectively may be "spreadsheet." If the managed software installer mechanism 84b receives a category request for a spreadsheet application, the mechanism 84b may look to the component categories 96, also maintained in the class store 70, to determine if a spreadsheet application is published to the user, and if so, install that application. In general, the managed software installer mechanism 84b provides a standard installation mechanism for applications and components, i.e., it is an execution engine for the setup scripts generated by the application deployment editor 78 or other various authoring tools. In general, the package is what a developer uses an authoring tool to create, i.e., essentially when a developer "writes a setup," the result is a Windows installer package. From that package, advertise scripts are created, and subsequently executed. However, it is also possible to install the package itself by generating and then running an install script. Generation and execution of install scripts are both handled on the end user's machine, in contrast to the advertising script model. For example, this happens in response to a standalone install, or as the result of install on demand. As described in more detail below, the managed software installer mechanism 84b also exposes an application programming interface (API) which an application program 98 may use (FIG. 11) to determine what installation choices users made, or even to install missing components. For example, if a component is missing, the application 98 itself may in effect run setup for the user, using installer APIs as set forth below to install the missing component. Moreover, because the managed software installer mechanism 84b is a basic system service that tracks information about what is installed, it may provide administrators in managed environments with a powerful set of tools for determining the software installed, and remotely pushing software installation down to user machines. FIG. 12 illustrates the managed software installer mechanism 84b architecture as embodied in the Windows NT.RTM. operating system, wherein the installer consists of two executable components, a client install engine 100, which runs with user privileges 102, and an install service 104. Because the install service 96 is implemented as an NT Service, it may be run with elevated administrative privileges 106. Note that changes to the system configuration (e.g., changes to the registry 74 and file system 35) are done as an installation transaction 108 by the install service 104, and the rollback transactions 110 are logged to provide for rollback of a failed or aborted installation. The rollback includes restoring the original contents of files replaced or deleted during the installation and restoring overwritten or deleted registry settings (e.g., COM class registration). Note that since this rollback information 110 may take up a significant amount of space, it may be disabled by an administrator or a user when performing an installation. The client install engine 100 and the install service 104 communicate through secure remote procedure calls. Note that where everything is in the same process, (e.g., in Windows 95 or Windows98), secure RPC is not used. Although not necessary to the present invention, to improve installation, the installer 84b is arranged to divide applications into a three-level hierarchy, such as in the sample feature hierarchy shown in FIG. 13. At the top of the hierarchy is a product 112, which is an implementation that an administrator or end-user may install, e.g., a specific word processing application package such as Microsoft.RTM. Word. As further shown in FIG. 13, a product may be composed of multiple features such as the features 114.sub.1 -114.sub.4, wherein a feature is the smallest installable unit of functionality. Examples of features of a word processor are a reader 114.sub.1, Editor 114.sub.2, Spellchecker 114.sub.3, and Printer 114n. A feature is something an administrator/user may choose to install or not, and thus somewhat corresponds to a checkbox in the "Custom" or "Advanced" installation dialog of a conventional installation mechanism. Features in turn comprise one or more components such as 116.sub.1 -116.sub.6, wherein a component is the smallest unit of sharing among products and features. For example, a component such as component1116.sub.1 may be shared by both the Reader feature 114.sub.1 and the Editor feature 114.sub.2. Only one copy of the corresponding file 118.sub.1 (e.g., a DLL) is actually installed, but that copy is installed if either Feature1 or Feature2 is installed. Note that while FIG. 13 shows components composed of files 118.sub.1 -118.sub.9, components are the actual contents of a product, and may be composed of files, registry entries, COM registration information, Visual Basic type libraries, shortcuts, (e.g. for the Windows Start menu), and so on. While features are specific to a product and identified by a name unique only within the product (e.g. "Reader"), components are global across all products installed on a machine and are identified by a GUID. Note that although COM components are also uniquely identified by a GUID and may be encapsulated as an installer component, an installer component is not related to COM. An installer component 116 is monolithic, i.e. it is either entirely installed on a machine or not installed at all. Because installer component identifiers are global, they are shared across products. By way of example, a number of products ship the Microsoft Visual Basic for Applications (VBA) runtime. Defining VBA as an installer component 116 provides advantages, including that the installation logic for VBA can be encapsulated within the component 116, so all products which install VBA will install and uninstall it in exactly the same way. Also, once VBA is installed on a machine, the managed software installer mechanism 84 knows that VBA is there, and installation of subsequent products which use this component simply increase an installation reference count of the component, i.e., the products share the same copies of the files. Moreover, since the managed software installer mechanism 84 manages the installed components, it operates properly when a product is uninstalled, i.e., the reference count ensures that the mechanism does not remove components shared by products remaining on the machine. FIG. 14 shows how the operating system/OLE requests a full component path that may result in the on-demand installation of components and/or features as needed, such as by using the MsiProvideComponentFromDescriptor API set forth below. In general, a descriptor is a token representing a product code/feature name/component GUID. First, the operating system calls the API at step 1400, requesting a full component path. In turn, the API (via the MsiUseFeature API, described below) checks the local machine at step 1402 to detect that the components that make up that feature are installed. Note that the API only installs one feature, i.e., the one that was requested, however, if there are "ancestors" of that feature in the feature hierarchy defined in the package, those are also installed (if not already installed). In other words, a given feature may not be installed if its parent is not also installed. Likewise, when verifying that all of the components in the feature are valid, the components in all ancestor features are also verified. In any event, if not installed, step 1404 branches to step 1406, to install (via the MsiConfigureFeature API, also described below) the needed piece or pieces of the product. Lastly, step 1408 obtains the path to the key file via the MsiGetComponentPath API, also described below) and returns it to the operating system, which then executes that path at step 1410. Turning to an explanation of how an application may interface with the managed software installer mechanism 84, FIGS. 15A-15B generally represent the steps taken by the application 98 and installer 84 (FIG. 11) to provide on-demand installation of features and components. First, at step 1500 of FIG. 15A, the application 98 determines that it needs a feature or component, (or at least state information regarding same). At step 1502, using the QueryFeatureState API, (described below), the application 98 requests the state of the feature or component from the installer. The state may be Absent, i.e., intentionally turned off by the user or administrator, and thus should not be installed by the application. Otherwise, the state may be Local (locally installed), Source (residing on a source media such as a network drive), or Advertised, (not installed but may be installed from the source when first needed). Based on the state, step 1506 determines whether the feature or component needs to be installed, i.e., it is not locally installed, but now it is needed and is proper for local installation. Step 1508 represents the installation on demand. Step 1520 (FIG. 15B) is next executed, wherein the application 98 requests the installer 84 to verify that the needed files are present. To this end, the MsiUseFeature API is called. In general, the MsiUseFeature API does two things, i.e., verifies that the feature is intact, and increments the usage count (the usage count is the number of times that the user or application has used the feature). Note also that, if the feature is installed as run-from-source, (e.g., from the network or CD-ROM), part of the verification that the feature is intact involves finding a valid source. At step 1522, a verify status of valid or invalid is returned, whereby step 1524 branches to step 1526 to install needed files if the status is invalid. Note that until valid, step 1526 may keep returning to step 1520 to request verification, some number of times before failing (not shown). However, if the verification returns valid status, at steps 1528-1530, the application 98 requests and receives the path from the installer 84 and loads/executes it as appropriate. In this manner, applications may repair themselves such as by installing missing or damaged components or files. Applications may avoid errors by checking with the installer 84 before making assumptions about what is installed on a machine at a given time. Missing features and components will be automatically installed by the installer mechanism whenever possible (and if allowed). The Windows installer (MSI) APIs The following describes some of the MSI APIs utilized for on-demand installation of software implementations, wherein the "%" symbol represents ANSI (A) and Unicode (W) versions. MsiGetProductCode returns the product code for a registered component, i.e., this API returns information on the product that installed an application:
UINT WINAPI MsiGetProductCode%(
LPCSTR% szComponent, // component ID registered for this product
LPSTR% IpBuf39); //returned string GUID, sized for 39 characters
With the product code, the application may check its features, one by one, on an as needed basis, using MsiQueryFeatureState(ProductCode, FeatureID):
INSTALLSTATE WINAPI MsiQueryFeatureState%(
LPCSTR% szProduct,
LPCSTR% szFeature)
In this manner, an application may, for example, set itself to display appropriately available features and hide or otherwise indicate (e.g., visually gray out) those that are not available. To check features, the application calls MsiQueryFeatureState(ProductCode, FeatureID) using the product code returned in MsiGetProductCode() and the Feature ID of interest. As generally described above, if the return state is INSTALLSTATE_UNKNOWN or INSTALLSTATE_ABSENT, the feature is not available, and for example, should not be displayed in a user interface. For example, if the spellcheck feature is turned off by an administrator, it should not appear available to the user. Note that a feature that is absent is still technically available, although an application may choose to treat it as unavailable, as it implies that the user has indicated that the user wanted to make the feature go absent. However, if the return value is INSTALLSTATE_ADVERTISED, the feature has been advertised/published and is available. If the return value is INSTALLSTATE_SOURCE or INSTALLSTATE_LOCAL then the feature has been installed. Lastly, if the return value is INSTALLSTATE_SOURCEABSENT (the feature is installed to SOURCE, but the source is unavailable, e.g., the network is down). Note that MsiQueryFeatureState will not return this, only the "installed" state of the feature, however MsiUseFeature may return this state. A management tool, for example, may enumerate the published features for a given product by calling MsiEnumFeatures:
UINT WINAPI MsiEnumFeatures %(
LPCSTR% szProduct,
DWORD iFeatureIndex, // zero based index into published features
LPSTR% IpFeatureBuf, //feature name buffer, size =
MAX_FEATURE_CHARS+1
LPSTR% IpParentBuf), // parent feature buffer, size =
MAX_ FEATURE_CHARS+1
To request and install a feature, the following procedure may be used: Call MsiUseFeature, passing in the ProductCode and FeatureId. If the return code is INSTALLSTATE_LOCAL or INSTALLSTATE_SOURCE, proceed down the hierarchical "pyramid" of code. If the return code is INSTALLSTATE_UNKNOWN or INSTALLSTATE_ABSENT, an error occurred, since MsiQueryFeatureState should first be called to ensure that only features known to be available are requested. If the return code is INSTALLSTATE_ADVERTISED, call MsiConfigureFeature, passing in the ProductCode, FeatureId and INSTALLSTATE_DEFAULT. The following are return states from MsiUseFeature: INSTALLSTATE_UNKNOWN: the product/feature is not known INSTALLSTATE_ABSENT: the feature is in the absent state INSTALLSTATE_ADVERTISED: the feature is in the advertise state INSTALLSTATE_SOURCE: the feature is install run-from-source and a valid source is available INSTALLSTATE_SOURCEABSENT: the feature is install run-from-source and a valid source is not available INSTALLSTATE_LOCAL: the feature is installed locally and the components that comprise the feature (and its parents) are all intact INSTALLSTATE_BROKEN: the feature is installed locally and the components that comprise the feature (and its parents) are not all intact (one or more keyfiles are missing) Note that the above algorithm is one possible way to treat the return values from MsiUseFeature, but not the only way. For example, (although not preferable) an application could choose not to use MsiQueryFeatureState, but could simply use the return value from MsiUseFeature to determine whether a feature was usable or not. MsiUseFeature indicates an intent to use a product feature and increments the usage count therefor:
INSTALLSTATE WINAPI MsiUseFeature%(
LPCSTR% szProduct,
LPCSTR% szFeature)
MsiConfigureFeature forces the installed state for a product feature:
UINT WINAPI MsiConfigureFeature %(
LPCSTR% szProduct,
LPCSTR% szFeature,
INSTALLSTATE eInstallState);
//local / source / default / absent / lock / uncache
An alternative to MsiConfigureFeature is MsiConfigureFeatureFromDescriptor, useful for making templates, add-ins and Access wizards more resilient. MsiConfigureFeatureFromDescriptor is essentially the same as MsiConfigureFeature, but takes a descriptor (token) rather than separate product and feature parameters:
UINT WINAPI MsiConfigureFeatureFromDescriptor %(
LPCSTR% szDescriptor,
INSTALLSTATE eInstallState); //local / source / default / absent
Once an application has requested a feature, it may perform its usual operations such as loading DLLs, opening data files and so on. However, as long as the application first asks where the file is located, dynamically loading DLLs should not fail for DLLs that are the key file of a component. The general information for accessing a file is set forth below: Call MsiGetComponentPath, passing in the component ID and other appropriate parameters. If the return code is INSTALLSTATE_ABSENT, then MsiUseFeature/MsiConfigureFeature was not properly called. If the return code is INSTALLSTATE_UNKNOWN, then the component is not installed/known. If the return code is INSTALLSTATE_DEFAULT, then the call was successful. (see the return values for MsiGetComponentPath. We never return INSTALLSTATE_DEFAULT. INSTALLSTATE_LOCAL and INSTALLSTATE_SOURCE imply success). If the return code is INSTALLSTATE_SOURCE_ABSENT (see above), then, for example, the network has gone down, or a CD-ROM is not loaded in the appropriate drive, whereby resiliency procedures should be invoked. A fully qualified key file should be returned, and parsing may be needed such as if a file that is not the key file is desired. In certain situations, i.e., when accessing a folder, a path is returned without a key file. Also, if the "key file" is a registry key or value then the registry key or value will be returned instead of a path to a file. The following sets forth the return values for MsiGetComponentPath: INSTALLSTATE_NOTUSED: The component being requested is disabled on the computer. INSTALLSTATE_ABSENT: The component is not installed. INSTALLSTATE_BAD_CONFIGURATION: The configuration data is corrupt. INSTALLSTATE_INVALIDARG: One of the function parameters is invalid. INSTALLSTATE_LOCAL: The component is installed locally. INSTALLSTATE_SOURCE: The component is installed to run from source. INSTALLSTATE_SOURCEABSENT: The component source is inaccessible. INSTALLSTATE_UNKNOWN: The product code or component ID is unknown. MsiGetComponentPath is a registry lookup that returns the full path to an installed component:
INSTALLSTATE WINAPI MsiGetComponentPath %(
LPCSTR% szProduct, // product code for client product
LPCSTR% szComponent, // component ID, string GUID
LPSTR lpPathBuf, // returned path
DWORD *pcchBuf) in / out buffer character count
A typical method is to call MsiGetComponentPath after performing the feature request steps set forth above. An alternative is to call MsiProvideComponent, which bundles three APIs (MsiUseFeature, MsiConfigureFeature, MsiGetComponentPath) into one. MsiProvideComponent returns the full component path, performing any necessary installation. As described with reference to FIG. 8, MsiProvideComponent and MsiProvideComponentFromDescriptor call MsiUseFeature to detect that components are installed, calls MsiConfigureFeature if any of its components are uninstalled, and then calls MsiGetComponentPath to obtain the path to its key file:
UINT WINAPI MsiProvideComponent %(
LPCSTR% szProduct, // product code in case install required
LPCSTR% szFeature, // feature ID in case install required
LPCSTR% szComponent, // component ID
DWORD dwReserved //reserved, must be zero
LPSTR% lpPathBuf, // returned path, NULL if not desired
DWORD *pcchBuf) in / out buffer character count
MsiProvideComponentFromDescriptor is essentially the same as MsiProvideComponent, but uses a descriptor instead of the product/feature/component identifiers:
UINT WINAPI MsiProvideComponentFromDescriptor %(
LPCSTR% szDescriptor // product, feature, component information
LPSTR% lpPathBuf, // returned path, NULL if not desired
DWORD *pcchBuf) in / out buffer character count
DWORD *pcchArgsOffset) returned offset of args in descriptor
This API, and MsiInstallMissingFile, below, are final, alternative attempts to fault in a feature, given a component or filename. It is expected that an application developer will attempt to use the other APIs to fault in features, but this may not always be possible. As a result, it is anticipated that such developers may benefit via these APIs. To recover from a missing component error (following a call to MsiLocateComponent), a missing component may be reinstalled by MsiInstallMissingComponent, checking for a return code of ERROR_SUCCESS and then calling MsiLocateComponent again:
UINT WINAPI MsiInstallMissingComponent %(
LPCSTR% szProduct, // product code
LPCSTR% szComponent, // component ID, string GUID
INSTALLSTATE eInstallState); //local / source / default / absent invalid
To recover from a missing file error (i.e., an application has failed in an attempt to open a file) the general procedure of calling MsiInstallMissingFile, checking for a return code of ERROR_SUCCESS and then re-trying the file I/O operation:
UINT WINAPI MsiInstallMissingFile %(
LPCSTR% szProduct, // product code
LPCSTR% szFile); // filename without path
As can be seen from the foregoing detailed description, there is provided a method and system for automatically deploying applications across a network in accordance with a policy. Via a script associated with a policy, and applied at user logon or machine connection to the network, applications may be assigned to policy recipients (users or machines), whereby the assigned applications are advertised to those policy recipients. Other applications may be published to users, whereby the application may be indirectly activated. While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
|
Same subclass Same class Consider this |
||||||||||