Software Deployment

the problem with Wise MM's is the implementation they use to get them in.

For example.

when you have a file which is in a merge module you application is flagged to import the mm.

Prior to importation you generally have this

application dll and
application dll com registration

what wise does during the detection of the mm is this.

detects dll is present

offers replacement MM.

if you select yes to mm replacement the following happens.

1) remove application.dll
2) add new MM replacement dll and com

the problem here is now you have this in your app

1) new mm
2) old com registration in dummy component named "registryXXX"

the issue is now your new MM is nicely reference counted as expected with MM's. however you now have a rogue component containing unreference counted regsitry information.

during uninstall of applications with this scenario you can run into removal of COM registration effectively leaving a machine crippled. (in bad cases it requires a rebuild)

The subject of merge modules and how they should be used has been a source of debate from the inception of the Windows Installer technology. With reference to in-house developed Merge Modules the answer to your question is more logistical than it is programmatic.

Custom created Merge Modules can and will become a management nightmare if the business does not first give a great deal of thought into how they are to be managed. Regardless of the projected number of modules that are expected to be produced consideration should be given to the following points.
1. Where are these Merge Modules to be stored?
2. Are Custom Merge Modules to be housed separately from Vendor provided modules?
3. By what means are the Merge Modules to be cataloged?
4. What is the procedure for the introduction of new Merge Modules as well as the upgrading of current Modules?
5. Are current installations to be re-packaged in the event of module upgrades?

These questions and I’m sure many more specific to the businesses environment have to be answered or the before logistical nightmare will raise its ugly head in a matter of time.
I would strongly suggest that a well planed source control system, such as Source Safe, be put in place to help manage the Modules. Additionally a carefully planed set of business rules be enacted to have governance over the process.

As to the question of the tools used in the construction of the Merge Modules. I am for lack of a better term a “Wiser”, that being said and with all due respect to my buddies at Altiris as well as the development engineers at InstallShield that I have butted heads with over the years. Neither Wise nor InstallShield sets the world on fire when it comes to building Merge Modules. Both tools interject tables, information and objects into the created Merger Module that are proprietary to the tool used and have little to nothing to do with the objects that the Merge Module was created to install. These entries cause conflicts when the Merge Module is added to an installation being built in a competing development tool. In fact in some cases depending on the content of a Merge Module you will find that the created Merge Modules can not be compatible with higher version of the very tool used to develop the module. Neither tool is capable of producing a “Pure State” Merge Module.

In development of your Merge Modules I would suggest you use what ever tool you wish to create them. Then once the Merge Module is created edit them in Orca and remove the un-necessary proprietary tool junk. A Merge Module should contain only the tables, Objects and Actions necessary to install the object contents, nothing else.

Finally I would be remiss if I did not mention Binary Compatibility. If the Custom Merge Modules are to house in-house developed objects. The development staff should always maintain Binary Compatibility between their developed objects.

I hope this server aide you in your decision.
Regards,

what tool are you using to implement the merge modules.

Wise has a bug which screws up the use of merge modules entirely, I haven't looked into how installshield handles them too much but I expect the are even worse.

if you have a decent conflict management tool or are looking to SVS i wouldnt bother with the MM's. They are overrated being that most tools that implement them do it wrong.

we will be using installshield.
what issues arise with Wise when creating MMs?

In my previous job I never had a single problem with merge modules created using Installshield. Something to remember when creating common control merge modules, i.e. Microsoft ones is to ensure that your syncing up the guid's acrosss the packages, basically the same guid MS use for comctl32.dll you should use in your home made one.

Generally you can also download Microsoft pre-made merge modules however I have found they are generally very badly made, have ICE errors, and its quicker to make one yourself.

Regards,
Paul

just whilst on the topic of installshield it does some pretty ugly stuff with components.

for example all COM registration is dumped into a single component and marked never to be uninstalled.

from my experience which is little with IS I found that it only worried about the dll not the com and there is no association between the two of them with IS. something which makes ICE33 more prevalent of an issue with IS than it is with Wise.

John,

Mr frodo did mention "in-house merge modules" didn't he [;)]
The desciption from John which is correct is referring to when you are performing a capture and Wise asked if you want to replace the file with the merge module instead. The file is removed but the com component registration will still be left in the package.

So if you have created your own merge module this issue doesn't arise when you add it to your wise project or by any other means.
If the DLL is backward compatable you should be okey but if you want to replace it I guess you would have to update each package using this merge module and then you should only have to reinstall one of the application to get the updated file in place.

From an installshield perspective during a snapshot it does its best to ensure that all the com information is listed under the relevant file, what it does do however is drop stuff into the registry table even if it has put it into the com tables correctly. This I have found can cause 100's of 33's which, in reality, are already resolved and the relevent keys can be deleted.

Paul

just to clarify AngelD even as a custom MM I would think this would still be an issue during setup capture.

Can you clarify if this is what you meant ? Just want to make sure we are on the same page. This is a particularly annoying feature of wise.

Hi John,

What I meant was this doesn't apply if the package is created from scratch without a capture.

You are correct when a setup capture is performed any file that is registered (ex. ActiveX/COM Component) and is replaced by a merge module when asked Wise does only remove the file in question but do leave duplicate registry information from the register info in the Registry table. This will have a bad affect when the application is uninstalled and if the merge module is used by other application as well.
If the merge module uses shared component the COM component register info the component(s) should not get removed as other applications uses the same but the registration info will be removed as it has leaked to the Registry table outside of the component in the merge module. The uninstall will break other installed applications using the same merge module. This do apply when using setup capture. So it's vital to verify that there is no duplicate registry info before finishing the project that is connected with the COM component when replaced with a merge module.

I recall a discussion between you (John) and Ed at the Altiris Forum about this and if I recall Wise/Altiris/Symantec [;)] or Ed stated (don't recall who) that this has been fixed in later versions but not totally true.

un-necessary proprietary tool junk

nicely put Rob...

Can i query one bit..

did you mean "remove" in the above quote ?

Quite an important word in the context of your conversation.

AngelD yeah I think I mentioned it "was to be fixed" I too agree it has not been done. I had a few complaints to Mike Grueber of Wise and he promised me it would be fixed so far I haven't seen evidence of a fix.

all that aside i still like wise .. :-)

Thanks John,

Good catch, it would appear that my thoughts out ran my fingers on that one. It should indeed read as follows;

Then once the Merge Module is created edit them in Orca and remove the un-necessary proprietary tool junk.

Regards,