View Full Version : INI path isuues

08-01-2002, 03:49 AM
Hi All,

Although i opened a service request on the next follwing issue, i wanted to know how many of you had this issue before, if ever.

This happens only in Repackager and not via the Author.

The official workaround so far is using the 3.5 Beta, which does actually fix the issue.

If you include an INI file, with one of its values being a path, for
example a file in your "My Documents" folder,
during the *.ism creation, it is switched to a path variable like,
for example [MyDocuments].

When you deploy the msi, that was created from the snapshots stage, the ini still shows the path variable and is not converted
back to the full path.

Thus, other programs that rely on the info inside the ini file, cant work properly.

Any one has any ideas ?
Am i missing anyhitng here in the creation process?
Is there a page missing in my AdminStudio help file? :)

Thanks all !

Arie H.

08-01-2002, 06:38 PM
It looks like it's pointing to somewhere under C:\My Documents and Settings. Refer to your INC file and find out the path it should be, and replace [MyDocuments] with appropriate MSI System Folder Property.

08-01-2002, 07:22 PM
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.

08-01-2002, 07:51 PM
Turning of INI file changes analysis in Repackager, so that INI files are treated as regular files, will work. The catch is, you won't be able to update INI files' content as you would when doing through INIFile table.

Exporting INIFiles table from within a MSI to a project involves too much work. As you said, it is not as feasible when the file number grows too large.

My preferred approach will be reviewing the path in INC file, construct the directory structure in Directory table, and use the Directory property in the INI File Changes view. However, I will include INI as a regular file if I have confirmation from customers asserting the path will be static. Unfortunately, there is no one-size-fits-all solution.