My blog has moved...

I have a new blog at http://www.geekswithblogs.net/rikoe which will carry my setup-related posts from now on. Ill probably post my recent entry on Resources and Data there soon.

See you there.

Resources and Data

After our company decided to use Windows Installer for all our installs, I held a presentation to the various project teams on Windows Installer technology. One of the most important principles I wanted to get across was the distinction between resources, application data and user data.

This distinction was first made clear to me by this blog from Rob. As I told Vagmi yesterday in a post on the WiX users list, it turned into a real discussion about what exactly the difference is, specifically between user and application data, and what the point is of making a distinction between the two.

So after Vagmi's excellent post about how to deal with application data, allow me my two cents worth about the topic...

1. Resources

As Rob points out resources are the physical building blocks of the application, typically the bits and pieces of your software program that you install. (Think of files, registry entries, shortcuts, virtual directories, databases etc.) In fact, according to his definition, which I've sort of made my own,

Setup is the process of getting the resources that make up a software program transferred from a source and configured on a target machine.

You'll notice that this definition mentions setup only as transferring resources, not any other kind of data - which brings me to the other kinds of data.

2. User Data

The "Designed for Windows XP" Application Specification refers to user data as "user-created data", which I think is a more apt description. I tend to think of it in terms of "everything that goes into the My Documents folder". Or in other words, everything that the user knowingly creates with the program.

User data, because it is created by the user, belongs to the user. Even though made by the software program you are installing, it is not part of the program. Because it is the user's data you have no right to remove it without his permission, or to install it for that matter. You can't install it because the user haven't created it.

So, in short, user data

• Should never be installed
• Should never be uninstalled

Installing user data to the My Documents folder, by the way, is another important design guideline to follow, not only because it's in the app spec, but because it makes sense. And it makes sense because:

• Every user has write permissions to his own My Documents folder. This makes life so much easier. For example, we've again had gazillions of permission problems recently with one of our products that was badly designed and stores it's user data in the Program Files folder.
• It's easily accessible.
• User's are familiar with My Documents. It gives them a common location to store and manage all their files and data. Tap into this - familiarity can be a good thing!
• It is easy to obtain the location of the My Documents folder programmatically, even if mapped to a different location.

(The "Designed for Windows XP" specification is a great resource for application design pointers, even if you aren't aiming towards the Windows XP Logo)

3. Application Data

Application data is where it gets tricky. It doesn't have to, but it can. Rob describes it as

the bits a program generates while its running,

which is correct, but perhaps not clear enough for people who want to be difficult (like the developers I tried to explain it to). It is data created for use by the application itself (as opposed to user data, which is for the user). Application data can be user-specific but not user-created. This is the important distinction. In fact, application data is more often than not about the user - information like recently saved files, or user preferences.

It is important to make the distinction that app data is to be used by the application itself, and never to be accessed directly by the user. But already the area becomes a bit grey: what about IE favourites? They are saved by the user, aren't they user data? Why then aren't they stored under My Documents? The way I've made it out for myself is: favourites are simply "things" or "places" to the users, the actual favourites "data" are stored in a location under the user's profile. They are never directly accessed by the user, or shouldn't be. The favourites are application data interpreted by IE (or Outlook, etc.) and presented to the user in a friendly manner, the same way as user preferences are.

So then, how does application data affect the setup? Well, they aren't resources, they're data, so we don't install them. This is where you need to put your foot down: many developers want the install to create the application data, but this is not good practice.

Example: One of our products has a service that requires a port number and a login name. This question currently gets asked in the install UI, but this is wrong. What if the user wants to change the port number or login? This should be configured from the application, not from the install. And if it's in the application, why should it be in the install in the first place? The application can simply check if the data exists on first run, and ask the user if it doesn't. What's more, then the user will know where to change it next time. The golden rule, then: do as much as possible in the application. Of course, things that need to be there before the application can run, like a user or virtual directory, must be set up by the install program.

About removing application data, this job often falls on the shoulders of the install program. Luckily Windows Installer provides the RemoveFile and RemoveRegistry tables. Even so, it can be a challenge to get this right, as Vagmi points out in his blog entry.

So in short, application data:

• should not be installed
• should be removed

Why should the install program remove application data? Well, it is important for a program to clean up after itself. If I uninstall a program from my machine, I don't want it to leave odds and ends lying around! Of course, if a program is well written, it will clean up most of its application data itself. For example, a program that creates a .tmp file to help in its processing should delete it after it has finished using it, even if it is stored in location the user doesn't know about. And yet so few programs perform these basic courtesies...

Where should application data be stored - ha, that's simple. In the Application Data folder of course! Every user has a (hidden) Application Data folder under his profile, and there is also a per computer one. But wait, there's also an Application Data folder under the Local Settings folder! Not quite so simple then... For a good discussion of storing application data for roaming vs. non-roaming and per-user vs. per-computer profiles, refer to the "Designed for Windows XP" Application Specification. It also discusses per-user registry entries, another important consideration with application data, and the cause of many a headache.

The most important part of this post was to be "What's the point?", but I've written WAY to much already. So I'll say what the point is in the next post...

And so it starts...

When I started working as a developer more than a year and a half ago, I never imagined I'd become a setup developer! But I have been working with installs now for quite a while, and with this blog I want to start documenting some of the things we've learnt, and investigate the technologies we use. (With "we" I mean me and my fellow partner in crime, Shelley - we are the "install people" at my company).