Logging can be useful to see where a setup failure may have occurred. Both SETUP.EXE and MSIEXEC.EXE create a play-by-play report of the install process. Logs might be especially helpful if an escalation is deemed necessary. Microsoft Project 2000 ships with logging turned off by default.
To enable logging during the Microsoft Project 2000 setup, start setup using the following switches: Setup.exe /l c:\logfile.txt
Additional switches are available to specify which information is written to the log file.
|
|
For more information on which switches to use with logging, see the Microsoft Project 2000 Resource Kit. |
With traditional installation technology, it was necessary to exit an application and rerun setup to perform an installation task. This commonly occurred whenever a user wanted a feature or product they had not chosen during the first run of setup. This often made the process of product configuration inefficient because it required the user to anticipate which functionality they required before they ever used the product. With the Windows Installer, however, users can install functionality on the fly.
Installation-on-demand makes it possible to offer functionality to users and applications in the absence of the files themselves. This notion is known as advertising. The Windows Installer has the capability of advertising functionality and to install-on-demand application features or entire products. Whenever a user or application activates an advertised feature or product, the installer proceeds with an installation of the needed components. This speeds up the configuration process because additional functionality can be accessed without having to exit and rerun another setup procedure.
A large portion of logic used in the Window Installer hinges on component detection. Component detection is key in preventing DLL conflicts that often plague applications that share common files. Whereas ACME used a procedural script to install a disjointed collection of files, registry keys and other resources, the Window Installer views all applications as three logical building blocks: Components, Features, and Products. You can use the Window Installer to detect missing components or files and then to 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.
Before addressing “Component Detection”, we need to look at these basic building blocks of Window Installer.
Components |
The smallest installation unit for Window Installer is the component. A component can be a collection of files, registry keys, shortcuts or INI file entries. Components are commonly hidden from the user. Whenever a user selects some feature for installation, the installer determines which components are required. Only a single instance of any component is ever installed and so several features may end up sharing some components. A component does not necessarily have to contain any files. When a component contains one or more files, all files are installed into the same folder. This is a rule of Window Installer.
|
|
The “Golden Rule” of installer components: No single file (as defined by filename and install location), registry entry, shortcut or other resource should ever be shipped as a member of multiple installer components. This rule applies across products, product versions, and companies. |
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.
