Certain dll's not being installed in the right place by Installshield repackager

[calref]

I am using Installshield repackager and capturing the files installed by another product (Aspentech Hysys in fact).

Certain dll files, that were supposed to be put into [systemfolder] are not being put there when the built .msi is executed. In fact, they seem to end up in the root of the 😧 drive (the drive on which I stored the captured files and built the package). These are files such as

lsprst7.dll
mfc70.dll
msvcp70.dll

and quite a lot of others.

Is this a bug/feature, and how can I make it function correctly?

[calref]

Would it help if I unticked the 'Use merge modules' option in advanced settings of the repackager? Does that mean it will literally install the exact files it detected during the snapshot process (and perhaps put them in the correct place?)

[looeee]

[list=1]

Find the Merge Modules in Editor (under redistributables)

right-click on them

choose properties

on the second tab (going my memory here) there's a page called configurable options.

Point them at the SystemFolder

Is it a bug? ask Microsoft ... it's their module

looeee

[calref]

looeee wrote:
[list=1]

Find the Merge Modules in Editor (under redistributables)

right-click on them

choose properties

on the second tab (going my memory here) there's a page called configurable options.

Point them at the SystemFolder

Is it a bug? ask Microsoft ... it's their module

looeee

Hmmm, strange, but the properties item, on the context menu, is greyed out when I do this.

Also, this would imply I have to do it every time I repackage an installation. It's much easier to just untick the 'Use merge modules' option in advanced settings of the repackager before building the msi.

I wonder why the default is to use merge modules anyway, when the idea of capturing an install and repackaging it, is to reproduce what the original install did as closely as possible?

[looeee]

Not sure why it is greyed out. It should offer you the destination if you remove and re-add the mergemodule.

Why use them in the first place? Component code sharing is the main reason. You want to ensure that when you uninstall that you only remove shared components when they are not used by any packages. Every time you deploy a resource (file, registry key, service, etc.) you need it to be counted as the same shared resource as other packages that deploy it.
If you don't use MSMs, you can get away with conflict-solving but it makes that stage a lot more work with very careful planning.

Yes its annoying that those MSMs go to the wrong folder, however it is only the files distributed with VisualStudio.NET that behave like that.

looeee