Alternatives to Traditional Installers

---

The .NET Framework brings some additional flexibility to the setup story, compared with earlier software platforms. In particular, you should know about XCOPY deployment and no-touch deployment.

XCOPY Deployment

XCOPY is a command-prompt utility that’s built into Windows. Its job is simple: It takes a source directory structure and creates an exact duplicate of that structure elsewhere. XCOPY deployment need not actually use the XCOPY command. Rather, it refers to installing an application by making a copy of all the relevant files and folders on the target system, without doing anything else.

Previous generations of Microsoft applications were typically not good candidates for XCOPY deployment. That’s because they depended on registering components in the Windows Registry, which XCOPY cannot do. But with .NET, the picture is somewhat changed. The .NET Framework’s components contain their own metadata and thus do not depend on the Registry. That makes it possible to deploy some .NET applications by simply copying all of the files from a CD to your hard drive, or by unpacking a zip file.

For simple applications, this is the easiest deployment that you could possibly ask for. However, for more complex applications, it falls down. Here are some of the things that you can’t do in a purely XCOPY deployment:

• Create shortcuts

• Allow installing only part of an application

• Require assenting to a license

• Add assemblies to the Global Assembly Cache (GAC)

• Create or configure databases

• Add custom event logs

• Check whether .NET is installed

• Present a custom user interface for the setup

• Uninstall via the Add/Remove Programs applet

For simple utilities or internal-use applications, you may find XCOPY deployment to be an attractive choice. Most real-world projects will run into at least one snag that makes a pure XCOPY deployment difficult to implement.

No-Touch Deployment

The .NET Framework also supports a new means of deployment called no-touch deployment. With no-touch deployment, instead of building a setup program you drop your application and its supporting libraries (EXE and DLL files) on a web server. Then you provide your users with a URL to the main application file.

Assuming that users have Internet Explorer 5.01 or later and the .NET Framework on their computer, when they go to the specified URL, the code will be downloaded to their computer. Whenever they need code in a different library, that too will be downloaded. These downloaded files are stored in a special cache. When users launch the application a second time, their computer will check the original URL for an updated version; if there are no updates, the cached copy will be used instead.

No-touch deployment is attractive for some scenarios. In particular, if you’re constantly updating your application, it’s easier to update a single copy on the web server than it is to have every user run a new setup. Yet there are some drawbacks to no-touch deployment as well. For starters, unless you build a special loader stub application for the client, the application will run in the Internet security zone, which prohibits many common actions (such as saving files). You also can’t deliver nonexecutable files this way, install services or local databases, register COM+ components, or satisfy other advanced scenarios.

Note

For more information on no-touch deployment and other deployment issues, you can download a copy of “Deploying .NET Framework-Based Applications,” a product of the Microsoft Patterns & Practices group, from www.microsoft.com/downloads/details.aspx?FamilyId=5B7C6E2DD03F-4B19-9025-6B87E6AE0DA6&displaylang=en.

TECHNOLOGY TRAP: Is That All There Is?

You’ve been with me for almost 300 pages now, and you’ve learned about dozens of things, large and small, that separate coders from developers. Now you know it all, right?

In a word, no.

I’ve been developing software for upward of a quarter-century now, and I’ve learned (I hope) a thing or two in that time. But I certainly haven’t learned everything about developing software. Although I’ve tried to be comprehensive in this book, I’ve inevitably missed some important topic. Perhaps you’ll be the one to ship a new category-defining product next year, creating the need for a chapter that I haven’t even envisioned yet.

If there’s one thing that distinguishes good developers from the rest of the pack, it’s an attitude toward learning. Good developers just don’t stop learning. There’s always some new part of the software universe to explore, some new language to learn, or some new tool to test-drive. As you hone your own development skills, I urge you to make use of the resources of the Internet to continue learning and exploring.

---