No DIMs in Merge Module Projects !!??

[HookEm]

:confused: Why no DIM reference in merge module projects? Completely negates the use of the collaboration tool if the bulk of your install projects come from merge modules you maintain.

[Christopher_Pai]

I wonder how practical it would be to write a program to build merge modules from dim files.

[pkass02]

:eek: Arrrgh ! I just evaluated InstallShield Collaboration and found out, that DIM references are not possible in MSM projects !!
That's a real killer for IS Collaboration !! 😞

[Christopher_Pai]

I'm trying to understand the motivation for such a requirement. Merge Modules and DIM's both serve the same purpose of allowing distributed, componentized authoring of setup logic to be consumed by an installer. They are parallel technologies that both get associated to features at build time. I'm not sure why you would want to have a merge module consume a DIM.

[pkass02]

As long as you use merge modules just internal as means of structuring your Setup (according to "best practices" for Basic MSI projects) I agree: in this
cas MSMs can be substituted by DIMs (in most cases).
But what, if you want to Deploy parts of your Product as MSM ?
This is NOT a uncommon requirement, especially for Server-Client products, where you have to deploy the client sided binaries (togehter with some kind of client api). Example: OPC-Binaries. And many others.
You do not state, that nobody deploys MSMs , don't you ? 🙂

[Christopher_Pai]

It depends on your definition of deploy. I assume your actually talking about redistributing MSM's as part of an SDK for another organization to consume in their installs. Furthor you want to build those MSM's using DIMs.

Personally I think in this scenario MSM's are more hassle then they are worth. We've seen countless times over the years where some merge module provided has issues building merging into an install, bad behavior at runtime, or just purely impossible to service in terms of patching and upgrading.

I would move away from MSM for redists and look at standalone setup prerequisite packages. Microsoft has depracated many MSM's in favor of this approach. One example is MSDE. It is no longer reccomended as a nested install or an MSM reference. The reason is when there are security vunerabilities it's extremly difficult to patch your private instance of the engine because your productcode and productname doesn't match what the microsoft security anaylizers detect. By bootstrapping the instance with the official microsoft package this problem goes away.

[pkass02]

Ok, reasonable arguments. Thanks 🙂

[Christopher_Pai]

BTW, I don't know what your SDK is like, but would it be possible to assume/require that the user have InstallShield? If so you could just redistribute the actual DIM files.

Some SDK's are compiled binaries ( say a Win32 DLL or COM server ) that don't really care what it's being consumed by, and some SDK's include source code or make other assumptions about the language/platform that will consume them.

[pkass02]

Deploying DIMs instead of MSMs has one great disadvantage: DIMs are just descriptions and do not contain the data, where MSMs already contain all required data. So You have to deploy not only the DIM but also all files of your workspace, that the DIM requires ... haven't you ?

The only acceptable alternative is a separate setup, that the custumer may call as a nested setup.

Now I found out, that a nested call to msiexec (or setup.exe which calls msiexec) can only be performed in the Ui-Sequence. Too bad ! Thus it
is not possible to perform a subinstallation dependent on some conditions that are set in the execute sequence ? That is an ugly restriction !

Why get things so complicated with MSI ???
😞

[Christopher_Pai]

Depends if you are trying to accomplish distributed authoring of installations or redistributing to externa customers portions of an installation. DIM's really are designed for the former and not the latter.

If you are doing the former, I like DIM's better then MSMs because the build is alot faster. Merge modules can take a long time to pull the embedded CAB's and extract the filekeys and then reinsert them into the built MSI. I've worked on installs that hundreds of merge modules and this cost was not trivial.

Nested installs are pure junk. Don't even consider them.

[pkass02]

Christopher Painter wrote:
...
Nested installs are pure junk. Don't even consider them.

So then, what are "best practises" if you have to comibine software parts (deployments) from different manufuacturers, which my software depends on (And it does not depend on those generally, but for some selected features ...) ?

[Christopher_Pai]

Generally installation serialization through bootstrappers is the best practice. At some point currently available generic bootstrappers don't meet your needs so you have to roll your own.

I"ve implemented bootstrappers that do exactly what you suggest. Imagine a bootstrapper that looks like an Install with a feature tree but the feature tree is really a combination of your products feature and related third party product dependencies. You enforce the relationships of `if I install this I have to install that` and then drive the installation of all the packages including passing which features of your install to install. You run all of these installs in /QB mode.

This way each install is atomically installed without the hassels associated with merge modules and nested installs.

The state of the art is improving for bootstrappers and soon you won't have to roll this pattern yourself.