#16 Performing Silent Installs

Evaluate
open
mesheets
5
2007-09-27
2007-08-22
No

I have modified code files in both the dotNetInstaller and InstallerEditor projects to add basic support for silent installs. The approach for adding such support was as follows:
* Addition of a "silent_install" property to the Bootstrapper XML
* Implementation techniques were chosen based on which approach was deemed to change lesser amounts of code

Notes:
* At the present, a command line switch for performing silent installs has not been implemented. Because of the added "silent_install" property, end-users don't need to be concerned with command-line switches, but I can see where a command line switch feature might be of benefit to others. Such a feature should be able to leverage the changes already made in support of silent installs.
* Dialog boxes are bypassed if a silent_install is requested. If the dialog box is triggered due to an error or other unexpected condition, it is possible that the process that launched a dotNetInstaller setup exe may not know that there was a failure somewhere along the way. Perhaps an ErrorLevel bitmask could be used to signify various error states (similar to RoboCopy)?

Attachment:
The attached *.zip file contains only the files that were modified. Download the version 1.3.3.0 source, and then copy the contents of the attached zip over top the original source. I found WinDiff directory and file comparison to be helpful in viewing my changes against the original.

Disclaimer: I would like to emphasize that the modifications and testing were based on my current usage needs. In other words, I am not (yet) using all the features of dotNetInstaller, and while I have attempted to cover all potential areas, I may have missed a few things along the way. Nevertheless, I am posting this in the hope that it may be of benefit to the community and perhaps even be enhanced by others.

Thank you,
Matthew

Discussion

  • Davide Icardi

    Davide Icardi - 2007-08-27

    Logged In: YES
    user_id=1515232
    Originator: YES

    I have added some code to the previous mod that should display a dialog box and then automatically close it after a period of time if there has been no user input. In silent install mode, I thought this addition might be useful for allowing an end-user to visually see an error message while not disrupting the overall flow of a silent install.

    At this point, I have not converted any existing message box code to use the timed message box. The attached mod simply adds additional functionality to the previously uploaded silent install mod--copy in the previous silent install mod, then copy in this mod.

    Thank you,
    Matthew
    File Added: dni_SilentInstallMod2.zip

     
  • Davide Icardi

    Davide Icardi - 2007-08-30

    Logged In: YES
    user_id=1515232
    Originator: YES

    Two items are included with this update--

    1) I found a section that was not automated when a silent install was specified; this has been corrected.

    2) An "alwaysdownload" boolean attribute was added to the Download element. When true (which is the default value), the existing application behavior is preserved. (The existing behavior is to always download the file, regardless of whether it already exists locally.)

    When false, the file will NOT be downloaded if a the file already exists at the full file name path specified by the download attribute values. This enables the same Bootstrapper configuration XML to be used for both standard installs and web installs.

    In turn, if used in this dual-mode manner, this also means that the download destination path would be somewhere accessible by a standard install, which is typically under the #APPPATH folder. The documentation recommends that destination path be under #TEMPPATH. In my usage scenario, the 7-Zip Setup SFX is used to package all the prerequisites and install files into a single, self-extracting, auto-launching executable. In Setup SFX configuration, 7-Zip extracts to a folder in the %Temp% directory and then launches setup.exe from the folder created under %Temp%. Thus, under that scenario, #APPPATH is actually a child directory of #TEMPPATH, so this approach of using #APPPATH as the download path should still be compliant with the spirit of the #TEMPPATH download path recommendation.

    The attached file is a cumulative collection of files modified for silent installs and now download bypassing; dni_SilentInstallMod.zip and dni_SilentInstallMod2.zip are not needed.

    Thank you,
    Matthew
    File Added: dni_SilentInstallMod3.zip

     
  • Davide Icardi

    Davide Icardi - 2007-09-26

    Logged In: YES
    user_id=1515232
    Originator: YES

    I have another update that enhances earlier updates plus adds some new functionality.

    1) Silent Install – A command line flag of “/q” or “-q” is now supported. Additionally, I changed my previous configuration-file-based silent install implementation from being at the <configuration> level to being at the root <configurations> level. After becoming more familiar with the application, I thought it was a better approach (plus, it made it much easier to implement command-line support).
    a) Specifying a “quiet” flag (/q or -q) on the command line will override a <configurations> attribute of silent_install = false.
    b) If a parent <configurations> element has a silent_install attribute of true, all “children” <configurations> elements will be run in silent install mode, even if the silent_install attribute of that element is false. Where this typically comes into play is when a <configuration> of type “reference” downloads another configuration file and processes it. For example, if the initial configuration file is running in silent mode, the downloaded configuration file will also run in silent mode.

    2) AlwaysDownload – This earlier addition was preserved. If AlwaysDownload = false and the file already exists locally, dotNetInstaller will not download the file.

    3) Timed Message Box – This earlier addition was preserved, though it has not been incorporated anywhere.

    4) OS Filter Handling – The OS Filter handling was modified at the <configuration> level so that it behaves in a similar fashion to the handling of LCID. In the 1.3.3.0 source, the install is aborted if the OS Filter does not match; if the LCID does not match, it will skip that <configuration> and try the next one. With this modification, if the OS Filter does not match, the current <configuration> will be skipped and the next <configuration> (if present) will be processed.

    5) Execute Multiple <Configuration> Elements – In the current 1.3.3.0 source, once the first <configuration> match is found, only that <configuration> element will be processed. With this update, all <configuration> elements that match at runtime will be processed. This enables greater flexibility in installer creation. For example, I may have 3 prerequisites that MUST be installed before my application can run. So, I leave the advanced_caption attribute value empty to disable the “Advanced” button. The application, though, may be more of a suite of self-contained modules, and I want users to be able to pick and choose which modules to install. Thus, I can create an additional <configuration> element, this one with the “Advanced” button enabled. As long as the LCID and OS properties are a match, both the prerequisite and application suite <configuration> elements will be processed. While an MSI with module-selection capabilities could likely be created, by leveraging dotNetInstaller’s download-on-demand capabilities, users only need to download those modules that they wish to install.

    6) File Check of type Exists – In the current 1.3.3.0 source, if a file check is running with a comparison type of “exists”, installerTypes.h generates an “invalid comparison type” message. Support for the “exists” type was added to file checks, and in this case the fileversion attribute is ignored and dotNetInstaller only checks for the presence of the file. The existing behavior of ignoring the comparison attribute type if the fileversion attribute was empty is retained.

    7) IDD_DialogInstall – I changed the SystemMenu property to false to prevent this dialog from being closed by an end-user. Otherwise, if a user closed this dialog, they could click the “Install” button again while the initial install instance was still running.

    The attached zip file is a cumulative collection of the files that have been modified to facilitate the described changes. I have also included some test cases I used; the AlwaysDownload flag is set to False on for the reference config files, so if all the test files are in the same directory, you won't need to post anything to a web server. For actions, the test cases do thing such as run notepad, wordpad, calc, etc. instead of running some installer.

    Thank you,
    Matthew
    File Added: dni_SilentInstallMod4.zip

     
  • Davide Icardi

    Davide Icardi - 2007-09-27
    • assigned_to: nobody --> mesheets
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks