Section 19.4. Windows Installer

19.4. Windows Installer

XCOPY deployment works well for many web sites. However, there are some situations where it falls short. For example, XCOPY does not automate the installation of assemblies into the GAC, nor does it make Registry edits. Further, if you need to install to multiple servers, such as a web farm, or have a precisely scripted and repeatable installation process, then XCOPY may get tedious and error-prone . For all of these scenarios, you need an installation tool with more robust capabilities. There are several third-party installation tools available, such as InstallShield, InstallAnywhere, and ActiveInstall.

Windows has its own installation technology, known as Windows Installer , which has been included with all the Windows operating systems starting with Windows 2000.

Windows Installer provides installation, removal, and management of applications. It also supports features such as automatic repair of existing installations, transactional operations (a set of operations performed by the installer can all be undone if installation does not complete successfully), installation on demand (application features are not installed until the first time a user tries to use that feature), and installation in locked-down environments if an administrator approves an installation package by means of group policy.

The Windows Installer is based on a database. Each application to be installed has a file associated with it, with an extension of .msi , which contains the data for that application, including rules for controlling the installation.

There are several ways of opening an .msi file. Double-clicking on the file will open the Windows Installer for that application. If the application is not currently installed on the machine, you will be presented with a series of dialog boxes for installing the application. Depending upon how the installation package was customized (described below), these dialogs will allow the user to select a target destination, offer installation for the current user or all users, present software license information, and so on.

If the application is already installed on the machine, you will be presented with a dialog box offering the choice to repair or remove the installation.

If you right-click on an .msi file in Windows Explorer, the context menu will include three relevant menu items: Install, Repair, and Uninstall. These options perform the same operations you might access by double-clicking on the file.

You can execute the Windows Installer from a command prompt. To install an application, use the following command:

 msiexec /i MyApp.msi 

To uninstall the app, use the following command:

 msiexec /x MyApp.msi 

To repair an installation, use this line:

 msiexec /f MyApp.msi 

Interestingly , msiexec.exe is one of the few command line tools provided by Microsoft that does not display a list of parameters when executed with the /? switch. However, executing the command with no command-line switches will bring up a dialog box with a list of all the command-line switches.


Probably the easiest way to run the Installer is to execute setup.exe , the Installer Bootstrapper which is created by VS2005 in a process that will be described below. Do so by double-clicking on the file in Windows Explorer.

The Windows Installer automatically logs installations and removals in the Application Log of the Event Viewer found in Control Panel Administrative Tools. Each entry in the log will have the MsiInstaller as the value for Source.

The Windows Installer is integrated into VS2005. You create installation packages for your application by adding one or more setup projects to the web application. By having more than one setup project as part of an application, you can easily deploy the same application with different configurations.

VS2005 uses MSBuild, the Microsoft build engine, to perform the builds that get packaged into the .msi files. You can create powerful and flexible MSBuild projects. MSBuild is also available outside VS2005, from the command line, with the MSBuild.exe utility. Going into all the detail of MSBuild is beyond the scope of this book.


To demonstrate using VS2005 to build deployment packages, you will first create a three-page web site called Deployment, with the pages named Default.aspx , FirstPage.aspx , and SecondPage.aspx . Each page will consist of two buttons to navigate to the other two pages. In addition, you will create a class file, Class1.cs in the App_Code directory, which will have a single static public method called GetTime that returns a string representing the current time.

All three content files, along with their associated code-behind files and the class file, are listed in Examples 19-1 through 19-7. (You might want to download these code examples from www.LibertyAssociates.com, since the code itself is not the focus of this section but rather how to deploy the code.)

Example 19-1. Default.aspx for Deployment
 <%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs"    Inherits="_Default" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server">     <title>Deployment Example</title> </head> <body>     <form id="form1" runat="server">     <div>       <h1>Deployment Example</h1>       <h2>Home Page</h2>        <asp:Label ID="lblTime" runat="server" />        <br />        <asp:Button ID="btn1stPage" runat="server"                    Text="Go To First Page"                    OnClick="btn1stPage_Click" />        <asp:Button ID="btn2ndPage" runat="server"                    Text="Go To Second Page"                    OnClick="btn2ndPage_Click" />     </div>     </form> </body> </html> 

Example 19-2. Default.aspx.cs for Deployment
 using System; using System.Data; using System.Configuration; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; public partial class _Default : System.Web.UI.Page {     protected void Page_Load(object sender, EventArgs e)     {        lblTime.Text = Class1.GetTime(  );     }    protected void btn1stPage_Click(object sender, EventArgs e)    {       Response.Redirect("FirstPage.aspx");    }    protected void btn2ndPage_Click(object sender, EventArgs e)    {       Response.Redirect("SecondPage.aspx");    } } 

Example 19-3. FirstPage.aspx for Deployment
 <%@ Page Language="C#" AutoEventWireup="true" CodeFile="FirstPage.aspx.cs"    Inherits="FirstPage" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server">     <title>Deployment Example</title> </head> <body>     <form id="form1" runat="server">     <div>       <h1>Deployment Example</h1>       <h2>First Page</h2>        <asp:Button ID="btnHomePage" runat="server"                    Text="Go To Home Page"                    OnClick="btnHomePage_Click" />        <asp:Button ID="btn2ndPage" runat="server"                    Text="Go To Second Page"                    OnClick="btn2ndPage_Click" />     </div>     </form> </body> </html> 

Example 19-4. FirstPage.aspx.cs for deployment
 using System; using System.Data; using System.Configuration; using System.Collections; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; public partial class FirstPage : System.Web.UI.Page {    protected void btnHomePage_Click(object sender, EventArgs e)    {       Response.Redirect("Default.aspx");    }    protected void btn2ndPage_Click(object sender, EventArgs e)    {       Response.Redirect("SecondPage.aspx");    } } 

Example 19-5. SecondPage.aspx for Deployment
 <%@ Page Language="C#" AutoEventWireup="true"    CodeFile="SecondPage.aspx.cs" Inherits="SecondPage" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server">     <title>Deployment Example</title> </head> <body>     <form id="form1" runat="server">     <div>       <h1>Deployment Example</h1>       <h2>Second Page</h2>        <asp:Button ID="btnHomePage" runat="server"                    Text="Go To Home Page"                    OnClick="btnHomePage_Click" />        <asp:Button ID="btn1stPage" runat="server"                    Text="Go To First Page"                    OnClick="btn1stPage_Click" />     </div>     </form> </body> </html> 

Example 19-6. SecondPage.aspx.cs for deployment
 using System; using System.Data; using System.Configuration; using System.Collections; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; public partial class SecondPage : System.Web.UI.Page {    protected void btnHomePage_Click(object sender, EventArgs e)    {       Response.Redirect("default.aspx");    }    protected void btn1stPage_Click(object sender, EventArgs e)    {       Response.Redirect("FirstPage.aspx");    } } 

Example 19-7. App_Code\Class1.cs for Deployment
 using System; using System.Data; using System.Configuration; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; public class Class1 {    public static string GetTime(  )    {       return DateTime.Now.ToLongTimeString(  );    } } 

19.4.1. Build Configurations

By default, web sites created in VS2005 are configured to enable debugging and to be run in debug mode within VS2005. If any unhandled errors occur, the user will automatically be brought into the debugger. The price for being in debug mode is reduced performance.

A web site can be configured to disable debugging. In this mode, all breakpoints will be ignored and any unhandled errors will result in an error page being displayed to the user. The non-debug (release) mode is more performant than debug mode and is typically used when a web application is deployed.

You can select debug or non-debug mode with an entry in the <compilation> element in web.config . (Configuration is covered in Chapter 18.) You can configure this by manually editing web.config or by running the Web Site Administration Tool.

To edit the file manually, set the debug attribute of the <compilation> tag to TRue or false as in the following code snippet:

 <compilation debug="true" /> 

To use the Web Site Administration Tool, click on the Website ASP.NET Configuration menu item. When the tool opens, click on the Application tab, then the "Configure debugging and tracing link. On that page, check or uncheck the "Enable debugging" checkbox. Doing so will automatically make the correct entry in web.config .

In versions of ASP.NET prior to 2.0, and still the case when creating .NET Windows applications (as distinct from ASP.NET applications), Visual Studio provides two default build configurations: Debug and Release. In VS2005 with ASP.NET, there is no longer a Release build configuration. (You can add your own build configurations, a topic beyond the scope of this book.)

Even if you have configured the web site to run in non-debug mode , the Active configuration will still be called Debug. This might cause some confusion, especially when building setup projects, as will be discussed shortly.


19.4.2. Adding a Setup Project with the Setup Wizard

You are now ready to add a project to the web site that will take advantage of the Setup Wizard to walk you through the steps of creating an installation package. This installation package will install a version of the application with the debug mode set to the value currently indicated in web.config , as described in the section above. For this example, verify that debug mode is set to true .

With the web site root directory highlighted in the Solution Explorer, click on the File Add New Project menu item. (This menu item is unavailable by right-clicking on the Solution Explorer.) From the tree view on the left, select Setup and Deployment under Other Project Types. From the list on the right, select Setup Wizard. Name the project Setup-Debug and leave the default location. The dialog box will look something like that shown in Figure 19-4.

