Deploying .NET Apps

Before you dig into the mechanics of deploying your VB .NET applications, it's important to first cover some of the concepts and advantages that .NET offers you over classic environments.

First, remember that all .NET applications emit metadata, which makes them self-describing. All the settings and deployment parameters are contained with the application itself, and there is no need to enter them in the registry or rely on other dependencies. This also means that each application is a completely standalone entity, and won't interfere at all with other applications. In fact, you can even have multiple versions of the same application deployed on one computer, and they won't interfere with each other!

Another benefit of self-describing applications is that they are very easy to deploy. You simply need to copy your files from one computer to the other. No complex installer routines are necessary.

Not only is getting your application to another computer easier, but there are now more options to do so as well. The quick and dirty way to deploy is to just use XCOPY, but you can also deploy over the Internet or by using the Microsoft Installer. Updating applications is also flexible, allowing you to update single components at a time via XCOPY or Internet.

In this chapter, you examine three ways to deploy your applications: via the Windows Installer, via CAB files, or via the Internet and Internet Explorer 5.5.

Windows Installer

The Windows Installer is an installation and configuration application that provides a standard method for deploying your applications. It allows you (or your users) to selectively install parts of your application and leave others out, or choose to install them at a later time. These installation files typically end in the .msi extension, and you've probably seen this standard interface in quite a few places. Figure 13.1 shows the Windows Installer in use when installing Microsoft Office.

If you've used the Windows Installer before, you'll know it offers you quite a few features for configuring your installation, thus reducing the time spent on deployment for the developers and end users. This is the Installer's raison d'etre (that's “reason for being” for those non-French speaking readers).

Visual Studio .NET provides a wizard allowing you to customize the way you deploy your application via the Windows Installer. Using VS .NET, you can very easily and quickly build a deployment solution without having to do anything other than clicking a few buttons.

Open a new or existing VB .NET project in VS .NET. Figure 13.2 shows an empty project created just for this exercise.

In the Solution Explorer, right-click on the solution and choose Add, New Project. In the Add New Project dialog box, choose Setup and Deployment Projects in the Project Types and Setup Wizard in the Templates, and give it an appropriate name. After you click the OK button, VS .NET will add another project to your solution, and display the File System window, shown in Figure 13.3.

The left pane shows what the file system on the installation machine will look like when deployed. Recall that because deployment involves only copying files, there are no options here for editing registry values or including dependencies. The right pane shows the items that will be installed in each folder (by default, it simply lists the same things as the left pane).

The Application Folder is where your main application files will be installed. This typically includes your .exe or .dll files, .resource files, and so on. In the properties window (lower right in Figure 13.2), you can configure where exactly this folder will be located on the user's machine. By default, it is c:Program Filesyour company nameyour app name. This is specified with the syntax [ProgramFilesFolder][Manufacturer][ProductName]. Typically, you'll want to leave this as is, to make it easier for your users. You can create subdirectories under this folder by right-clicking on the Application Folder and selecting Add, Folder.

The properties window has a few additional elements you can set. The first, AlwaysCreate, specifies that this folder should be created even if the folder is empty. The Condition property allows you to specify rules that will be enforced during installation. For example, specifying VersionNT>=500 means that the installation will occur only if the target machine is Windows 2000 or later. For more information on conditional phrasing, see the VS .NET documentation with the topic Deployment Conditions.

DefaultLocation, Description, DisplayName, and Name are all self-explanatory. Property provides users a way to override the paths of custom folders for your application. If you leave this property blank, users cannot change or rename the target folders during installation.

Finally, Transitive specifies whether the Condition property should be evaluated only upon first installation, or every time the installer is called. For example, you could use it to enable reconfiguring the application after it has been installed. Typically, you'll leave this property at False.

Next, the Global Assembly Cache Folder (GAC) specifies any custom assemblies that should be copied to the target computer's Global Assembly Cache. These assemblies would be loaded every time the CLR is started on the target machine, and thus would be available to many different applications. This folder has the same property options as the Application Folder.

User's Desktop contains, obviously, the items that will be installed to the target machine's desktop. These will normally include shortcuts to your application. User's Programs Menu likewise contains shortcuts to your application that will be placed in the Start Menu, Programs folder.

Additionally, if these four folders are not enough, you can right-click on File System on Target Machine, select Add Special Folder, and add any number of additional special folders to which you can deploy files. These include the Windows System folder, the Start menu, Fonts folder, and so on.

After you've configured your application properly, select Build from the Build menu, and your deployment package will be created with an .msi file extension. Browse to your application solution folder (c:Documents and SettingsuserMy DocumentsVisual Studio Projectsappname by default), and you'll see a new folder with the same name as your Deployment solution (Setup3, in this case). Inside this folder, you'll see Debug and Release folders, which contain debug and release versions of your installer. By default, your installer will have been placed in the Debug folder. Inside, you'll see the installer file (again, Setup3.msi in this case). Double-click on this, and you'll be greeted with the familiar Windows Installer application, shown in Figure 13.4.

All you need to do is distribute this file and you're done! An end user can now execute this file again for further options such as repairing installation or removing the application. A user can also go to the Add/Remove Programs Control panel to manipulate the program.

CAB Files

A CAB file is basically a compressed version of your application files. This allows you to distribute your application more easily, especially over the Internet.

Creating a CAB file for your application is an easy process. Just as you did to create a Windows Installer project, go to the File menu and select Add Project, New Project, and select Cab Project from the Add New Project window. The CAB project will appear in your Solution Explorer. Add the necessary files by right-clicking on the CAB solution, selecting Add, File. Anything you put in this solution will be compressed.

These CAB files can be distributed with your Windows Installer application, or via the Internet, as you'll see in the next section.

Internet Explorer

There are numerous ways to take advantage of the Internet for your applications. As you learned in Chapter 8, “Building Web Applications with VB .NET and ASP.NET,” one method is to use ASP.NET to build a fully functional application. Users can simply visit your Web site and execute your Web application. Chapter 9, “Building Web Services with VB .NET,” showed you how to build Web services, another way to distribute your application components via the Internet. Both of these methods often use assemblies to provide supporting resources to your application. The users never need to execute anything on their side other than Internet Explorer.

The CLR also allows your executable applications to be accessed over the Web with Internet Explorer 5.5 or later simply by typing the name of your application in the address bar—something that was not possible prior to .NET. For example, by typing http://www.yourserver.com/MyApp/MyApp.exe into your browser, the application will be instantiated and run on the client's machine. Figure 13.5 shows such a situation using the simple application we built earlier in this chapter.

Supporting files for your application (such as configuration or CAB files) must be located in the same directory as your .exe file for this method to work. These files will be downloaded by the client as necessary.