I'm busy with creating a new installation.
I'm using a basic msi project with some installscript code.
At this moment, I'm implementing some custom 'things' that needs to be ran during maintenance mode.
I have the following situation:
I install my product(initial installation)...
Now it is possible to debug my project from within installshield.
When I change anything in the code and run debug again(without rebuilding)... I see the lines I've added within the debug window but it seems that something is not in sync with the new code... the code that is executed when you step through it, is not the line that you really see within the debug window.
My question: how can I change some (maintenance)code and debug this new code without reinstalling the product everytime?
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Debug maintenance
Started by
Christoph
, Feb 06 2007 09:30
3 replies to this topic
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 06 February 2007 - 18:41
You can't (reliably).
Stefan Krüger
InstallSite.org twitter facebook
Christoph
-
- Full Members
- 81 posts
Posted 07 February 2007 - 08:57
Stefan,
what is actually the reason why this is not possible?
Has it something to do with the cached database?
I don't understand it.
I do an initial install of my product from out of folderA.
The builded project within the release folder of my development folder is in sync with the project in folderA. When I start to debug(with the commando 'setup.exe /v"ISSCRIPTDEBUG=1 ISSCRIPTDEBUGPATH=\"<path to setup.dbg>", the debugger starts and I'm running in maintenance mode.
OK.
When I now change something in the installscript code and compile(only compile) so that my setup.dbg file is updated, I run the debugger again.
I see the added line within the debugger but the debugger seems to ignore it?!!?
Can someone give me an explanation what the reason is for this behaviour?
what is actually the reason why this is not possible?
Has it something to do with the cached database?
I don't understand it.
I do an initial install of my product from out of folderA.
The builded project within the release folder of my development folder is in sync with the project in folderA. When I start to debug(with the commando 'setup.exe /v"ISSCRIPTDEBUG=1 ISSCRIPTDEBUGPATH=\"<path to setup.dbg>", the debugger starts and I'm running in maintenance mode.
OK.
When I now change something in the installscript code and compile(only compile) so that my setup.dbg file is updated, I run the debugger again.
I see the added line within the debugger but the debugger seems to ignore it?!!?
Can someone give me an explanation what the reason is for this behaviour?
Zweitze
-
- Full Members
- 522 posts
Posted 07 February 2007 - 13:59
Hey Christoph, long time no see...
Setup.dbg does not contain the actual scripts, it rather contains some instructions for the debugger, eg. locations of variables, names of functions etc.
The scripts themselves are stored somewhere in the MSI - indeed you can run scripts without passing the path to a Setup.dbg on the command-line.
After a completed installation the MSI is cached, and will be reused. You can update the cached MSI, but the only official method is patching.
Patching is time-consuming, you need to create a patch, and to do so you need to have the old MSI around, and wait for the patch to be created. This is not feasible for debugging purposes, 'change this and see what happens'.
You could try to reverse engineer the storage of InstallScripts. Create two builds of your project with a minimal script change, then compare the MSIs using MSIDIFF.VBS (in Platform SDK). If you find differences, and you are convinced how InstallShield stores the script files, you can write a small program that:
- Retrieves the scripts from the last built MSI
- Retrieves the product code from that MSI too
- Uses MsiQueryProductInformation (?! or something like that) to ask for the cached copy of the product
- Updates the cached copy
Running that program is much easier than creating and installing patches.
When using this method, keep in mind that you may not have covered all differences from InstallScript. Or, when this does go wrong, reevaluate the differences again.
Setup.dbg does not contain the actual scripts, it rather contains some instructions for the debugger, eg. locations of variables, names of functions etc.
The scripts themselves are stored somewhere in the MSI - indeed you can run scripts without passing the path to a Setup.dbg on the command-line.
After a completed installation the MSI is cached, and will be reused. You can update the cached MSI, but the only official method is patching.
Patching is time-consuming, you need to create a patch, and to do so you need to have the old MSI around, and wait for the patch to be created. This is not feasible for debugging purposes, 'change this and see what happens'.
You could try to reverse engineer the storage of InstallScripts. Create two builds of your project with a minimal script change, then compare the MSIs using MSIDIFF.VBS (in Platform SDK). If you find differences, and you are convinced how InstallShield stores the script files, you can write a small program that:
- Retrieves the scripts from the last built MSI
- Retrieves the product code from that MSI too
- Uses MsiQueryProductInformation (?! or something like that) to ask for the cached copy of the product
- Updates the cached copy
Running that program is much easier than creating and installing patches.
When using this method, keep in mind that you may not have covered all differences from InstallScript. Or, when this does go wrong, reevaluate the differences again.