Utilizing Merge Modules for Common DLLs Strategy

Hi all,

I have the following situation:
--------------------------

1. I would like to standardize commonly shared DLLs and registries on 5000
PCs(Win95, NT and 2K environment) by using Merge Modules.
(i.e. Files and registries under Windows folder, System folder, Common
Files...)

2. I try to repackage every single existing applications (appx 1200
different apps) in MSI format and combine Standardized Common DLLs.

3. Whenever I find new files and registry that can be part of Common DLLs, I
would like to include them in right Merge Modules and officially post them
on intranet and distribute to every single desktop.

What I have done is:
-------------------

1. Categorize and create MSI files of all the default merge modules that
come with ISWI 2.01 into 3 as follows;
- Common DLL (Generic DLLs)
- Common RTM (Language specific Runtime Modules)
- Common DBC (Database Connectivity related)

2. Before I run InstallShield Spy to create MSI file for existing apps, I
install those 3 apps on base PC as a baseline.

3. Run Spy and get the delta.

4. Analyze shared files and include merge modules(which can be duplicated
with my Common Packages).

5. Create separate merge modules that is not part of default MSMs.

6. Repackage(Update) Common Packages with brand new Merge Modules.

7. The final production package should be able to deliver any updated merge
modules with it and scheduled Common Package distribution will ensure all of
desktop's Common DLLs are up-to-dated and corrected properly regularly.

What I found as merge module candidates other than default are;
-----------------------------------------------------------

1. Oracle version 7, 8 ODBC Drivers
2. PeopleSoft ODBC Drivers
3. Passport Portal
4. Seagate Crystal Report v8.0
5. Old Microsoft DLLs
6. Java2 Runtime
7. Adobe Common Files
8. Microsoft Shared
9. Real Player
10. Macromedia
11. To be identified

My Questions on all of these are;
-------------------------------

1. Is this valid thought? We are using software distribution tool call -
Novadigm(same idea of MS SMS). It is a good tool but have a lot of issues on
DLL and registry conflict. I try to be relied on resiliency that MS set with
MSI on resolving those issues.

2. When I repackaged a application and run dependency check, it finds those
DLLs (Old MS DLL i.e. vb40032.dll ...) and put them on right places (even
create one.)

Is this means the Default Merge Module already has those but doesn't deploy
until I ask for it?
Or, it means the Default Merge Module didn't have one but just added it on
top of itself.

If it is the first case, How can I deploy those hidden files by default?
(BTW, I run msiexec /i for all the merge modules and MS Old DLLs is not
showing up.)

If it is the later case, is it permanent update or temporary? if it is
permanent, when I repackage Common Packages, is it include new files and
registries? If not, how can I add them up as part of MSM?

3. What is the best way of collecting (or subscribe) reliable MSMs? where
can I find it? http://www.installsite.org and
http://support.installshield.com/ are the most reliable sources?

I am really appriciated to you guys who read this big note in advance.

I hope I can get some answers on this so that I can go home early!!!! :)

----------------------------------
Young Pae young.pae@bchydro.com
PC/LAN Specialist 2
BCHydro NCS Application Support
Software Certification and Distribution
1-604-515-8547

Your question is quite complex. What you seem to be attempting is versioning control to standardize your install platform across the whole user population. In practice, this may not be entirely possible, as with the old Microsoft DLL's. The issue is registration of the objects when more than one version of the DLL is contained in the separate packages.

Windows Installer will allow this by placing the 'older version' into an application specific location and registering it for use by *that* application. This avoids 'DLL ####' by allowing the application to continue using the specific dependency even when the 'parent' DLL is updated by a service pack or such.

One problem with that approach is that each application tends to veer off into its' own little memory space on the target platform and run with a separate copy of any given DLL that may actually be in the application space of another process that is running concurrently. One of the reasons for having DLL's is to share resources, and this seems to be stepping back to the days when all resources were built into each application. But that is another soapbox...

Your intention seems to be to have a 'pool' of available DLL's that may contain several versions of the same file. My gut feeling is that doing so is going to cause problems. Certainly, in our development environment, we have had to be very careful to ensure that each DLL is uniquely identified and that the latest version is the one requested by all calling routines.

So let me ask a few questions:

Do you have a standard software suite across the board, so that all machines will be using a uniform standard and you can test to ensure that all the elements you are incorporating will work in all the environments?

When you are doing your product design, how do you determine the set of tools you will be using? I can see that your applications span a wide variety of operating systems ... what is your development environment?

For our applications, we design to a specific platform and try to closely control the configuration of the target machines. This is basically in response to our product complexity and the fact that we have the luxury of working on new products. Converting legacy products to use Windows Installer has its' own set of challenges.

I would be happy to discuss component registration and our approach to this whole subject, but I imagine that most of my comments would be of no interest to the forum in general. If you would like to continue this on an email thread, please drop me a message at my email address (in my profile).

Regards,
SteveP

eapy

SteveP