By using the default location, the setup project will be located in its own folder under the root location for all your project files (set using Tools Options). You might want to consider changing the location of this setup project to be in a subdirectory of the project it is setting up.

The wizard will take you through five screens. The first is a splash screen. The second screen asks you to choose a Project Type. Select "Create a setup for a web application."

The third screen asks you to select the outputs from all the projects in the solution. Check the only checkbox available, next to "Content Files from c:\ websites \

Figure 19-4. Setup Wizard project dialog box

Deployment." (Your directory structure may be different from those shown here.) Click the Next button.

The next screen allows you to include other files, such as READMEs, of which there are none. The final screen displays a summary of all the settings for this setup project. Click Finish.

A project will be added to the Solution Explorer and the main design window will now show a File System editor for the setup project, similar to the screenshot shown in Figure 19-5.

Build the setup project by right-clicking on the project name in the Solution Explorer and selecting the Build menu item.

Build will build the application, taking all dependencies into account but not building any components that are up to date. In a large solution where current development work is only being done on one or two projects, it makes for a faster build process.

The Rebuild menu item first deletes all intermediary files and previous build outputs and then builds the entire app from scratch. It may take longer, but it is smart to do a Rebuild before testing the final build.

You can open the Output window to view a log of the build process by clicking on View Other Windows Output. At the end of the build process, it should say:

 Build: 2 succeeded or up-to-date, 0 failed, 0 skipped 

The number 2 refers to the two projects in this application, i.e., the web site and the setup project.

Figure 19-5. Setup project added to web site

Two files are created by this build process that actually need to be deployed: setup.exe and Setup-Debug.msi . Copying these files to the deployment target, (the server), and double-clicking on the setup file will cause the contents of the . msi file to be installed on the local machine.

The output files from the build process will be located in a directory called Setup-Debug (which is the name of the setup project) under the directory where the projects are stored, in this case in c:\VSProjects . Setup-Debug will contain a .vdproj file which contains information used by VS2005 to properly handle the project.

The Setup-Debug folder will contain two other subdirectories: Debug and Release . These folder names are a consequence of the warning in the previous section. The deployment output files, setup.exe and Setup-Debug.msi , will be contained in the folder called Debug because that is the name of the current active build configuration. Even if the web site is configured to run in non-debug mode, the output files will still be placed in a folder called Debug .

19.4.3. Adding a Setup Project Manually

You can create a setup project manually without using the setup wizard. This gets you to the same place as using the wizard, trading convenience for greater control.

You can manually or automatically create either debug or release versions by editing web.config prior to building the setup project.


To begin, repeat the process of clicking on the File Add New Project menu item. This time select the Web Setup Project template, and name the project Setup-Release , as this time youll create a non-debug (release) version.

Edit web.config to set the debug attribute of the <compilation> tag to false or open the Web Site Administration Tool, go to the Application page, click on the Configure Debugging and tracing, and uncheck Enable debugging.

You must manually add the output files to the setup project, so right-click on the project in Solution Explorer and select Add Project Output. Select Content Files from the list at the top of the dialog box, as shown in Figure 19-6.

Figure 19-6. Adding project output manually

You can select multiple outputs using standard Windows techniques with the Ctrl or Shift keys.


As soon as the output is added, any dependencies are detected and the class library is automatically included in the build.

The new project with that name will display in Solution Explorer with the primary outputs, similar to that shown in Figure 19-7.

19.4.4. Further Customizations

Whether the setup project came from the wizard or not, a number of customizations are available to you. Specifically, right-clicking on a setup project in Solution Explorer and selecting View or clicking on the View Editor menu item will bring up six different editor choices.

Figure 19-7. Adding output manually to a setup project

Clicking on any of these editors will display that editor for that project in the main pane. (When you first added a setup project, the File System editor is what you are looking at.)

19.4.4.1. File System

This editor, displayed in Figure 19-7, allows you to control where files are added to the end user's machine. The items in the leftmost pane are named folders on the target machine, such as the Web Application folder, the directory where the application is installed. Clicking on any of the named folders displays its contents in the right pane.

You created this example project using the Web Setup Project, for which the only named folder displayed on the left side is Web Application Folder. If you had instead based this on the more generic Setup Project, there would be, instead, three named folders: Application Folder, User's Desktop, and User's Program Menu.


Right-clicking on an item displays a context menu. Select Add to add a folder, a file, an assembly, or a project output. You can add shortcuts to the desktop or to the Start Programs menu by right-clicking on the appropriate item.

