Thanks for the answer 🙂
Can you perform this little test and tell me your results.
This is a bit long, so bare with me. If any step on the way
is not understood, don't hesitate to ask for further details.
Create an ini file, have one of its values - a path to
somewhere in your drives. have another one to another
location just to see differences.
set your analysis option to track files and track ini changes
create a snapshot, using the Repackager, have it call
notepad.exe instead of a real setup.exe file.
Close notepad and it will give you an option to do some more changes before it does the second snapshot.
do the following: move that ini file to another dir and copy notepad.exe to that dir as well, or any other file
for that matter, but you need at least one "more" file, or you'll get a warning and later an error on deployment.
go on and make the second snapshot. The result is the ism file
At this point it will want to continue with the build, you can proceed with that.
After this is done, open the ism file and look at Step 2 for the Files that were added. Notice that you do see
that notepad.exe or other that you added, but not the INI file.
At the same step, look under the INI file changes and voila, your INI files, now look for the values that had paths
in them...they are basically path variables.
Edit the MSI file via Orca or AS, and head to the INIFiles table, and you can see that the path variables are there.
Now, unless the snapshots caught unnecessary reg changes, which you can remove (but will have to rebuild), you
can go a head and delete those 2 file you moved to a new directory and run the MSI which in change should deploy
BOTH files to that dir again.
Now look at the INI file for the paths...hmmm..the paths did not resolve back to regular paths...
OK..At this point you might call foul...I'm trying to catch INI file changes, when actually no change was actually made,
its rather NO ini - before and now that INI does EXIST...ok..try doing the same process, only now in your analysis
options uncheck anything to do with INI changes.
When you open the new ism, you'll see that the INI that you moved, actually doesn't show anywhere..and will not be
deployed. As if INI is not "treated" as a normal file. This is why I used the "More" at the beginning, otherwise this would
be an empty-file ism you have just created...
At this point, you can add the file manually and rebuild. ON this occasion, if you deploy the MSI, the INI paths will be ok !
You can view the table in Orca or AS. You can also export the good INIFiles table at this point and import them into that
first "bad" MSI, and it will replace it, so deploying the first package will be ok now as well.
This is a solution when you have 10 files nested all over...what do you do with 100, or more...
Hope this didn't sound too crazy 🙂
I'm using AS for windows XP, where almost all aspects of the station, including GUI, are being read from ini files. This
includes paths to other components - you can imagine that after deploying an initial test package I created, the station
simply didn't work anymore... 😞
And as a reminder..This would NOT happen under the Author - tested it as well.
Thanks for any input you or the others might have on this !!
Arie H.
