Merge Module Pros/Cons and Temp Folder Size Questions

[stevew]

I am trying to install VB6 and VC6 components as Merge Modules built from 3rd parties, instead of the the Plug Ins provided by InstallAWARE. I am wanting to just try to see the pros/cons. I may go back to the Plug Ins later.

Some questions are immediate:

1. There is a special installAWARE dialog that displays if the VB and C components needs to be installed. This components get installed before the main application. Under the Merge Module method the special prereq dialog does not show. I don't understand the need for the dialog because it is not needed under the MSM method. Is this possibly because InstallAWARE needs these run times itself?

2. Some size requirement points:
- A previously mentioned comment but i notice that the sizes of the Merge Modules are not included in the dialog that shows the estimated applicaiton size.
- As well i notice that these sizes do not include any of the extra space required to install the application due to temporary file space needed.
- I also notice that the complete setup is extracted to the temporary folder before being installed. This is going to mean that maximum path lengths are more likely to be hit.
- Also i notice that the dialog that shows the estimated sizes does not use consistent units. For example, The space available may be 1 GB but the applicaiton needs 75,000 bytes and the remaining size is 925 KB. It would be mathimatlically nice to keep the units consistent. Only computer nerds can do these translations automatically in their head.

3. I have several Merge Modules that are dependent on each other. Is InstallAWARE honoring these dependancies? Or are these dendancies an invalid concept carried forward from my Install Shield Merge modules?

4. When registering DLLS is installAWARE using only Windows Installer methods and is not registering these files the old fashioned way by adding keys to the registry manually?

5. I notice that the Merge Module decompressor included with InstallAWARE is going inside the MSM and uncompressing the contents. There is an option to skip signed files. When I build my InstallAWARE setup using MSM files, I notice that i do not get any compression size differences when compared to the Plug In method. I think that maybe the setup builder is also uncompressing the contents of the MSM before building the project? If true then there are some inherent problems here (I do not want to alter 3rd party MSM for support reasons). Please confirm the status or the reason to ingnore this issue.

6. With Merge modules there is no option to Not uninstall the MSM. oh well.

7. when i install via MSM then i do not see the file names displayed as they are being installed. Instead i see a bunch of long Proxy-GUID values. Or maybe this is unrelated and are the registry keys. Maybe i don't see any files at all. This is fine but i do see the files listed when uninstalling. Basically the display is messy with MSM, the installation is faster, and the progress indicators are not as accurate. Is this expected?

8. I think that MSM does not have any advantages for low level components like the C and VB run times. MSM may be best used for things like the crystal run time engine. When might i want ot use MSM. Is this a more reliable method? For realiable i mean that i just want a solution with as few moving parts as possible. This would limit the chances that an installation might fail. As near as I can tell, MSM is not as realiable as InstallAWARE plug-ins; but is MSM more reliable for use with the Windows Installer technologies?

[MichaelNesmith]

1) If InstallAware needed those runtimes, it would not run unless they were always installed, which is not the case. The prepeq dialog is shown by default for all plug-in installed runtimes and can be disabled through the script (and the timing for the runtimes rescheduled in the script too, of course).

2) Thank you for your observations - I will pass them along to the product team.

3) InstallAware does not have a built-in concept of merge module dependencies, but if you add all dependent modules, they should work.

4) This depends entirely on how you are registering the DLLs...how are you doing this right now?

5) There is no need to manually decompress MSMs which you are including with your main setup, because they will be added to your setup in decompressed form when processed. However, you can decompress MSMs used by external setups you run that are not directly processed by InstallAware.

6) Uninstalling a product will remove its merged modules, but respect reference counting so shared libraries are not removed (provided, of course, that the MSM has been authored correctly).

7) I believe you can see files being installed on slower computers. The plug-in based method specifically hooks up the user interface for each runtime, which is why you see clear indications under that method.

Both methods work equally fine and the differences are primarily cosmetic - as you have accurately observed in your post. The major drawbacks for MSMs is that they cannot be placed in web media blocks or conditionally executed. The major drawbacks for plug-ins is that they are finite and plug-ins are not available for runtimes that already have MSMs (such as Crystal).

[stevew]

wow, you work on christmas day (previous post) plus you are fast! outstanding!

4) registering dlls is being done by the installAWARE. For the Install Files command, if i go into the details there is a check box for "File is Self Registering DLL". Are these being done by the Window's Installer? The reason i am asking is because if the keys are being added manually and not using the Window's Installer then this does not meet windows logo requirements. So is the Prerequisite Installation is registering DLLS, or is the the Window's Installer being called twice? (once for the prereq's, then reboot, then once for the app $TITLE$). Have i made the quesiton more confusing?

[MichaelNesmith]

Thanks for your appreciation of our work - always makes our day here!

4) If you check this box, Windows Installer will self register the DLL. But it will do this by calling the DLL's self registration mechanism. So the answer is yes and no - yes, Windows Installer is registering the DLL; no, registry keys are not being explicitly specified but created by invoking the DLLs self registration mechanism. Prerequisites are unrelated to DLL self registration.