Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.

Shared DLL Folder between 2 MSI Projects

Started by 10000maniacs , Aug 14 2012 11:01

5 replies to this topic

10000maniacs

Full Members
4 posts

Posted 14 August 2012 - 11:01

Hi Folks.
Our company has two seperate installs, but in 99% of cases these two MSI installs get installed together on the same customer machine.
They both share the same folder for common DLLs called COMMON.
Both installs now have minor upgrade patches and one of the patches updates a DLL in the COMMON folder.
Here is the problem: When I apply the patch that updates this common dll, all other DLL updates that are applied in this patch fail. Its as if MSI stops applying dlls. When I exclude the COMMON dll from the patch, all the other DLLs apply correctly.
Is there a rule in MSI that states that you cannot upgrade a DLL that was installed by another MSI project? If so, how do I bypass this rule in Installshield? (And not screw it up for future minor upgrades)
Thanks,
Mike

Edited by 10000maniacs, 14 August 2012 - 11:12.

Stefan Krueger

InstallSite.org

Administrators
13,269 posts

Posted 15 August 2012 - 12:53

There's no such rule, as far as I know. Did you generate a log? It should tell you why the DLLs don't get updated.

Stefan Krüger
InstallSite.org twitter facebook

HOWTO: Logging an MSI installation

Read this before sending me e-mail or private messages

10000maniacs

Full Members
4 posts

Posted 15 August 2012 - 17:24

QUOTE (Stefan Krueger @ 2012-08-15 12:53)

There's no such rule, as far as I know. Did you generate a log? It should tell you why the DLLs don't get updated.

Hi Stefan,
Just got the rule book out. The Common folder is not allowed

Rule 16: Follow Component Rules
Components are a very important part of the Installer technology. They are the means whereby the Installer manages the resources that make up your application. The SDK provides the following guidelines for creating components in your package:
•Never create two components that install a resource under the same name and target location. If a resource must be duplicated in multiple components, change its name or target location in each component. This rule should be applied across applications, products, product versions, and companies.
•Two components must not have the same key path file. This is a consequence of the previous rule. The key path value points to a particular file or folder belonging to the component that the installer uses to detect the component. If two components had the same key path file, the installer would be unable to distinguish which component is installed. Two components however may share a key path folder.
•Do not create a version of a component that is incompatible with all previous versions of the component. This rule should be applied across applications, products, product versions, and companies.
•Do not create components containing resources that will need to be installed into more than one directory on the user’s system. The installer installs all of the resources in a component into the same directory. It is not possible to install some resources into subdirectories.
•Do not include more than one COM server per component. If a component contains a COM server, this must be the key path for the component.
•Do not specify more than one file per component as a target for the Start menu or a Desktop shortcut.

overlordchin

Full Members
100 posts

Posted 15 August 2012 - 20:09

We have several common components across multiple products that install to a "CommonFiles\Company\Component.version" structure. Marking them as shared allows them to sit in the same common location but yes based on those rules if another product uses an upgraded version we install it do a different folder based on the version number

This way if one product gets ahead of another it wont break the previous. Consider this scenario.

Product A installs version 1.0.0 of a component to a directory
Product B installs version 1.2.1 of the same component to the same directory overwriting the previous version.

User runs a repair on Product A. What happens? I would think it would restore the old version breaking Product B.

Stefan Krueger

InstallSite.org

Administrators
13,269 posts

Posted 16 August 2012 - 08:55

QUOTE

Just got the rule book out. The Common folder is not allowed

Which of the buulet points do you mean specifically? Note that the first point only says you can't use two (different) components (i.e. different ComponentIds) to install the same resource. You can however use the same component in multiple products. Typically, a merge module is used for this purpose. So if the component GUID is identical, they can install the same resource in a common folder.

QUOTE

Marking them as shared

That's a legacy setting for compatibility with non-MSI setups. If the file is only installed by msi setups (and you follow the component rules, i.e. use identical GUID) then you don#t need to set the shared flag.

Stefan Krüger
InstallSite.org twitter facebook

HOWTO: Logging an MSI installation

Read this before sending me e-mail or private messages

10000maniacs

Full Members
4 posts

Posted 16 August 2012 - 16:04

Thanks Stefan.

Back to InstallShield "Basic MSI" Projects

Licensed to: InstallSite