Compartilhar via

Componentizing Winamp – Pt 3

  • Artigo

Now that we have captured the file and registry changes on an XP-Pro system from installing Winamp Lite, our next step is to get this information ported to Component Designer.

In my case, the Ashampoo Uninstaller presents the data in two forms, one through UI that you can browse through Folder and Registry Nodes to see only the changed files/keys, this is very intuitive. The other method is to export the information to a text file.

I prefer the UI method because the presentation in the log is also a little cluttered.

Now that I’m ready to do some actual work with Component Designer, I open it side by side with the Uninstaller utility. I browse through the utility’s displayed list of files and at the same time I will browse to the same folder or files in CD, adding them as file resource dependencies for my new component.

The registry keys are done basically the same way, browse through the list in the utility then browse to the appropriate *branch* or specific key in CD and add those as new registry resources for your component. After I had completed adding all the branches that were tagged as having been modified by Winamp’s installer is when I realized the newbie mistake.

After adding all the reg keys, I was browsing the list in CD and saw references to “ITune” and “QuickTime”! Seems my system was ‘dirty’ and I had these other players installed, so when I added the Classes\cda branch it was listing all players under the key. I got lucky and the keys were obvious as to which ones needed to be removed from the component. But if it was an obscure class GUID reference instead, I’d never know that it didn’t belong and would have wound up on the runtimes!

The lesson learned here is to do this analysis on a clean system that you haven’t been using and abusing. If at all possible, try to install a clean copy of XP with the hotfixes installed, then install the utility and then just install your application and you’re practically guaranteed to have only metadata in your component that truly represents the resources required for your targeted application.

Anyways, adding the file resources took me about 2 or 3 minutes. The one issue I ran into is that there were two file resources with the same name: Winamp.ini. CD complained, and when I compared the actual INIs, they were different, and since both files would eventually need to reside in the same root Winamp file repository, I had to decorate the name of one of the files. So the Winamp.ini in .\program files\winamp remained as “Winamp.ini”. But the INI that resides in .\windows\system32 got renamed as “windows_system32_winamp.ini”.

Now, for the decorated file name, I had to go to that file resource in Component Designer, double click on the file entry here and you’ll see advanced properties. The “Target Name” shall remain Winamp.ini, but the “SOURCE NAME” entry needs to map to what Target Designer should look for in the Winamp repository. So change the “source name” to “windows_system32_ winamp.ini”.

This is cool, because now you can have many files of the same name living side by side in your repository by simply decorating them. When TD builds the runtime, it will RENAME “windows_system32_winamp.ini” to “Winamp.ini” when it bin places.
Now that you have the component’s file and registry resources filled out, time to build your repository. Using the file resources as your check list, create a folder called “Rep”, collect all those files and put them in the Rep folder. Don’t forget to decorate the correct version of the file that will conflict with the other!

To recap:
- Install your app on a clean system!
- Browse with CD to add the resources while you’re viewing the utility side by side.
- When you find that you have files of the same name, simply decorate the file’s name in the advanced properties and then decorate the file name before copying it into the Rep folder.
- That Rep folder will be your repository.

In Pt 4 we’ll discuss the advanced component properties and how to create a Package object and Repository object. If we have time, maybe we’ll also talk about static dependency analysis and converting those to component dependencies.

Hang in there, we’re over half way done, then we get to build a runtime and test this sucker! <grin>

It took me 8 hours to write this over the course of a day; music I listened to while I typed this ranged from Kajagoogoo to Social Distortion to Echo and the Bunnymen.

Ciao.

- Andy

Comments