Problem with adminstudio with most applications

[CChong]

There is a problem when you package most(any in my opinion)apps with install shield 3.01 and with previous versions.

Install shield puts in rubbish when you install the msi package(once packaged with admin studio) when it registers the _com files in components. This rubbish occurs in the following place(s), (an example of one key only in a package- Acrobat) you go to .pdf in HK_Classes_root/.pdf.

This key has a default key called acro.exchange, you then goto this key & proceed to acro.exchange/shell/open/command. In this spot, it will contain a long line with rubbish in it.

This is the problem that is constant in most, if not all applications.

To fix this problem, you need to self register all files that have no file extensions attached to them(ie .pdf or .zip etc). You also need to delete all the CLSID in the registry if any exist per file component.

The components for the _com files with file extensions(generally .exe), need to be exported from the original installed PC & imported into the install package. In other words, install the acrobat reader or writer packager etc, export the .pdf, .application/pdf (under MIME/Database/Content type/application/pdf) & acro.exchange into the install shield MSI package. Also do the CLSID as well. DO NOT HAVE THE FILE AS SELF REGISTERING.

Please note that under each file extension, there will be numerous acroexchange. xxx or similiar, make a note before deleteing the CLSID _com registratons from the package. You will need to extract each of these from the original machine & import them into your package. By importing the registry settings, you are registering the file.

Once you have all these written down, delete the CLSID under the com registrations in component(under advanced section).

This should do the trick.

If you don't remove the rubbish from these entries, it produces all sorts of weird results.

This problem is also seen in Winzip.

When you package up winzip, then install it on a clean machine, then double click on a zip file, the file does not open the contents of the zip file to the window, it is blank.(This is what happened to me). This is because of the rubbish that is put into the registry. Once this is fixed, winzip runs ok.

good luck

PS

More oftern than not, some file just wont self register, this is a major flaw with install shield 3.01 & previous versions.

This has been registered with install shield but have recieved a responce from the support team. They know about the problem, there is no fix at present but there is a work around given by install shield which is to self register all the files, but this still puts in the rubbish as describe above.

The work around does not work all the time as some files do not self register properly.

So the jury is out & waiting for the verdict.

[TsungH]

I beg to differ.

If you have MS Office 2000 installed, and look under, say, HKCL\Word.Backup.8\shell\Open\command key, and you will see a value "command" of REG_MULTI_SZ type with some seemingly junk data. It is not created by ISAS 3.x. Repackager just faithfully grabs information that's added, Acrobat Reader in your case. Authoring environment imports everything as it is from INC and NIR file.

We at InstallShield Consulting Services have repackaged Acrobat Reader, Winzip and a whole lot more countless time, and the process to repackage Acrobat Reader and Winzip is like a walk in a park. Our customers are able to deployed the repackaged builds seamlessly and use them on their production machines without a glitch.

[jeronimo]

Hi TsungH (and MagPie),

since you've repackaged Winzip and Acrobat (and many other apps) I would like to know some things.

Until now, I've repackaged Winzip 8.00 and Acrobat 5.0. With a minimum of work, both apps seem to work fine but:
- when I launch Winzip for the first time, I have the message "...Winzip isn't currently associated with ZIP files". How to avoid this? I've examined the registry and changed many things, but it still doesn't work the way I want.
- even if it works, how to be sure the install is clean? I can't examine each regitry key to see whether it is correct, wether it misses a key or, on the contrary, whether there is a key that shouldn't be there.
- in which measure can I ignore warnings like ICE33, which warns me that a registry value may overwrite a value created through the Extension, ProgId or Verb table?

etc... etc...

Comments?

Thanks,

Jerome

[TsungH]

Jerome,

For the association issue, I would have that as part of repackaging process, i.e., run Repackager, install Winzip, run Winzip once to configure everything, run Repackager to get the all the changes made, import INC and NIR to Author environment. That should resolve the association issue.

For a repackaged install, it will take a significant amount of time to have a "clean" (how clean is clean?) install. To have a "clean" repackaged install, I will go thru each and every registry entries and remove all that's changed by OS, and other factors. The same process applies to all other views, like INI. Having a good exclusion list facilitates repackaging process, but no exclusion is perfect. In my opinion, the cleanest and the easiest way (maybe) is to have the installation written from scratch.

Currently, we are optimizing the import process to associate ProgID, Extension, verbs to appropriate file (DLL or OCX), hence reducing the number of ICE33 warnings. ICE33 warnings on registry can be safely ignored.

Watch out for installations that put down services, hardware drivers, DSNs. They usually require more time to make it work, and at times impossible to be repackaged (if hardware dependent). Sadly, there isn't an one-size-fits-all solution.

[jeronimo]

Ok, such an amount of work, that's actually what I feared...
Aren't you tired at that hour?

Thanks for your answer,

Jerome