I have 8 TLB, 1 EXE, and 7 DLL files that I am using the COM Extract at Build functionality on. At build time the COM data is extracted from the files without error, however when I check the MSI all of the TypeLib information that is extracted contains hardcoded paths which point to the folder the files were in on the build machine.
When I run the installer on a clean machine these paths find there way into the registry and cause my app to throw errors until I correct these paths in the registry.
What could be causing this? Why does the CLSID section substitute the actual file paths while the TYPELIB section does not? Are the DLL's not designed properly?
That doesn't sound like what should happen. When the COM extraction is performed, the registration will put a raw path in the registry. When we read this, we attempt to detect and replace such paths with ones based on properties or other MSI substitutions that will reflect the actual install path. Can you post an actual example of one of the table entries that still has the raw path as well as the actual location of the file?
(I don't know off hand whether we perform this substitution for all registry entries laid down during self-registration, or whether it's just the set that we know are COM-related paths. I'm hoping an example could let us identify that.)
I opened a support incident (#SIOC-000073352), but will continue this thread as I tend to get faster responses through here.
I attached a REG file that I exported from the MSI that was built from the project. The path to the file on the build machine is listed inside the REG file as D:\\Projects\\IShield\\Installs\\[ CD Images ]\\Pages\\PCD\\pages\\bin\\PagesePages65.tlb" while the path on the target computer is really C:\Program Files\...
I did some more playing around this morning and discovered that if I extract the COM info from inside the IDE everything works as expected, it is only when I extract at build time that there is a problem. In fact, registry keys created under our own key are extracted properly from the IDE while they show up as hard coded paths when Extracted at build time. What would be causing this
I should note that I am running InstallShield 2009 on Vista x65 SP1, and InstallShield 2008 is also installed on this box. Could that be causing this issue?
Apparently I can't upload a REG file. Below is what I copied from the REG file mentioned int he previous post. As previously stated this information was exported form the MSI built from the project with the COM extract at build setting turned on. [CODE]REGEDIT4
[HKEY_CLASSES_ROOT\TypeLib\{3911E92C-0D4C-4BD6-9D19-AA88DE471A87}\6.5\HELPDIR] @="D:\\Projects\\IShield\\Installs\\[ CD Images ]\\Pages\\PCD\\pages\\bin"
[HKEY_CLASSES_ROOT\TypeLib\{3911E92C-0D4C-4BD6-9D19-AA88DE471A87}\6.5\0\win32] @="D:\\Projects\\IShield\\Installs\\[ CD Images ]\\Pages\\PCD\\pages\\bin\\PagesePages65.tlb"
My suspicion is that both of these paths refer to the file (do you have a mapped or subst drive?), but the file figures its own name as one thing, and we figure it as another. Then when it's time for fixing things up, we can't find our path in what it wrote. I could imagine this being exacerbated on a 64-bit machine. Does this still occur if you were to move this file to, e.g., C:\TMP?
The problem was related to the path. When I removed the [] from the path the COM Extration at build time worked fine. Funny how this only affected TypeLib information at build time, and the COM extraction inside the IDE still worked fine.
And here I thought those square brackets might be an obfuscation. If that reproduces in simple tests, it's probably worth looking at and, assuming it's not too crazy (or intentional), fixing.
That said, it sounds like you've got it working now?
Yes, it is working now. Thank you for your help, your suggestion to try another path put me on the right track. I think support is going to create a work order for this.
