Could someone please explain to me why when i create a package with wise package studio it ignores most of the .ini files located in the the directory i wish to capture?
This has been causing me a major headache today!!

Thanks,

Typ0
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
You should check both the File-table as the IniFile-table, i also had problems like that. WPS has some trouble identifying .ini files as such.
Answered 08/04/2004 by: inert
Orange Belt

Please log in to comment
0
Thx inert,
I've checked and the files are not located in either table.
it seems if the ini file does not adhere to:
parameter = parameter
it is ignored. is there anyway for me to change this behaviour?

Thanks again,

David
Answered 08/04/2004 by: typ0
Senior Yellow Belt

Please log in to comment
0
Hi,
That's a tricky one.
I assume your Xclusion list is in order...Maybe you can find out what kind of installer the Manufacturer has used (installshield etc.) so you could "break in".
Anyway you could run FileMon whilst installing the app. and see what happems..

Succes,
Answered 08/04/2004 by: inert
Orange Belt

Please log in to comment
0
Ah, kind folks!

This mishandling of INI files is NOT a bug - it's a FEATURE!

Just like it did in Wise versions 4-9, Wise handles INI files dynamically.

If you've imported an INI file into WFWI or Package Studio, then the CONTENTS of the ini are stored, and Wise tries to rewrite them at install-time.

I'm not at all surprised that you're not finding INIs in the file table - because they're not files - they're just settings that Wise INTENDS to reconstitute into actual files.

I encountered this problem when trying to set file permissions on an INI file in the Windows directory. We're in a locked-down environment here, and I had to grant special access rights... surprise... there was no INI file LISTED to which I COULD apply rights.

(I ended up using xcacls.exe as a custom action in the Execute Deferred MSI script.)

I hope this helped...

Respectfully,

- Sean Roberts
Answered 08/04/2004 by: sean_c_roberts
Senior Purple Belt

Please log in to comment
0
HeheH! You could be right,
i'd alway's (in the nick of time) add the .ini files manually from the installation, so i'd be sure they were actually being installed.
Next time i shall remind this, thanx Sean.
Answered 08/04/2004 by: inert
Orange Belt

Please log in to comment
0
Thanks for your replies ppl,

So does this mean i will have to maually had the .ini files after the .msi package is installed on the destination computer? or can i tell wise to treat these specific files as normal files rather then try to be clever with them?

Thanks!

Typ0
Answered 08/05/2004 by: typ0
Senior Yellow Belt

Please log in to comment
0
This particular quirk of WPS has been bugging me for quite a while.
I did however discover something just over the last week of packaging up a monster app. It has to do with the way you configue the Setup Capture setting.
If you select "Convert Registry entries into advertising info" and "Use snapshot comparisons and SmartMonitor", this will almost alway miss a lot of ini files if not all.
If you capture this way I recommend as soon as you have captured do a search for ini files in the apps directory's or by time and date, then add them manually as files to your project.
If you select "Retain registry Information as-is", and "Use snapshot comparisons only" you will usually get most of the ini files imported into the ini file table. But if there are a lot of ini files I've had compiling errors and I still use the manual method. The only reason I use the ini file table is if I want to package something with a few ini files and use variables I can set from inside the msi that will be deployed to different platforms.
Answered 08/05/2004 by: WiseMonkey3
Senior Yellow Belt

Please log in to comment
0
I'd agree with the WiseMonkey..

If you have problems using the IniFile table - delete any relevant entries then add the .ini files to the package using the file table (so they are dealt with in the same way as all other files in the installation).

The IniFile table generally works well but there are exceptions. One thing to watch out for is that some applications rely on the INI file entries to be in a certain order. When msiexec creates "yourfile.ini" via the IniFile table - it will put them back in any order it sees fit, which can cause problems with some poorly coded apps.

Guess you lose some of the flexibility by not using the IniFile table but sometimes you have no choice and will just have to use custom actions for any tayloring required...

Good luck,
Rob.
Answered 08/05/2004 by: MSIPackager
Third Degree Black Belt

Please log in to comment
0
This thread certainly answered my question.

Thanks again eveyone for all your help!

Typ0
Answered 08/05/2004 by: typ0
Senior Yellow Belt

Please log in to comment
0
Greetings all!

Excellent answers all around, but, on principle, I have to disagree with WiseMonkey's method.

IN THEORY :) the PURPOSE of the recreating INI files is so as to not lose existing settings.

I remember from Wise versions 4-9 (non-MSI) that INIs were handled dynamically:

If the INI file didn't exist, it was created, otherwise not.
If a section didn't exist, it was created, otherwise not.
If a name-value pair existed... you understand the rest of the permutations.

Do MSIs do the same thing? Do they attempt to retain existing settings? I've not had to deal with this recently, so I'm curious.
Answered 08/05/2004 by: sean_c_roberts
Senior Purple Belt

Please log in to comment
0
Well....
My experience in this matter is that when you've got some ini-files which are recognized by WFWi , the msi installs correctly.
On the other hand.. when i do adjustements in these captured ini-files, the actual msi-installation tends to 'undo' these changes.
So when i want to be sure i just make them Files, instead of IniFiles.
Mostly the clock is ticking....so i'll have to dig deeper in that matter sometime..
Answered 08/05/2004 by: inert
Orange Belt

Please log in to comment
0
Don't get me wrong I love the ini file table.[:o]
It really is versatile and works for a lot of apps & caps, as long as there aren't bazillions of them and the ini files aren't to large in content.
For example has anyone captured CorelDraw8.0?

If you have the time it is worth investing but should have a reason like being able to customize PROPERTIES or variables, one of the main reasons I use the ini file table is to populate specific settings for metaframe or a standard workstation from the one MSI.

Many types of ini files won't even import, such as those that are used for CoolGen.

Regardless of your choice and it can be per package and mixed I now always do a file search incase WPS didn't get them all.

Also like INERT says the time is a-ticking so sometimes it's easier to just grap the ini files and dump it as a file.[&:]
Answered 08/06/2004 by: WiseMonkey3
Senior Yellow Belt

Please log in to comment
0
This is alway a pain in the a$$. You should be able to set the system to just copy the .ini files and not try to re-create them.

Always seem to be .ini files that don't have the standard [Header] format. If it contains none of these (just text etc) you loose the lot. I generally use windiff.exe or similar to scan my capture against the install app and see what is missing - usually a lot of junk .tmp files and half of the .ini files.

Is it the norm to add them manually or has someone found a better way so they just stick?
Answered 08/10/2004 by: boyfromoz
Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity