3 replies to this topic

[Scott Mayham]

I'm working on an installation for a product of ours.  It consists of a "client" glob, and a "server" glob.  In actual use, the client is also installed on the same box as the server, so I've structured the setup with two Features: "Client-Only" and "Client-Server".  The Client-Only feature has all of the stuff to run the client, including some DLLs (each in it's own Component, set to Shared, [SystemFolder], and ExtractAtBuild). The Client-Server feature has all of the stuff to run the Server, PLUS all of the components which are members of the Client-Only feature.

When the setup is installed, the Client-Only feature installs just fine, including the registrations of the DLLs.  When the Client-Server feature is installed, all of the files are delivered, and there are no errors reported during the installation. BUT not all of the registration data from the DLLs (notably, the TypeLib stuff) gets into the registry, and the application fails.  If I then go and register the DLLs manually using RegSvr32, all is well.

I got curious, and looked at my project's .MSI file with ORCA, and was amazed to find that the TypeLib table associates each value NOT to the component containing the DLL, but to the Feature containing the Component.  And, sure enough, the Feature to which these DLLs were associated was "Client-Only", which I assume is the reason why that Feature is the only one which worked.

The inference seems pretty strong that, with the way I've structured this setup, only the Client-Only feature will get the TypeLib data into the registry.  Have I missed something? Are DLLs restricted to being a member of only one Feature, for purposes of registration?  Or, can I create additional entries in ORCA (or, better, in the Power Editor) to form additional associations of these DLLs with other Features?  Has anyone navigated this swamp?

BTW, I'm using ISWI 2.03.  

Thanks,

[Leigh Ravenhall]

If I remember correctly, I think the registration details are associated with the feature to allow support for advertisment.  Not 100% sure, so if I'm wrong, please feel free to correct me.

I'm curious about the way you divided your software into features.  Wouldn't it have been more appropriate to have a client feature and a server feature.  Then, if the machine is going to be installed as a client/server, you would just install both features.

[Scott Mayham]

Thanks, Leigh, for your quick reply.

My choice of feature structure was an attempt to accomodate to wishes of our Product Management people, who wanted 2 choices presented to our customers: Install everything or just the Client.  And, yes, it appears that I'm going to have to restructure things in the manner you suggest, so that the DLLs are members of just one Feature.  

In the short term, I'm going to attempt a quickie fix, in which I'll change the registry settings of the DLLs' Components from "Extract at Build" to "Self Register".  In this way, I hope to sidestep the .MSI table limitation, while preserving the outward appearance of the installation (the tech writers have already documented it).  Logo compliance is not yet a big issue for our customers, so that's a non-issue for now.

Looking down the road, however, I know that my problem will reappear.  The present product only supports one back-end database (DB2 on iSeries), but support for NTier (Oracle and SQL) is coming soon.  Then instead of 2 Features, I'll have 4: a client and a server for each of two kinds of back-ends.  So, even after I repackage this current setup so the DLLs are members of only the Client Feature, I'm back in the swamp again when I have to support 2 Clients.

Which leads me to some unplowed ground - suppose I make a merge module for these DLLs.  Can't I successfully  associate a MM with as many features as I want to? I'm wondering if this would be a good general solution - and one of the reasons that Microsoft seems to depend so heavily on them?

Let me know your thoughts.

Thanks,

[hteichert]

The problem of the association of TypeLib info (for COM it's the same) with features and not components is by design (error) in Microsoft installer. Using merge modules doesn't help out of this, because MSMs only contain components - not features!
The basic idea of Microsoft installer of a setup with features as the view of the user and components as the view of developers was really good, but dies due to these restrictions.
Imho the only way to solve this association probem, is to look for a feature structure that only connects a component containing the "problem" dll to exactly one feature.
For your problem with different clients/servers for different database connections (i got the same situation with connections to MS SQL, IBM DB2 and Oracle) I would use a structure like:
+-- Server
!   +--MS SQL
!   +--IBM DB2
+--Client
    +--MS SQL
    +--IBM DB2
Another way would be an own dialog box with radio buttons to allow the selection of ClientA, ClientB, ... and setting the feature installlevels of the features containing the needed components via MsiSetFeatureState in CustomActions.