Managing multiple developers on InstallShield project via TFS

[anup_jishnu]

I have 3 developers who can work on InstallShield. Based on the work at hand, I am thinking of having all three of them work on the same ISM & RUL files to speed up development. TFS provides merging functionality so should be good enough. I want to know what others feel about using TFS to manage 3 developers check-ins for same ISM & RUL files.

[ElenaN]

What you want is doable. The only trouble I had – TFS Auto Merge “spoils” ISString table in the ism. To avoid this I always choose to Merge Changes In Merge Tool (tick “Navigate conflicts only”, in most cases there is no conflicts).

[anup_jishnu]

Thanks ElenaN. My previous experience was only in Visual Studio Setup projects and thats what we used to do there. But I had heard from an Installshield developer that it gets very messy with Installshield scripts and so should be avoided. As you suggest, I will give Merge Changes In Merge Tool with “Navigate conflicts only” a try.

[ElenaN]

Forgot to specify – my experience was with Basic MSI projects which are stored as XML.

[Christopher_Pai]

In my extensive experience in this area, InstallShield is unsuitable for what you are trying to do.

The problem is two fold:

1) InstallShield uses a DTD instead of an XSD XML document.
2) InstallShield algorithms for generating primary keys frequently results in merge conflicts.
3) InstallShield ISM is massive, monolithic increasing the likeliness of a merge conflict.


The problem is if I had a file to an installer, I might hit 5-6 tables. Something like Directory, Component, FeatureComponent, File, and various ISExtended tables. When I compare differences it's hard to read that where an XSD like WiX would be logically grouped together.

InstallShield generates primary keys for many tables. Things like AllOtherFiles1. Well, when two developers go off on two different branches they frequently create the same primary keys and this breaks the merge.

If you really want to do this, you'll want to look at something like Developer Installation Manifests.

My personal solution is to split development into merge modules authored in Windows Installer XML. I then use IsWiX (Industrial Strength Windows Installer XML) to author the wxs. This solves the problem by:

1) Split the work into multiple files to reduce likely hood of merge need
2) Author XML that is hashed and sorted to aid the tool in merging
3) Reduce the tooling cost because only 1 developer has to have a copy of InstallShield
4) Continue to leverage the benefits of InstallShield over WiX

If you ever want a demo, I could do a webinar.