CSCI E-143 CertPrep:   Deployment   (Kalani, chapter 13)

Saturday,  Dec. 11,  2004

This Saturday we cover Kalani's chapter 13,  "Deploying a Windows Application".   "Deployment"  here means the installation of your project on a  "target" machine—one different from your own.

This may not be the most important chapter in Kalani,  but it may be the most confusing.   And the following writeup may have the most excessive and unnecessary amount of detail.

Ambiguous Terms

Here are some terms that have more than one meaning in this chapter:

Installer.   There may be as many as half a dozen meanings to this term.   Here are two meanings you must distinguish now:   (The others are described under  "Installation Components",  below.)

  1. The installation package you set up with the "Setup Project" wizard,  which you may modify with the six setup editors.   This package,  when compiled,  comprises a single module,  with an extension of  .msi.   Kalani describes the start of such a project on pages 846-849.
  2. The Windows  "Installer"  service which runs this .msi  package.   Needless to say,  the target machine must have this "Installer".   If it doesn't,  we pass to the next topic:

Bootstrapper.   There are two things that may be "bootstrapped",  or loaded during installation:

  1. The Windows Installer,  #2 in the above list.   You can include this with your installation package.     (Kalani, page 849)
  2. The .NET Framework,  which must be present on the target machine.   You cannot,  as a matter of course,  include this bootstrapper with your installation package.   Kalani discusses its installation on pages 849-850.   Invoking this Framework installation from your installation package is not trivial.   On pages 927-928,  Kalani has an example that does it.

"Cab".   This term apparently has two unconnected uses:

  1. On page 842,  Kalani says that a "Cab project" is for packaging ActiveX components.   We will not be concerned with this.
  2. On page 851,  under the "Package files" option for .msi  output,  the "Cabinet file" option seems to control only the size of CAB files,  for instance,  the size of files that can be placed onto a floppy.

Registry Editor.   Distinguish these two meanings:

Installation Packages

Types of Installation packages

