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
- :
- COM Extraction not working
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
‎Jul 12, 2007
09:29 PM
COM Extraction not working
Please excuse my ignorance on COM Extraction.
I have a DLL that needs com extraction. When I build my project I am getting the following warnings:
The first two dependencies mentioned are in fact listed and installed to the same directory as the Hcn.EftposEclaim.Messages.dll_TEST component.
I do not know what the thrid file is at all!
I assume the com won't extract because of the missing dependencies.
When I install this build onto a test environment, the com information has not been extracted (no shock seeing as it wasn't extracted in the build either). However, if I run regasm manually, the com extracts no problems.
What has gone wrong? Why can I do this manually but I can't seem to get the automated installshield feature working?
I have a DLL that needs com extraction. When I build my project I am getting the following warnings:
ISDEV : warning -6248: Could not find dependent file Hcn.EftposEclaim.Utils, or one of its dependencies of component Hcn.EftposEclaim.Messages.dll_TEST
ISDEV : warning -6248: Could not find dependent file Hcn.Translator, or one of its dependencies of component Hcn.EftposEclaim.Messages.dll_TEST
ISDEV : warning -6248: Could not find dependent file nunit.framework, or one of its dependencies of component Hcn.EftposEclaim.Messages.dll_TEST
The first two dependencies mentioned are in fact listed and installed to the same directory as the Hcn.EftposEclaim.Messages.dll_TEST component.
I do not know what the thrid file is at all!
I assume the com won't extract because of the missing dependencies.
When I install this build onto a test environment, the com information has not been extracted (no shock seeing as it wasn't extracted in the build either). However, if I run regasm manually, the com extracts no problems.
What has gone wrong? Why can I do this manually but I can't seem to get the automated installshield feature working?
(12) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2007
09:38 PM
If you try doing COM EXtract on A.DLL and A.DLL has a dependency on B.DLL and B.DLL is not in the LoadLibrary path, it will fail because the DllRegisterServer() function in A.DLL will never run.
Try running Depends.exe to identify your missing libraries. Also consider extracting the COM data of your key file once instead of at build time to prevent upgrade problems. Extract at build should be reserved for situations where you only support major ( or no ) upgrades and your interfaces frequently change in your COM servers.
Try running Depends.exe to identify your missing libraries. Also consider extracting the COM data of your key file once instead of at build time to prevent upgrade problems. Extract at build should be reserved for situations where you only support major ( or no ) upgrades and your interfaces frequently change in your COM servers.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2007
09:40 PM
Actually I jus noticed the regasm reference.... don't use COM extraction. Set the components .NET Scan At Build property to Properties Only and the .NET COM Interop property to Yes.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 12, 2007
10:04 PM
Fabulous instructions. Thanks! All working.
Can you possibly explain what this bit means please?
.NET Scan At Build property to Properties Only
.NET COM Interop property to Yes
Just briefly if that's possible, or send me somewhere I can read about it? I like to understand what I've changed, it's the only way to learn.
Can you possibly explain what this bit means please?
.NET Scan At Build property to Properties Only
.NET COM Interop property to Yes
Just briefly if that's possible, or send me somewhere I can read about it? I like to understand what I've changed, it's the only way to learn.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 13, 2007
11:11 AM
That's a lot of ground to cover. :cool:
COM and .NET COM Visible are somewhat different concepts that result in the ability to instantiate a COM server. COM extraction uses LoadLibrary and then call's the DLL's DllRegisterServer() function to spy on what the function would have done. Then it authors MSI tables to mimic this behavior.
But a VB.NET/C# assembly isn't WinPE code so it can't be directly called like that. RegAsm does a similar concept only it uses reflection to determine the COM registration needs of the ComVisible(true) class. InstallShield has written a similar method but instead of writing to a reg file, it writes directly to the MSI tables to teach MSI how to register your assembly for interop.
These methods are better then calling regsvr32 or regasm because now MSI understands your COM server / Interop Class better and can better install, uninstall and repair it.
Rob mensching has a good article explaining all of this:
http://blogs.msdn.com/robmen/archive/2004/04/28/122491.aspx
Buried in the XML you'll see this component element:
You'll note that essentially he's doing the same thing as InstallShield. He's setting the File@Assembly to .NET ( equivilant to Properties Only ) the File@AssemblyRegisterComInterop to Yes which is the equivilant to True.
Of course the reason I like InstallShield is I don't have to memorize all of this XML stuff. I just right click | new component, add file, set keyfile, set two dropdowns and move on........
COM and .NET COM Visible are somewhat different concepts that result in the ability to instantiate a COM server. COM extraction uses LoadLibrary and then call's the DLL's DllRegisterServer() function to spy on what the function would have done. Then it authors MSI tables to mimic this behavior.
But a VB.NET/C# assembly isn't WinPE code so it can't be directly called like that. RegAsm does a similar concept only it uses reflection to determine the COM registration needs of the ComVisible(true) class. InstallShield has written a similar method but instead of writing to a reg file, it writes directly to the MSI tables to teach MSI how to register your assembly for interop.
These methods are better then calling regsvr32 or regasm because now MSI understands your COM server / Interop Class better and can better install, uninstall and repair it.
Rob mensching has a good article explaining all of this:
http://blogs.msdn.com/robmen/archive/2004/04/28/122491.aspx
Buried in the XML you'll see this component element:
You'll note that essentially he's doing the same thing as InstallShield. He's setting the File@Assembly to .NET ( equivilant to Properties Only ) the File@AssemblyRegisterComInterop to Yes which is the equivilant to True.
Of course the reason I like InstallShield is I don't have to memorize all of this XML stuff. I just right click | new component, add file, set keyfile, set two dropdowns and move on........
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 13, 2007
01:05 PM
I am also having issues extracting COM information from IS 2008. There seems to be some issue with this that I consider a bug.
I have the same project opened in IS 2008 and IS 12. I perform the COM Extraction on the same component and in IS 12 everything is extracted correctly, but in IS 2008 it extracts everything except for the Type Libraries.
Now these are all on the same machine and all dependency files are where they should be, otherwise the IS 12 component COM Extraction would have failed.
So I manually entered the missing Type Libraries in the IS 2008 project, but as soon as I do a refresh COM information then the Type Libraries entry will be removed.
So what is IS 2008 missing that works for IS 12????
Thanks,
I have the same project opened in IS 2008 and IS 12. I perform the COM Extraction on the same component and in IS 12 everything is extracted correctly, but in IS 2008 it extracts everything except for the Type Libraries.
Now these are all on the same machine and all dependency files are where they should be, otherwise the IS 12 component COM Extraction would have failed.
So I manually entered the missing Type Libraries in the IS 2008 project, but as soon as I do a refresh COM information then the Type Libraries entry will be removed.
So what is IS 2008 missing that works for IS 12????
Thanks,
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 13, 2007
01:25 PM
Maybe the filters.xml is getting in the way. Have you tried C:\Program Files\Macrovision\IS2008\Support\RegSpyUI.exe?
BTW, Mike Marino is the man when it comes to this subject...
BTW, Mike Marino is the man when it comes to this subject...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 13, 2007
01:38 PM
Actually after a little more looking around I found the thread about Microsoft stating the best practices was to place the Type Libraries information in the Registry Table instead of the Com Extraction table. So I checked and sure enough the Type Libraries information was there.
I have not yet tested the install, as I am only doing a side by side comparison to look for differences and therefore that was why I noticed the difference when the Type Libs information did not show up.
When I am done the whole install then I'll have it tested on a clean machine to see if the Com Extraction does still work correctly.
Thanks,
I have not yet tested the install, as I am only doing a side by side comparison to look for differences and therefore that was why I noticed the difference when the Type Libs information did not show up.
When I am done the whole install then I'll have it tested on a clean machine to see if the Com Extraction does still work correctly.
Thanks,
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 13, 2007
01:58 PM
Microsoft or Rob Mensching? ( RobMen != Windows Installer Team )
FWIW ICE33 still says you should use the TyleLib table over the Registry table. Rob disagrees and InstallShield is caught in the middle wondering..... well I suppose I shouldn't speak for InstallShield.
Going either way won't break Vista Certification so I really don't care any more. Specially since I'm all .NET and I don't have to worry about COM anymore anyways...
FWIW ICE33 still says you should use the TyleLib table over the Registry table. Rob disagrees and InstallShield is caught in the middle wondering..... well I suppose I shouldn't speak for InstallShield.
Going either way won't break Vista Certification so I really don't care any more. Specially since I'm all .NET and I don't have to worry about COM anymore anyways...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 13, 2007
02:03 PM
Well if it works the default way in IS 2008 then fine, but if not then I can get back to the old method by using the instructions in the KB articale Q113259
So hopefully things work properly and I do not have to go an change things to make it work....
So hopefully things work properly and I do not have to go an change things to make it work....
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 16, 2007
09:50 AM
Christopher Painter wrote:Both, in this case. See the TypeLib table MSDN topic's remarks. You're right that ICE33 hasn't been updated for this yet, and I certainly can't say if it will be.
Microsoft or Rob Mensching?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 16, 2007
10:08 AM
Thanks for pointing that out. The latest COM best practices all become a blur after awhile. That's why I'm glad I have InstallShield.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 17, 2007
01:11 PM
Off the topic question Chris, but have you heard anything about the new installer package InstallAware?
I am doing research in to other install packages and I am basically only comparing the most popular ones, which are InstallShield, Wise and then I also found InstallAware and Ghost.
Do you happen to have an opinion on which is the best to work with, which is good for administation push, less error prone, ease of use, ...etc?
If you have an information about these could you let me know?
Thanks,
I am doing research in to other install packages and I am basically only comparing the most popular ones, which are InstallShield, Wise and then I also found InstallAware and Ghost.
Do you happen to have an opinion on which is the best to work with, which is good for administation push, less error prone, ease of use, ...etc?
If you have an information about these could you let me know?
Thanks,
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)