Posts in Category "tools"

Upgrade Codes, Product Codes, and Silent AIR Application Uninstall

Those who sign up for the Adobe AIR redistribution license have had the ability to silently install and uninstall AIR applications since the AIR 1.0 release. Unfortunately, the silent uninstall support on Windows is a bit rough. I’ve included below a link to a utility I wrote that eases the problem a bit. But first, a little background on the issue.

When an AIR application is installed on Windows, it’s installed via Windows Installer. This is a good thing; it allows leveraging all the capabilities of Windows Installer. For example, silently uninstalling an AIR application on Windows can be accomplished directly via the “msiexec” utility that is part of Windows. All you need to provide to msiexec is the product code of the application.

AIR applications don’t inherently contain product codes—they’re specific to Windows Installer—and you won’t, for example, find one in your application descriptor. Furthermore, Windows Installer requires that product codes change—even for the same application—under certain circumstances. In order to play it safe, AIR generates a unique product code for each version of your application. This, in turn, means you need to know the product code associated with the specific installed version of the application in order to uninstall it. This is a hassle.

Fortunately, Windows Installer also associates an upgrade code with each application. An upgrade code is basically an application identifier that never changes and, given an upgrade code, you can look up the corresponding product code. The mapping from upgrade code to product code is stored in the registry at application install time. Like product codes, AIR generates an upgrade code for your application. Unlike product codes, upgrade codes are the same across all versions of your application and are easily determined via the OSID application that comes with the redistribution support.

Unfortunately, the only way to look up that mapping is via the MsiEnumRelatedProducts() system call, and the msiexec utility won’t do it for you. (Theoretically you can look this mapping up yourself in the registry, but that turns out to be fairly complicated, and I’m not sure it can be done reliably.)

How much of a problem this is depends on the uninstall technology you’re using, whether or not it can perform this lookup for you, and whether or not you’re in a position to write a few lines of C code to perform the lookup. For anyone out of luck on all counts—or just curious—I’ve written a small utility called “msiu2p”. You can download msiu2p here. (The zip package includes the executable and the source.)

Here’s an example:

c:\ msiu2p {8DA920D5-C41C-42E0-BF31-87BA49984EE4}
{A2BCA9F1-566C-4805-97D1-7FDC93386723}
c:\

Of course this isn’t useful just for AIR applications, either: It’s a handy complement to msiexec for any application using Windows Installer.

We plan to improve AIR’s intrinsic support for this kind of thing in an upcoming release. In the meantime, I hope this utility will help fill the gap for those who need it.

AIR, ADT, Java, and Proxies

AIR applications, when accessing content via HTTP or HTTPS, always do so via the system proxy settings. On Windows that means they use the same settings as Internet Explorer. On Mac OS, those are the same settings as used by Safari. It’s hard to use a machine if the system proxy settings aren’t correct, so users typically have this set up early on and then don’t have to think twice about it—it just works.

The folks over at Sun who had to implement Java for Windows had other ideas, and gave Java its own proxy settings. If you have to explicitly enter your proxy settings for your operating system, you most likely will have to separately enter those settings to any JRE you’ve installed. In current versions of Java, these settings are accessed via the Java Control Panel.

ADT is, as explained earlier, written in Java. It also generally has to access the network when signing in order to obtain a secure timestamp; that server is accessed via an HTTP request. The end result? Developers often find that AIR applications can access the network just fine during development, but when it comes time to create an AIR file, packaging fails because a timestamp can’t be created.

If you run into this situation, be sure to check your Java proxy settings—and make sure you’re checking for the same JRE that ADT is using. (If you have more than one JRE, they may not be sharing proxy settings.) I do not recommend disabling timestamping, for reasons I’ll explain later.

Tools: Procmon

Back to developer tools.

In the platform-specific category, Procmon is my favorite on Windows. It captures registry, file system, and process events for any process. You can use it to debug your own programs and just about anyone else’s, too. It’s originally from Sysinternals, now provided by Microsoft directly.

For example, I once used it to debug some custom build steps in Visual Studio that weren’t behaving. Using Procmon, I was able to determine which files Visual Studio was checking timestamps on. It turned out an incorrectly entered output list was causing Visual Studio to look for files that didn’t exist and causing the step to run every time. Sure, maybe I’d have seen that if I stared at the output list long enough. But it was easy to spot in Procmon.

A few features I’ve found most useful:

Filtering by process name. You can filter events in about a zillion ways, but the most useful is to exclude based on process name. Find an event from a process you don’t care about, right-click, and select Exclude. Procmon remembers these settings between invocations, so it’s easy to reduce clutter by excluding Explorer.exe, etc.

Filtering by event type. In the toolbar you’ll find three buttons to show/hide file events, registry events, and process events. Again, eliminates a lot of clutter if you know which type of event you’re looking for.

Saving log files. You can save your captured event logs. I encourage our QE team to use this feature and attach the log files to bug reports. I can open the logs back up in Procmon and get a good idea of what happened.

You’ll also be surprised at all the stuff that Procmon captures going on under the covers. For example, you can see all of the work your application does before it starts executing your code. Sometimes I’m amazed applications ever finish starting!

Tools: Araxis Merge

Computers are tools. Fancy, general-purpose, expensive, complicated tools, but tools nonetheless.

Most applications are tools, too. Programmers tend to think of applications used to write or debug other applications as tools and everything else as, well, something else–but this is just perspective. To an end user, an application is a tool that helps them write a book, perform research, calculate (the original purpose of the computer!), and so on.

Ironically, most programmers seem rather reluctant to invest the time in assembling a good set of tools. Can you imagine a carpenter who still hadn’t taken the time to learn how a chop saw worked?

In the spirit of someone writing tools in order to help others write tools, then, I thought I’d post occasionally about some of the tools that I use.

First up: Araxis Merge. An awesome GUI diff and merge tool for both files and directories. Can be integrated with various source control systems; I use it to perform all of my non-trivial integrates in Perforce. Its three-way merge algorithm is great, and it will show intra-line diffs, which are particularly handy when merging Visual Studio and XCode project files.

Bonus: Available on both Mac and Windows.