XCOPY Deployment.   This is of limited usefulness,  because it can only be used to copy from your media to the target machine,  in a location specified by the user.   If you want to do any of the things normally done during installation,  such as creating shortcuts,  selecting optional features during installation,  using different paths on the target machine,  running routines during installation,  etc.,  etc.,  etc.  (see the list on Kalani's page 840),  then you must use a custom installer.

Types of Deployment projects.   There are four different kinds:

  1. Windows setup projects,  which we are concerned with here
  2. Web setup projects,  for deploying web-based routines,  which we will ignore
  3. Merge Module projects,  for components shared by multiple apps;  briefly discussed at the end of the chapter
  4. Cab projects,  which contain ActiveX components for download over the internet,  which we will also ignore.

Setting up an  Installation package

You can begin either with a Setup wizard (described on pages 847-848) or with a Setup project (described on pages 856-857).   You will be asked to specify such things as

In addition,  you can customize the basic project,  using one of six editors to make various settings and perform various actions on the target machine.

Allowing the user to decide actions during installation     (Kalani, pages 866-867)

Passing data into a routine run during installation     (Kalani, pages 899-901)

Using the Global Assembly Cache

Requirements for Placing a Shared Assembly into the GAC

Placing Shared Assemblies into the GAC

How the CLR Locates Assemblies       (Kalani, pages 880-881)

  1. It determines the version of the assembly to load.   It relies on the various  config  files that were discussed in Chapter 15,  Configuring,  especially for the  codebase  and the  probing  elements.

  2. It asks if the assembly is already loaded.

  3. It looks in the GAC.

  4. It uses the path specified in the  codebase  element,  if any.   See  Chapter 15,  Configuring.

  5. If there is no culture information,  it looks in the application's installation directory and its sub-directories,  as defined by the  probing  element.   See  Chapter 15,  Configuring.

  6. If culture information is available,  it looks in the application's installation directory and its sub-directories,  using path names qualified by the cultural information and the  probing  element.

Delay-Signing

Merge Modules       (Kalani, pages 884-889)

These are used for packaging components such as DLLs.   (The description is placed here,  after the explanation of the GAC,  because Merge Module contain shared assemblies you will almost certainly want to place into the GAC.)

Installation Components

It may happen during deployment that you will need to create components on the target machine that cannot be created with the various deployment-customizing editors described above.   For instance,  you may need to create Performance Counters or Event Logs on the target machine.   To do this,  you will have to write custom installation components.

We now come to the other possible meanings of the term "Installer".   Here is the complete list:

Meanings already discussed above:

  1. The installation package you set up with the "Setup Project" wizard,  which you may modify with the six setup editors.   This package,  when compiled,  comprises a single module,  with an extension of  .msi.   Kalani describes the start of such a project on pages 846-849.
  2. The Windows  "Installer"  service which runs this .msi  package.

New meanings,  discussed below:

  1. The  Installer  Class,  which you may instantiate to perform specific tasks during installation of your code on a target machine.
  2. This  Installer  Class itself has a list of Installers,  which are themselves instances of the Class that install components needed during installation of the whole.   An "Installer" may refer to any one of these.
  3. Your project may need a Performance Counter on the target machine.   A Performance Counter is installed by a specific routine,  the  PerformanceCounterInstaller.   Each specifically designed one of these,  then,  is also an "Installer".
  4. Install()  is also the name of the principal method in the  "Installer"  class.
  5. "Installer"  may also refer to the Windows utility,  installutil.exe,  that runs your instantiation of this  Installer  Class.

The Installer Class

Namespace:  System.Configuration.Install

Important members:

Required Attribute:  add

[RunInstaller(true)]
to your class definition to get your Installer object to run during a setup project.

The  .InstallState  file remembers the state of the installation.   It is created by the  Install()  method,  and is used both by the  Rollback()  and the  Uninstall()  methods.

An assembly containing such Installers may be run two ways:

An installed assembly may be uninstalled with this command: 

installutil.exe  /u  Foo.dll

Here is an example of such an install module,  taken from Kalani's example on pages 899-900.   It is here just to show what the code looks like.   The code is not complete: 

  [RunInstaller(true)]
  public class Foo : System.Configuration.Install.Installer
  {
    public Foo()
    {
      // This call is required by the Designer.
      InitializeComponent();

      // TODO: Add any initialization after the InitComponent call
    }

    public override void Install(System.Collections.IDictionary savedState)
    {
      // call the Install method of the base class
      base.Install(savedState);

      // Get the arguments pass to the class
      string strArgs = this.Context.Parameters["Args"];
      if (strArgs == "")
        throw new InstallException("No arguments specified");
      
      //HERE DO THE WORK TO INSTALL THE COMPONENT.
    }

    public override void Commit(System.Collections.IDictionary savedState)
    {
      // call the Commit method of the base class
      base.Commit(savedState);
    }

    public override void Rollback(System.Collections.IDictionary savedState)
    {
      // call the Rollback method of the base class
      base.Rollback(savedState);
    }

    public override void Uninstall(System.Collections.IDictionary savedState)
    {
      // call the Uninstall method of the base class
      base.Uninstall(savedState);
    }
  }

When you add, say,  an Event Log to your app,  you will see,  in the properties window for the Event Log you have added,  an option to  "Add Installer".   If you do this,  you will get an entire module generated by the IDE.   An example follows.

You will note that it has no  Install()  or  Commit(),  etc.,  methods.   These methods are in the base class,  System.Configuration.Install.Installer.   All that this derived class has,  in the  InitializeComponent()  method  at the end,  is the creation of an  System.Diagnostics.EventLogInstaller  object,  itself derived from the  Installer  class,  and the addition of this instance to the container's  Installers  property.

All  of this code is here just to be informative  (if not intimidating).   I doubt any of it will come up on the exam. 

using System;
using System.Collections;
using System.ComponentModel;
using System.Configuration.Install;

namespace InstallTest
{
  [RunInstaller(true)]
  public class ProjectInstaller : System.Configuration.Install.Installer
  {
    private System.Diagnostics.EventLogInstaller eventLogInstaller1;

    private System.ComponentModel.Container components = null;

    public ProjectInstaller()
    {
      InitializeComponent();

      // TODO: Add any initialization after the InitializeComponent call
    }

    protected override void Dispose( bool disposing )
    {
      if( disposing )
      {
        if(components != null)
        {
          components.Dispose();
        }
      }
      base.Dispose( disposing );
    }

    #region Component Designer generated code - do not modify

    private void InitializeComponent()
    {
      this.eventLogInstaller1 = new System.Diagnostics.EventLogInstaller();
      // 
      // eventLogInstaller1
      // 
      this.eventLogInstaller1.Log = "Application";
      this.eventLogInstaller1.Source = "InstallTest";
      // 
      // ProjectInstaller
      // 
      this.Installers.AddRange
       (new System.Configuration.Install.Installer[] {this.eventLogInstaller1} );
    }
    #endregion
  }
}

URL Remoting and Security Considerations

It is possible to set up your app on a server  (one not running .NET)  and have Internet Explorer  (not a Windows app)  navigate to the URL for the server,  download the app,  and run it.    (Kalani, example, pages 903-904)

This sort of thing obviously raises security concerns.

Such downloaded modules are stored in the download cache,  which,  though not physically attached to the GAC,  can be viewed by Windows Explorer  (using  shfusion.dll)  as if it were.   Since the download cache remembers the source of its modules,  the system can assign code access security settings to them.   Such modules can be allowed to run,  or can be prevented from running,  by modifying the security settings for the machine.

Some DLLs on the local machine are willing to operate even though the code invoking them is not fully trusted,  because they have the  AllowPartiallyTrustedCallers  attribute set.

But not all local DLLs have this setting:  specifically,  System.Data.SqlCLient.SqlConnection  does not. If you want to run code from foreign sources that use such DLLs,  you will have to modify the security settings on your machine.   You do this with the .NET Framework Configuration Tool.   You can revise the settings for the machine or for a user,  and for a code source  (such an Intranet or the entire Internet)  or for an individual assembly.   You may also assign levels of trust to particular trusted Internet sites.   You can assign one of four levels of trust:  None,  Internet,  Local Intranet,  and Full Trust.   (Kalani, pp. 911-914)

Methods of Deployment

Removable media  (floppies,  CDs,  DVDs)  may be used for deployment.   They must have their files packaged to fit,  using the "Cabinet Files" option.

Deployment may also be done over a network.   You do not have to create CAB files if you do this.   You put the compiled setup package in a shared network folder.

Deployment may also be web-based.   So far as I can tell,  this is the same as network deployment,  except that the compiled setup package goes into a virtual directory on a Web server.

Administrative Installation       (Kalani,  pages 917-918)

You do this when you're deploying to a large number of users.   You do two things:

This point is to cut down on installation time,  and to insure that all installations are the same.   Advantages:

Windows Logo Program Requirements

I think this is all guff,  and I would be amazed if you get a question about any of it.

Summary

This has been presented in far too much detail.   Here is what you should know:

The value of chapters like this is that they're not as hard as they look,  and if you put in a little effort here,  it will bring up your grade and defend it against questions about details in,  say,  Controls,  that you have  no idea  about.

The  (parenthesized references)  in the above list are explained  here.
Here are the relevant questions from the two tests at the end of the "short Kalani"  book:  

    Test 1:  questions  47  (page 379;  answer:  page 397),  50,  52,  53.

    Test 2:  questions  47  (page 429;  answer:  page 447),  58,  59,  60.

(Some of these questions may duplicate those in long Kalani.   Both texts are listed here.)

Last  revised  Dec. 10,  2004