Chapter 21
7.Right-click the Application Folder node in the Designer (left pane) and select Add Project Output. The form will look like Figure 21-11.
8.Next, select “Primary output” from the Add Project Output Group form and click OK.
Figure 21-11
9.Now, right-click Primary output from Prerequisite, which you just added. From the context menu, select Create a Shortcut to Primary Output from Prerequisite. Rename the shortcut Prerequisite. Right-click the newly created shortcut and select Cut from the context menu. On the left pane, right-click User’s Program Menu and click Paste.
10.Save and build the Installer project.
11.Right-click the Installer project in the Solution Explorer and select Install. A Windows Installer will be loaded. This is the Setup project you have just created. Remember the shortcut you added to the user’s program menu. Take a peek at your menu, and you will see the shortcut.
How It Works
When you created the setup application, Visual Studio created a Windows Installer application. Changes you made, such as adding the ClickOnce program to the project, were included in the Installer database file.
In this example, you added one executable. It is also possible to add many other types of files including text files, help files, and other assemblies.
When you built the project, two files were created:
The msi file
An installation loader named setup.exe
When you looked, you saw these files in your <solution directory>\Installer\Release folder. You can find the path by selecting the Solution and looking at the Path property in the Properties
Deploying Your Application
window of Visual Studio. If the user did not have MDAC 2.8 or the correct version of the .NET Framework 2.0, it would have been downloaded from the vendor. You can change that under the settings where you added the dependency for MDAC 2.8.
User Interface Editor
Installations can be configured to meet almost any need with Visual Studio 2005. One of the easiest ways to make your installation look professional is to customize the interface the user sees during installation. A tool, User Interface Editor, is available to do just this.
With the User Interface Editor, you can configure the installation to do just about anything you want. You can add prebuilt dialog boxes such as a license agreement. Also, a number of customizable dialog boxes are available. You can even add a custom dialog box to ensure that a valid serial number is entered during installation.
In the next Try It Out, you will customize the installation of a setup application. We will show you some of the options, but know that almost every aspect of the installation is customizable.
Try It Out |
Customizing the User Interface |
1.Open Visual Studio and create a New Setup Project. Name the project UserInterface.
2.Now, select View Editor User Interface from the menu.
3.The editor will open as shown in Figure 21-12.
Figure 21-12
4.You will see two main items. Install and Administrative Install both have customizable interfaces. The administrative install is for a special type of installation that we will not explain in detail; it is used when an administrator installs an application image to a network share.
5.Under the Install node at the top, right-click Start and choose Add Dialog from the context menu. (See Figure 21-13.)
Figure 21-13
6.Select the License Agreement dialog box and click OK. By default, the dialog box will be added as the last dialog box under the Start node. You will make the dialog the second window the user will see by moving it up the tree node. Right-click the License Agreement dialog and choose Move Up until it is the second dialog box. Your project will look similar to Figure 21-14.
7.This is where you would normally add a license agreement file using the LicenseFile property. The only requirement is that is it must be in Rich Text Format (RTF). For this example, you will leave this property blank.
8.Next, add a Customer Information dialog box and make it the third step under the Start process. Change the SerialNumberTemplate property to %%-###-%%% and the ShowSerialNumber
to True.
9.That is all it takes. Just build the application and install. You will see the license agreement dialog box as the second screen of the installation. The third step is the customer information screen.
10.The third step is the customer information screen. Enter 77-000-777 for the serial number. See Figure 21-15.
11.Now, complete the installation by clicking Next through the rest of the steps.
Deploying Your Application
Figure 21-14
Figure 21-15
Chapter 21
How It Works
Wow. How easy was that? You customized the installation package with just a few clicks of the mouse. Visual Studio made this easy. As you saw, you can control the installation interface.
The second step of the installation was the license agreement you added. You were forced to agree to install the application. Visual Studio added the dialog boxes in the order you chose.
The third dialog was the customer information screen. Without a valid serial number, the installation would cancel. We created a valid serial number based on the SerialNumberTemplate property you changed to %%-###-%%%. The % character signifies that a required digit is included in the algorithm, and the # character is entered for digits that are not included. The serial number algorithm summed all required digits and then divided by 7. If the remainder was 0, the serial number entered passed validation. So, the first two and the last three digits were added together for a total of 35. Then 35 was divided by 7 for a remainder of 0, and you were allowed to install the application.
Deploying Different Solutions
Deploying applications is actually a large and complex task, made easier by various tools. But if you consider, for a moment, a large suite of applications, something like Microsoft Office, you will notice that there can be a vast number of files. All these files require explicit locations or Registry entries. They all tie together to make the application work. As well as being a large installation, there can also be many other complexities, such as database creation: What happens if the database exists? What happens with the data that is already there? This kind of activity, commonly referred to as migration, could potentially mean a lot of work for an installation expert.
Having multiple application types can also make an installation complex, and detailed knowledge of the different applications is required for a successful installation. The following section discusses some items regarding the different deployment scenarios surrounding the different types of applications that can be created with Visual Studio 2005.
Private Assemblies
Private assemblies are installed in a directory named bin located under the application directory. These files are private to the application. There are a few benefits in doing this:
No versioning is required, as long as it is the same version as the one with which the application was built.
The private assembly is not a shared assembly, and therefore it cannot be updated by another application (at least it is not meant to be).
You can manually replace the assembly as long as it is the same version.
It enables XCOPY deployment (the ability simply to copy and paste files to a location and have it work).
You can make changes to the assembly, and if two different applications use it, you could update one independently from the other.
Deploying Your Application
There is no configuration or signing (see next section) to do. It just works.
It is great for small utility Assemblies and/or application-specific code. Private assemblies have the following negatives:
When you have multiple applications using one assembly, you have to deploy the assembly to the bin directory of each application.
You would normally have to include the assembly in each setup project where it is used.
Versioning is not enforced as it is in a shared assembly.
It is not strongly named, which means someone could spoof your assembly.
Spoofing an assembly is when someone creates an assembly that looks identical to yours and replaces yours with the spoof copy. This spoof copy could do malicious things.
Shared Assemblies
Shared assemblies are actually more stable than private assemblies are, and they have a thorough approach to assembly deployment. A shared assembly can also behave like a private assembly, so all the benefits of that approach apply here too. The traditional shared assembly is different because of the extra work you need to do and the extra capabilities it then gains.
A shared assembly is like going back in time. In Windows 3.1, the main deployment location for these kinds of DLLs was the Windows\System directory. Then you were advised to have these files in the local application path, because it made for easier installation and uninstallation. Today, the System directory concept returns in a new guise named the Global Assembly Cache (GAC). However, the strong naming of assemblies is a definite step up.
To install a shared assembly, you have to add the file to a new folder named Global Assembly Cache. By default, this folder is not visible in the three default folders that are listed. To add the GAC folder you must right-click the node named File System on Target Machine and select Add Special Folder Global Assembly Cache.
Note that any project type can use a shared assembly, including a Web application.
Following is a list of the main benefits of a shared assembly:
It is signed and cannot be spoofed.
It has strong versioning support and configuration options.
It is stored in one central location and does not need to be copied to the bin directory of every application that uses it.
You can have many different versions running side by side.
Chapter 21
Shared assemblies have the following negatives:
You have to sign the assembly.
You have to be careful not to break compatibility with existing applications, or else you have to configure the different versions.
Configuration can be a nightmare depending on the requirements.
Deploying Desktop Applications
In the second project, you created a setup for a desktop application. All that you installed was the one executable. It had no dependencies other than the .NET Framework, which is always required. In a more complete application, you may have various assemblies, WinForm controls, or other files that you created for the application. Installing a private assembly with the Setup project means that you include the file by adding it to the setup application.
Deploying Web Applications
A Web application, when using private assemblies, can be simple to deploy. You can use the Visual Studio 2005 Web Application setup project to create a simple Web setup. The setup creates a virtual directory and copies the files you specify to the physical directory location.
You do not need to deploy the Visual Basic code files. These are compiled into an assembly in the bin directory. Only aspx, ascx, js, css, and other HTML files or scripting files are required.
Deploying XML Web Services
A Web Service is deployed in much the same way as a Web application is deployed. It also has a virtual directory. The files that it requires are somewhat different, though. You need to deploy the asmx and discovery files together with the assembly.
Useful Tools
There are a few tools that either come with .NET or are in Windows already for you to use. This section briefly points to these tools. When creating an installation, you also need to test it by installing it on various machines. Sometimes, when things do not go according to plan, you may need to do some or all of the activities by hand to see which one was the cause of the problem. As an example, perhaps you suspect that the ASPNET_WP.dll process has become unstable or broken in some fashion and it has affected the installation. In this scenario, you may wish to restart IIS before you run the install. In a similar vein, perhaps an assembly that was supposed to be registered in the GAC as a shared assembly cannot be found by the client, and then you may want to register it manually to check whether there was a problem with the registration. The following list briefly describes the tools you may need to use:
ASPNET_RegIIS: The aspnet_regiis.exe command line tool can be found in the
<sysdir>\Microsoft.NET\ Framework\<version> directory. This tool makes it an easy task to reinstall various aspects of the ASP.NET runtime.
Deploying Your Application
IISReset: IISReset simply restarts IIS without requiring you to open the IIS management console. Simply open a DOS prompt and type IISReset, and it will immediately restart IIS.
ILDasm: If you wish to inspect the metadata of an assembly, ILDASM is the tool for the job. With the tool, you can inspect everything from the Namespaces to the version. Start ILDasm by typing ILDasm at a Visual Studio command prompt.
GACUtil: This is a Visual Studio command line tool for registering/unregistering assemblies from the Global Assembly Cache. The /I option is for registering the assembly, and the /u option is for unregistering.
RegAsm: This Visual Studio command line utility is used for creating the necessary Component Object Model (COM) information from an assembly. This is used when you need to expose an assembly for COM Interop. The regasm tool includes switches for registering/unregistering type libraries.
InstallUtil: This is a Visual Studio command line tool for executing the Installer classes within an assembly. This can execute the InstallerHelper sample you did earlier in this chapter.
MageUI (Manifest Generation and Editing Tool): This is a graphical tool for generating, editing, and signing the application and deployment manifest for ClickOnce applications. Run MageUI from a Visual Studio command prompt to start the tool. A command line tool is available if you prefer to not have the user interface. Mage.exe is the command line version of the tool.
Summar y
Well, we hope you enjoyed looking at some general aspects of deployment. In the first section of this chapter, you were introduced to some terminology, and then you saw how to create a ClickOnce Application and a simple Setup application inside Visual Studio. You also learned the positives and negatives of private versus shared assemblies. Ultimately, we hope you learned that there is potentially a lot to learn in this area, from getting to know more about the features of the Windows Installer templates to learning how to do more with ClickOnce deployment.
Now that you have finished this chapter, you should know how to:
Create a ClickOnce deployment application
Create a Visual Studio 2005 setup application
Use general deployment terms such as XCOPY, shared versus private assemblies
Edit the installer user interface
Exercises
Exercise 1
Create a setup project for Notepad and install the program. You should be able to find the notepad.exe file in your Windows System directory. Hint: You will need to add the file to a setup project. Have the
Chapter 21
setup application add a shortcut to the Start menu. Deploy the notepad.exe file to the Program Files directory. For extra credit, change the Manufacturer property of the project and change it from Default Company Name to Wrox. Also, change the Author property to your name.
Exercise 2
Using the setup application created in Exercise 1, add a splash screen dialog box that is displayed first during the installation. We have included a bitmap in the code for the book named Wrox_Logo.bmp. This bitmap is the correct size, 480 _ 320, and you can use this image for the dialog box. Hint: You have to add the image you use to the setup application before you can add it to the splash dialog box.
22
Building Mobile Applications
Mobile devices — more specifically, personal digital assistants (PDAs) — are being shipped to more and more people around the world. A market once owned by Palm’s Operating System is now a market full of devices running Microsoft Windows CE. According to a report published November 12, 2004, by the Associated Press, Windows CE first took the top place over Palm in number of PDAs shipped in the third quarter 2004. Of the 2.8 million PDAs shipped worldwide, Windows CE was the operating system on 48.1 percent. The demand for applications to make PDAs and other smart devices valuable to companies is growing with the number of PDAs in use by corporations. As you build skills in Visual Studio 2005, know that building applications for smart devices is definitely a skill many employers are and will be looking for in their developers.
Designing mobile applications for Windows CE, Pocket PC 2003, and Smartphone 2003 devices is simplified using Visual Studio 2005. This chapter will focus on applications built for PDAs running Microsoft Windows Pocket PC operating system.
Understanding the Environment
If you have never used a PDA, it is a small version of a stripped-down PC. A typical Pocket PC from 2002 has 64 MB of internal memory and a 206-MHz processor. It weighs less than a pound and has a 3.5 inch screen that supports 240x320 pixels and 65K colors. Now, compare that to a desktop computer. A normal PC may have a spec sheet like this: 3 GHz processor, 120 GB hard drive, 512 MB RAM and a 19-inch monitor that supports 1600x1200 pixels and 32-bit color (over 4 billion colors). Another important difference is that the screen on a Pocket PC is tall, whereas a desktop monitor is wide. One more issue to consider is that when the battery dies, you lose all data and applications stored in memory. The user must add a storage device, such as a compact Flash card, to avoid having to reinstall applications when the battery loses power. Keep these differences in mind as you build applications for mobile devices.
Now that you know the basics of a PDA, I will try to outline what Visual Studio 2005 has for you to work with when you create mobile applications. To start, you have the .NET Compact Framework (CF). The best part of the CF is that it is a subset of the .NET Framework you know about from earlier chapters. Most of what you know is part of the CF, and this knowledge will
