Missing .ini files
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
This has been causing me a major headache today!!
Thanks,
Typ0
0 Comments
[ + ] Show comments
Answers (13)
Please log in to answer
Posted by:
inert
20 years ago
Posted by:
typ0
20 years ago
Posted by:
inert
20 years ago
Posted by:
sean_c_roberts
20 years ago
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
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
Posted by:
inert
20 years ago
Posted by:
typ0
20 years ago
Posted by:
WiseMonkey3
20 years ago
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.
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.
Posted by:
MSIPackager
20 years ago
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.
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.
Posted by:
typ0
20 years ago
Posted by:
sean_c_roberts
20 years ago
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.
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.
Posted by:
inert
20 years ago
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..
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..
Posted by:
WiseMonkey3
20 years ago
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.[&:]
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.[&:]
Posted by:
boyfromoz
20 years ago
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?
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?
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.