Installshield debugging on a remote PC [SOLUTION]

This is the issue that prompted my starting this blog.  And as stated above, it may end up being the only post I make, only time will tell.

Due to no fault of my own, my organization uses InstallShield (currently 2010 premier) for package development.  Occasionally, an issue will arise that requires that I debug an installation on test machine, that is, I'll encounter an issue that I cannot explain via logs or even in-line debugging and am forced to run the installation in debug mode on the offending device.

Today, I lost nearly seven hours of what could have been highly productive time simply trying to get the debug mode started on a target.  When I began, I realized that I hadn't actually run a remote debug session since we upgraded our projects to IS 2010.  I wasn't terribly worried about that, and proceeded in the fashion described in all of the Flexera documentation (one example of which can be found here.)  I followed the instructions to the letter and yet the debugger simply would not come up.

I will refrain from describing my efforts in the registry editor, double-checking my Setup.dbg file, running Filemon and Regmon to see if I could figure out why ISdbg.exe was not attaching to my installer.  Suffice to say, I spent a ridiculous amount of time trying every command-line permutation, moving my installer source all over the filesystem, trying to run it off the network, and rubbing my temples until they turned into shiny red mirrors.

Finally I keyed in on one specific line in the various troubleshooting docs I'd been finding online and in the help:

Note that if your installation, script, and debug files are all in their original location on the development system, you do not need to specify the path to the debug file—use the following: setup.exe /d

I was at that troubleshooting stage where you stop checking if an idea is dumb, and so I changed the filesystem on the target so that I could place my installer source in the exact same location that it lived on my development machine.  My development directory lives on my D: drive, so that required changing the drive letter of the CD on the target, and creating a R/W filesystem on D: (this was a VM, so it wasn't terribly hard; you could probably do this with a mapped network drive or a USB stick, etc.)  

I created all the subfolders to match my development system, then copied the entirety of the installer source to the target system.  I opened a command prompt and navigated to the release image in the source, then ran the installer with the  "/d" switch:

D:\ISDev\Trunk\ProjectXInstaller\Main\Full Installer\DiskImages\DISK1>projectx_setup.exe /d

Success.  Frustrating, infuriating, teeth-grinding success.

It has taken me so long to get the damn debugger up that I only have a vague idea of what I set out to test, I reset the VM as part of the troubleshooting so I need to reproduce the issue all over again, it will probably take me another hour to get to where I should've been at 9:30 this morning.  Anticipating that something like this will happen to me again shortly after I've forgotten how I solved it this time, I decided to take a breather to make this post.  Hopefully someone else will find this while debating whether a new career in the custodial arts would be better than working with InstallShield and can avoid the horror that was my day.  

At least it's Friday.  After I make up all the time I wasted on this tomorrow, I'll still have Sunday to wind down...

Inaugural post

I have a long and storied history of starting blogs, making one or two posts, and never coming back.  So let me make it abundantly clear that I may do the same thing here.

The goal of this blog is simply to give me a place to record my occasional victories working in the fields of build and packaging management.  I've discovered that this is one of the most challenging software disciplines, and I suspect that this is due to the ratios involved.  One build or packaging manager can support a development team of thirty or more, which right there means the ratio of general devs to those with real build/package experience is 30:1.  Further, there are many general devs who are pressed into build/package management and treat it as a peripheral task, and never become specialized in the field.  Finally, the very few of us who have been immersed in one or both of these disciplines for any length of time are (in my experience) incredibly pressed for time, so the number of useful resources on the interwebs is almost non-existent. 

So anyway -- I may just have these first two posts, or I may return again someday when I've lost an entire day to something which should've been dead simple had the tools we use been designed correctly.  If anything here is of assistance to you, I'm happy to have helped.