This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Does InstallShield treat Primary Interop Assemblies (PIAs) differently?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 31, 2009
06:29 PM
Does InstallShield treat Primary Interop Assemblies (PIAs) differently?
My installer includes various COM DLLs (some directly; some through MSMs). Some are used by mutliple (optional) Features, so they're all in a hidden-required Feature. The generated MSI shows the appropriate Class table rows associated with that Feature. Yay.
An optional, .Net-based Feature needs to make use of the COM classes, so I generated Interop Assemblies. I wanted to create Primary Interop Assemblies (PIAs) for my DLLs...but some of the DLLs rely on Microsoft libraries (MSXML, ADO, etc.). .Net's TLBIMP won't generate a PIA if it would depend on any non-Primary Interop Assemblies. It doesn't seem "right" for me to generate and "publish" a PIA for Microsoft components, so the IAs for my DLLs aren't Primary either.
But...when I built the installer, it seemed to "fault in" the COM DLLs/MSMs when it processed the Interop Assemblies belonging to the optional Feature:
(where MyCompany.VBThing.Interop.dll Component is only used by the optional Feature)
The resulting MSI showed the Class table rows for w/ the DLLs/MSMs "owned" by the optional Feature containing the Interop Assembly! Suddenly my installer only works if .Net is installed and the user selects the optional Feature!
But...when I generated PIAs for the MS pieces and my DLLs which use them, IS builds an MSI w/ the right Feature values in the Class table -- i.e., neither .Net nor optional Feature required to make things work.
Is there another (better?) way out of this? As I said, it seems "wrong" for me to generate PIAs for MS DLLs...but...back in Dec. 2004 (slightly after the Bronze Age?), a Microsoftie seemed to say, "yup - just make your own."
TIA
An optional, .Net-based Feature needs to make use of the COM classes, so I generated Interop Assemblies. I wanted to create Primary Interop Assemblies (PIAs) for my DLLs...but some of the DLLs rely on Microsoft libraries (MSXML, ADO, etc.). .Net's TLBIMP won't generate a PIA if it would depend on any non-Primary Interop Assemblies. It doesn't seem "right" for me to generate and "publish" a PIA for Microsoft components, so the IAs for my DLLs aren't Primary either.
But...when I built the installer, it seemed to "fault in" the COM DLLs/MSMs when it processed the Interop Assemblies belonging to the optional Feature:
Adding merge module 'VBThing DLL' that is a dependency of component 'MyCompany.VBThing.Interop.dll'
Adding file 'VCPlusPlusThing.dll' that is a dependency of component 'MyCompany.VBThing.Interop.dll'
Adding file 'VCPlusPlusThing.dll' that is a dependency of component 'MyCompany.VBThing.Interop.dll'
(where MyCompany.VBThing.Interop.dll Component is only used by the optional Feature)
The resulting MSI showed the Class table rows for w/ the DLLs/MSMs "owned" by the optional Feature containing the Interop Assembly! Suddenly my installer only works if .Net is installed and the user selects the optional Feature!
But...when I generated PIAs for the MS pieces and my DLLs which use them, IS builds an MSI w/ the right Feature values in the Class table -- i.e., neither .Net nor optional Feature required to make things work.
Is there another (better?) way out of this? As I said, it seems "wrong" for me to generate PIAs for MS DLLs...but...back in Dec. 2004 (slightly after the Bronze Age?), a Microsoftie seemed to say, "yup - just make your own."
TIA
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 01, 2009
10:50 AM
If this is just a matter of what InstallShield includes, and where, you might try including the correct files in the right features manually. Then also disable Dependency scanning - set the component for MyCompany.VBThing.Interop.dll to "Properties Only".
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 01, 2009
01:27 PM
That seems to fixed my problem -- thanks.
Out of curiosity...any thoughts on the behavior change between Primary & non-Primary IAs with "Dependencies and Properties?"
Out of curiosity...any thoughts on the behavior change between Primary & non-Primary IAs with "Dependencies and Properties?"
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 02, 2009
01:20 PM
I don't believe InstallShield knows anything about PIAs vs. non-PIAs; they're just all assemblies. So the difference is probably in the assembly itself - what dependencies or references it reports. You might be able to verify this with a tool like .NET Reflector.