cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rosherman
Level 2

Shared DLL betwen two applications

Hi,
My company has developed two different applications , but there are some common dll's (not COM objects). Both applications has their own installer (based on Installshield MSI project).

1. What is the best way to distribute the commom (shared) dll's ?

2. Is there any method to handle different versions of these shared dll's ? (for example, if our customer installs an older version of Application A and a newer version of Application B (that contains also a newer version of the shared dll's)

Thanks,
Robert
Labels (1)
0 Kudos
(4) Replies
Holger_G
Level 10

Use merge modules for the shared/common components.
0 Kudos
rosherman
Level 2

Nick Rivers wrote:
Use merge modules for the shared/common components.


Thanks for your reply. But, I'm new to merge modules. Can you please povide me some info what are these modules, how can I create them and how does this solve the main problem (shared components betwen two different applications).

Thanks alot,
Robert
0 Kudos
klacounte
Level 6

What do you mean by "shared"? Is there only supposed to be one copy of the DLL on the machine that both applications load? Or do both applications have their own copy of the DLL?

If you only want one copy of the DLL on the machine then go with the merge module approach - it's a project type so just create a new merge module project for the shared DLLs.

If both applications have their own copy of the DLL then you don't have to do anything special - just include them in both installs.

If you have a choice I'd let each application have it's own copy of the DLL. That can prevent support issues caused by version incompatibilities. e.g. User installs Application A with version 1.0 of a shared DLL. User then installs Application B with version 3.0 of a shared DLL. Now Application A is using version 3.0 of the shared DLL also so if a function is not backward compatible then Application A is broken. JMHO
0 Kudos
mikegillow
Level 5

Merge Modules are one of the project types in IS. Their purpose is to package components used frequently by other installations. Take a look at the Redistributables folder in the IDE for lots of examples.

However, I'm not sure if this is the right way for you to be going - your #2 item suggests that you need to be able to support side-by-side distribution of those dll's (something I'm not familiar with) unless you maintain full backward compatibility in the dll's. In your scenario, if the new dll won't work with the old version of Application A, then you need to have a way to have both the old version and the new version installed on the target machine.

Also, as I understand it, if you have a merge module that is updated for a release, then that release must be handled as a Major Upgrade and not as a minor/patch upgrade. So if those common dlls are subject to frequent change, a merge module might not be right for you.

If you don't have to support side-by-side installation of the dlls, I think all you need to do is include them in both of your projects and make sure they are flagged as Shared so that Windows will maintain usage counts.
0 Kudos