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
- :
- Re: COM Extract at Build not working if DLL is not registered on build server
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
‎Sep 19, 2013
12:49 PM
COM Extract at Build not working if DLL is not registered on build server
Hi there,
I am working on a Basic MSI project with IS 2012 Spring.
Our installation package must install a COM DLL on the target PC and register it.
So until recently I only set the "COM Extract at Build" to "Yes" and it did its magic. It extracted the corresponding COM entries in the Registry table, and the installed application ran smoothly.
But we recently upgraded our build servers, and we have got one that we have never used to actually build our application. Its only purpose it to build the installation package with IS 2012 Spring Standalone Build. So, the COM DLL has never been registered on this server.
We found out that the "COM Extract at Build" does not properly extract all the entries to the Registry table when building the installation package on this server. Some entries are missing, while other contain some wrong GUID's.
If we build the installation package on a server where the DLL was registered, all the COM info is correctly extracted.
So, here are my questions:
I am working on a Basic MSI project with IS 2012 Spring.
Our installation package must install a COM DLL on the target PC and register it.
So until recently I only set the "COM Extract at Build" to "Yes" and it did its magic. It extracted the corresponding COM entries in the Registry table, and the installed application ran smoothly.
But we recently upgraded our build servers, and we have got one that we have never used to actually build our application. Its only purpose it to build the installation package with IS 2012 Spring Standalone Build. So, the COM DLL has never been registered on this server.
We found out that the "COM Extract at Build" does not properly extract all the entries to the Registry table when building the installation package on this server. Some entries are missing, while other contain some wrong GUID's.
If we build the installation package on a server where the DLL was registered, all the COM info is correctly extracted.
So, here are my questions:
- Is that a known issue?
- Is there a way to make this work without registering the DLL on the build server?
- I thought of setting the DLL file to self-register, but it doesn't work. It displays an error message "Error 1904. Module C:\Program Files (x86)\My Company\My Product\MyCOM.dll failed to register. HRESULT -2147220473. Contact your support personnel.".
If I register the DLL by hand with regsvr32, it works fine.- How does Self-Reg differ from regsvr32?
- How does Self-Reg differ from regsvr32?
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 20, 2013
04:57 AM
Hi, there are more ways to register com in IS.
They've recently created whitepaper on this topic http://blogs.flexerasoftware.com/installtalk/2013/07/a-word-about-seemingly-hung-com-extraction-processes-by-josh-stechnij-senior-software-engineer-com-extraction-was-originally.html
They've recently created whitepaper on this topic http://blogs.flexerasoftware.com/installtalk/2013/07/a-word-about-seemingly-hung-com-extraction-processes-by-josh-stechnij-senior-software-engineer-com-extraction-was-originally.html
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 29, 2013
02:55 AM
Hi there,
Thanks for the link Marek22! I did a few tries with the UseAPIRegistryHooks registry value, and it helped to point me in the right direction.
So, it took me a very long time to nail that one down. With the help of Tech Support, I finally managed to isolate the problem by following this procedure (in a VM)
From there, I analyzed what happened in the Registry when starting Visual Studio for the first time. When starting VS (not launching it as Administrator), it creates some user-specific registry entries under the following keys:
Once these entries exist, the COM extraction at build no longer works in the same way, and the resulting Registry table is erroneous.
If you delete (or rename) the above registry keys, the COM extraction at build works fine again.
So, it looks like a bug in InstallShield 2012 Spring SP1 to me.
And it has nothing to do with registering my COM server on my development machine. I could register or unregister my COM server on my machine, the COM extraction was still erroneous.
So the title of this thread is a bit misleading...
Funnily enough, this issue seems to be fixed in InstallShield 2013 SP1.
What I would still like to know is:
Thanks for the link Marek22! I did a few tries with the UseAPIRegistryHooks registry value, and it helped to point me in the right direction.
So, it took me a very long time to nail that one down. With the help of Tech Support, I finally managed to isolate the problem by following this procedure (in a VM)
- Install Windows 7 x64
- Install Visual Studio 2010 and its SP1, but do not start Visual Studio yet.
- Install InstallShield 2012 Spring with its SP1
- Build the affected MSI package --> The COM extraction works fine.
Start Visual Studio. When started for the first time, it asks what sort of project it will mostly be used for (Choose your default environment settings). In my case, I usually choose Visual C++ Development Settings.
Then Visual Studio loads the user settings. - Build the affected MSI package --> The COM extraction is erroneous.
From there, I analyzed what happened in the Registry when starting Visual Studio for the first time. When starting VS (not launching it as Administrator), it creates some user-specific registry entries under the following keys:
- [HKEY_CURRENT_USER\Software\Classes\Interface]
- [HKEY_CURRENT_USER\Software\Classes\TypeLib]
- [HKEY_CURRENT_USER\Software\Classes\Wow6432Node]
Once these entries exist, the COM extraction at build no longer works in the same way, and the resulting Registry table is erroneous.
If you delete (or rename) the above registry keys, the COM extraction at build works fine again.
So, it looks like a bug in InstallShield 2012 Spring SP1 to me.
And it has nothing to do with registering my COM server on my development machine. I could register or unregister my COM server on my machine, the COM extraction was still erroneous.
So the title of this thread is a bit misleading...
Funnily enough, this issue seems to be fixed in InstallShield 2013 SP1.
What I would still like to know is:
- Was that a known issue in IS 2012 Spring SP1?
- Is there a hotfix available?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 03, 2013
02:49 PM
There was an issue with the newer style kernel mode COM extraction in IS 2012 that would cause COM data to be extracted incorrectly if any keys were present under the Wow6432Node key in HKCU\Software\Classes. The issue was reported in work order IOA-000066199 as a failure to correctly extract proxy/stub related information.
No hotfix was made available for IS 2012. However, it should be possible to copy the kernel filter drivers from IS 2013 into the System folder for IS 2012 (ISRegFlt.sys and ISRegFlt64.sys from \Program Files\InstallShield\2013\System; it may be necessary to reboot the machine after copying the files to ensure they are reloaded if COM extraction was already used). The code changes were self contained to the registry filter code in the drivers so no other files should be needed. Please note, however, that we have not tested using the IS 2013 filter binaries with IS 2012.
No hotfix was made available for IS 2012. However, it should be possible to copy the kernel filter drivers from IS 2013 into the System folder for IS 2012 (ISRegFlt.sys and ISRegFlt64.sys from \Program Files\InstallShield\2013\System; it may be necessary to reboot the machine after copying the files to ensure they are reloaded if COM extraction was already used). The code changes were self contained to the registry filter code in the drivers so no other files should be needed. Please note, however, that we have not tested using the IS 2013 filter binaries with IS 2012.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 03, 2013
03:01 PM
As a follow up to my previous reply, using the registry filter driver binaries from IS 2013 may not work correctly. One reason no hotfix was made available for this issue in IS 2012 is there are a number of other changes included in the driver, including changes to how multiple concurrent build processes are handled. How the registry filter driver listens for COM extraction requests changed between IS 2012 and IS 2013 as part of these changes.
While attempting to use the IS 2013 driver binaries with IS 2012 should not cause any adverse effects, it is possible that no COM information will be extracted. As such, we would either recommend migrating to IS 2013 if possible, or, change the COM extraction method in use as highlighted in the COM extraction whitepaper previously mentioned.
While attempting to use the IS 2013 driver binaries with IS 2012 should not cause any adverse effects, it is possible that no COM information will be extracted. As such, we would either recommend migrating to IS 2013 if possible, or, change the COM extraction method in use as highlighted in the COM extraction whitepaper previously mentioned.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 04, 2013
07:16 AM
Hi Josh,
Thanks a lot for your answer!
I wish the support technician had escalated the corresponding incident to you. It would have saved me a long time finding a way to isolate this bug.
But there is something I have missed there: according to the release notes of IS 2012 Spring SP1, this bug should have been resolved in the version I'm using.
Thanks a lot for your answer!
I wish the support technician had escalated the corresponding incident to you. It would have saved me a long time finding a way to isolate this bug.
But there is something I have missed there: according to the release notes of IS 2012 Spring SP1, this bug should have been resolved in the version I'm using.