Before adding any files to a named folder, you must first set the AlwaysCreate property of that folder to true before building the setup project. To do so, click on the relevant named folder in the left pane, and set the AlwaysCreate property in the Properties window.


Use this editor to add shared assemblies to the GAC on the target machine. To do so, right-click on the root of the left pane, "File System on Target Machine" and select Add Special Folder. You will see a plethora of special folders, many of which should be familiar to you. Click on Global Assembly Cache Folder to add this to the left pane. Right-click on it and select Add Assembly... to add an assembly to the GAC. For an assembly to be added to the GAC, it must first have a strong name.

19.4.4.2. Registry

The Registry editor allows your setup program to make entries in the Registry of the target machine. The screen shot in Figure 19-8 shows a new key called TestValue inserted in HKEY_LOCAL_MACHINE\Software\<Manufacturer> , where <Manufacturer> will be replaced with the value of the Manufacturer property of the setup project. (It defaults to the organization entered when VS2005 was installed.)

Figure 19-8. Registry editor

You can add new keys to the Registry by right-clicking on a node in the left pane and selecting New Key. If you want to add a value to a key, right-click on that key and select New. Then select one of the following:

  • String Value

  • Environment String Value

  • Binary Value

  • DWORD Value

You can name the new value in the right pane or in the Properties window. The value is set in the Properties window.

19.4.4.3. File Types

The File Types editor allows you to associate file extensions with the application. If an associated file type has been double-clicked in Windows Explorer, the application will open with that file name passed in as an argument.

To add a file type to the project, right-click on "File Types on Target Machine" and select Add File Type. A default document type will appear with the &Open command below it. In the Properties window, change the name to something meaningful, say, MyApp Data File , and enter the extension in the Extensions property, say, abc , as shown in Figure 19-9.

Now if a file on the target machine with an extension of .abc , say SomeData.abc , has been double-clicked in Windows Explorer, the application will open with that file.

19.4.4.4. User Interface

The User Interface editor allows you to customize the dialog boxes that are displayed during the installation process. The process is divided into two categories: Install and Administrative Install. The first is for normal installation by users on their local machine, and the latter is for installation to a network for use by members of a workgroup.

Within each category, it is further divided into three phases: Start, Progress, and End. The default configuration looks like that shown in Figure 19-10.

Right-clicking on any item in the window and selecting the Add Dialog menu item brings up a selection of standard dialog boxes which can be added and further customized, such as dialogs with radio buttons, checkboxes, or text boxes, a customer information screen, a splash screen, a license agreement, and so on.

Again, since this example is based on a Web Setup Project, the middle node under Start is Installation Address. If you had based the project on Setup Project, those nodes would be Installation Folder.


Figure 19-9. File Types editor

Figure 19-10. UI editor

Any dialog box added this way will have properties for text files or bitmaps to display, executables to run, and so on.

19.4.4.5. Custom Actions

The Custom Actions editor displays the four phases of the installation process: Install, Commit, Rollback, and Uninstall. You can assign an executable or script file to execute at the conclusion of any of these phases.

19.4.4.6. Launch Conditions

The Launch Conditions editor allows you to create conditional installs . For example, you can specify that a certain version of Windows be installed, a certain file is present, or a certain Registry entry has the correct value.

By default, Web Setup Projects verify that IIS has been installed with a version greater than or equal to 4.

19.4.5. Deploying the Web Site

To deploy the web site created by building a setup project, copy the two output files, setup.exe and .msi , to the target machine and double-click on setup.exe in Windows Explorer. The installation program will run, opening up the Setup Wizard, as shown in Figure 19-11.

Figure 19-11. Setup Wizardopening dialog box

Clicking on the Next button will bring up the dialog box shown in Figure 19-12. All the web sites available on that machine will be listed in the Site drop-down. You can enter the name of the virtual directory you wish to use.

Clicking on the Disk Cost button will bring up a dialog box, shown in Figure 19-13, which details the drive space required and available on the local machine.

After looking at the drive space, click the Next button on the setup wizard dialog box to go to a confirmation page. Click Next one more time to start the installation.

Assuming that the installation succeeds, you will see the new virtual directory created under Default Web Site in Computer Management , as shown in Figure 19-14. (See Chapter 18 for a description of using Computer Management.)

You can then run the web site by opening a browser and navigating to the new URL, with a web address similar to the following:

 localhost/setup-debug/default.aspx 

Figure 19-12. Selecting an installation address

Figure 19-13. Disk space availability dialog box

Figure 19-14. New virtual directory created



Programming ASP. NET
Programming ASP.NET 3.5
ISBN: 0596529562
EAN: 2147483647
Year: 2003
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net