A strange problem happens when two features share a COM-server component.
Say, we have a COM server component (say COM.EXE) used in two independent features (F1 and F2). All the COM-related data of the COM.EXE is orderly stored into the Class table (together with ProgId, AppId, and TypeLib tables and some additional registry records go into Registry table). Although I don't need any advertising, the MSDN states that I have to specify an OLE-advertizable feature in the Feature_ field of the Class table. We cannot squeeze both F1 and F2 there, so we choose, for example, F1.
Now if the user selects only F2 for installation, the COM.EXE is installed -- ok, all the related data from the Registry table get written to the registry -- ok, but THERE HAPPENS NO COM-SERVER REGISTRATION.
Is this an MSI 2.0 bug or a feature? Is there any workaround?
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.
COM server registration
Started by
mstone
, Aug 19 2004 09:20
9 replies to this topic
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 19 August 2004 - 11:02
While I personally find this quite annoying, accoring to Microsoft this is "by design". The workaround would be to use the registry table instead (which defeats the purpose of the Class tabel, but at least it works)
Stefan Krüger
InstallSite.org twitter facebook
mstone
-
- Members
- 20 posts
Posted 19 August 2004 - 12:25
That's what I first thought of, too. The problem is with type libraries: they get registered not by simply writing something into the registry, but with a RegisterTypeLib Win32 API call. Ironically, the call does wind up writing something into the registry, but we don't know a priori what exactly.
Actualy, I've played with regmon and what I'm doing right now is writing an utility that digests a type library and creates a set of registry records that effectively registers the type library. Then I'm going to automatically run this utility every time making an installation package to add the records to the Registry table.
Actualy, I've played with regmon and what I'm doing right now is writing an utility that digests a type library and creates a set of registry records that effectively registers the type library. Then I'm going to automatically run this utility every time making an installation package to add the records to the Registry table.
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 19 August 2004 - 14:12
I may be totally off the target, but I think I read that the problem is the windows installer database schema which does not allow a many to many connection between a COM file and features. Is it acceptable to add the COM component to a separate, parent feature?
Regards
-Stein Åsmul
-Stein Åsmul
mstone
-
- Members
- 20 posts
Posted 19 August 2004 - 15:07
Perhaps that would help, but it is acceptable only if the two features do have something in common from the end-user's point of view. Otherwize the end-user will have to face an unnatural feature tree where two unrelated features have "artificial" parent feature.
Zweitze
-
- Full Members
- 522 posts
Posted 20 August 2004 - 09:20
As a workaround, try this:
Create a MSM with the server component(s), class information, ProgId etc. Merge the MSM to both features.
Create a MSM with the server component(s), class information, ProgId etc. Merge the MSM to both features.
Petch
-
- Members
- 35 posts
Posted 25 August 2004 - 10:55
I agree with Zweitze. You should have the COM server on a feature that gets installed every time regardless of what the end user chooses.
mstone
-
- Members
- 20 posts
Posted 26 August 2004 - 17:20
| QUOTE (Petch @ 2004-08-25 09:55) |
| I agree with Zweitze. You should have the COM server on a feature that gets installed every time regardless of what the end user chooses. |
This solution won't work if the product (and the feature tree) is big and the COM server needs to be installed only for _some_ _unrelated_ features. "Some" means I can't hide the COM server into, say, an invisible required feature and have it always installed. The COM-server exe-file together with its dlls and other dependents weighs around 30MB -- it's not acceptable to install it even if it's not needed. "Unrelated" means I can't make a common parent feature feature for these features.
mstone
-
- Members
- 20 posts
Posted 26 August 2004 - 17:23
| QUOTE (Zweitze @ 2004-08-20 08:20) |
| As a workaround, try this: Create a MSM with the server component(s), class information, ProgId etc. Merge the MSM to both features. |
I don't have much experience with creating merge modules but I doubt this solution will work. Merging a merge module effectively means filling in the MSI tables with the data extracted from the merge module. And the Class table still has only one 'Feature' field, regardless of what we fill it in with
mstone
-
- Members
- 20 posts
Posted 26 August 2004 - 17:33
I'm glad to close the topic with good news. I developed a simple utility to extract the registry records from type libraries, so the problem is now solved by moving all the registration information to raw Registry table.
The only deficiency of this solution is losing COM-server-based advertising, but I didn't need it anyway.
Thanks to to Stefan Krueger for firmly dotting the i-s and crossing the t-s and to everybody for participation and willingness to help!
Should anybody have any questions on extracting the information from type libraries -- welcome!
The only deficiency of this solution is losing COM-server-based advertising, but I didn't need it anyway.
Thanks to to Stefan Krueger for firmly dotting the i-s and crossing the t-s
and to everybody for participation and willingness to help!Should anybody have any questions on extracting the information from type libraries -- welcome!