COM extraction from .ocx .exe does nothing or is incomplete

[GlenT]

As I said, all our "Extract registration info from native library" option does is to simulate the COM registration and sniff the registration data.

I'm not understanding the difference between what your API does and calling Regsvr32 in a custom action. They appear to do the same thing. Why would your procedure fail and a custom action using Regsvr32 (which is essentially the same) succeed? You have our objects. Have you tested creating a custom action to verify that it works?

Regarding hand editing of the COM and registry pages, we are aware that adding items manually to the AI COM page does not generate the required registry entries, which must be done separately. At this point, it appears impossible to enter all of the required data by hand successfully. You seem to be confirming this is the case.

As a gesture of good will, and in recognition of the fact that our company has been inconveniced by these AI COM extraction issues for almost three years, we would like to suggest that AI should at least test whether or not a custom action using Regsvr32 would work and then provide us with the code template so that we could modify it as necessary. The benefit for AI is that they would have a proven workaround to suggest to other Embarcadero clients who find themselves in a similar position.

It goes without saying that our company has spent many unproductive hours diagnosing these and other issues for AI at our own expense. Several of these issues remain unfixed to this day, such as the internal AI code signing engine timing out and the lack of AI support for Authenticated Users (which is provided by InstallShield Express). As a small business with a single infrastructure programmer, we are reluctant to delay our current development work further while experimenting with developing a DLL to do this, unless we know it will succeed.

BTW, it should be recognized that there are fundamental differences in the approaches to COM registration that we have discussed. ISX does a extraction at build time, which means that the COM data that is extracted is always refreshed at build time. AI (when it worked) did a one-time extraction and placed COM data into the AI project. The advantage to this (and our saving grace at this point) is that once the data is correct in the AI project, it is not subject to change unless we modify our COM objects and do another extraction.

However, your proposed solution would rely on self-registration at install time via a custom action and Regsvr32. The native mechanism for this (self registration) was deemed unsafe by Microsoft several years ago and dropped. Using Regsvr32 in a custom action defers extraction of COM data until the actual install takes place. This means that it is subject to whatever variances are in play on every one our client machines -- meaning that its success is subject to the version of windows, the current windows updates and whatever security policies are in place on each individual client computer.

So, rather than writing a known set of verified COM data consistently at each installation, the custom action method is subject to potential issues that could vary from one machine to the next -- a potential support nightmare -- as demonstrated by your API issues.

[Daniel]

Hello Glen,

Please give us some time so we can prepare a sample project which implements the custom action registration approach.

Thank you for your patience.

All the best,
Daniel

[GlenT]

Thank you.

[codesynergy]

I want to chime in here, in hopes that this COM extraction issue might be bumped up in priority.

Our company uses a lot of COM dlls/exes (.Net and native). A while ago, I reported an issue with COM extraction here: http://www.advancedinstaller.com/forums ... =2&t=30016
In summary, there were issues with registry extraction (Windows 7 64bit):
- Some registry data was was missing.
- Some registry data was not extracted correctly.
- My machine was sometimes being corrupted.

I have received a response that the issue was fixed (in 12.0 I think?), but I've since moved on to other things, and I have not had time to re-test yet. After reading this post, I'm not 100% confident that the issue is indeed fixed, which worries me.

I haven't had a chance to thoroughly compare the extraction differences between InstallShield, AI, and heat (the wix tool). But, I'm really not confident that any of them are 100% reliable. However, AI's extraction is, by far, the worst.

In InstallShield, we do not use the COM extraction feature, since it also did not seem to work (though, it's a very old version of IS). Instead, we generate registry files containing our COM registry data (using our own process), and we use InstallShield's "REG File To Merge At Build" feature. This allows us to merge our registry files into components at build time. This gives us a greater amount of control over the registry content that goes into the installation.

My main issue here (with AI), is the lack of a method to import the registry data from a registry file into a component. There is an option to import registry data into a feature, but you cannot import registry data directly into a component (COM data should be attached to the associated .exe/dll). So, in our case, we generate the COM data into registry files using our own process. However, we cannot import these registry entries into our AI project, like we can in InstallShield.

Some suggested work-arounds have been:
- Manually creating the registry entries. This is only viable for small projects. Our project has thousands of COM registry entries, and it is not practical to manually create these in our project.
- Self registration - Microsoft says not to use this option. Also, not sure if this works for both native and .Net.
- Running a custom action that runs regsvr32/regasm. The issue here is, the installer isn't "aware" of the registry data it's creating. I'm not sure of all the issues this might create.

In my opinion, since COM extraction seems to be ... not reliable, I would first focus on adding a feature to import registry files into components. This would be a good work-around, allowing users to generate the registry data using a third-party tool (or their own tool) and import it into their project.
I've actually started working on a script to import registry files into AI (into components). My script seems promising so far, but, if it doesn't end up working, we might have to stick with InstallShield. Programs won't run without their registry data.

To summarize my thoughts:
- COM extraction doesn't seem to work well in AI (and maybe heat/IS also).
- There isn't a good work-around in AI. So, how do you get your registry data into your project?
- One (or both) of the following features should be implemented:

• - Add an option to import a registry files into a component. Since you can already import a registry file into a feature, it seems like it wouldn't take too long to implement this.
  - Add the "REG File To Merge At Build" option InstallShield has.

[Daniel]

Hello,

@Glen: I've sent you by e-mail a sample project created with Advanced Installer 12.0 which uses the custom action approach to register and unregister your DLL and EXE COMs. I'll write a small overview here for forum users.

Basically to register/unregister a DLL COM you can use the regsvr32 tool as described in the "Regsvr32" article. For EXE COMs you should be able to register/unregister them by calling them with /regserver and /unregserver commands.

So, considering your case (we have 2 EXE COMs and 3 OCX/DLL COMs) you can create 4 BAT file as it follows:
1. registerEXE.bat

Code: Select all

%1 /regserver
%2 /regserver

2. unregisterEXE.bat

Code: Select all

%1 /unregserver
%2 /unregserver

3. registerDLL.bat

Code: Select all

regsvr32 /s %1
regsvr32 /s %2
regsvr32 /s %3

4.unregisterDLL.bat

Code: Select all

regsvr32 /s /u %1
regsvr32 /s /u %2
regsvr32 /s /u %3

Next, you should proceed like this:
1.add your EXE and DLL files in "Files and Folders" page
2. add the above BAT files as temporary files in "Files and Folders" page
3. go to "Custom Actions" page and add a "Launch file" custom action, scheduled on install as deferred after Install Execution Stage -> Add Resources" action group, which will launch the " registerEXE.bat" like this:

• File To Launch: [&registerexe.bat]
  Command Line: "[#COM1.exe]" "[#COM2.exe]" <the COM filepaths are passed as parameters, i.e. %1, %2, to the BAT file>
  Hide program's window: checked

4. add another "Launch file" custom action, scheduled on install as deferred after Install Execution Stage -> Add Resources" action group, which will launch the " registerDLL.bat" like this:

• File To Launch: [&registerdll.bat]
  Command Line: "[#COM1.ocx]" "[#COM2.ocx]" "[#COM3.ocx]"
  Hide program's window: checked

5. using custom actions as above you should add another 2 "Launch file" custom actions which will launch the "unregisterEXE.bat" file: 1 custom action scheduled on install as rollback just before the "[&registerexe.bat]" action and, the other scheduled on uninstall as deferred before "Install Execution Stage -> Remove Resources" action group
6. using custom actions as above you should add another 2 "Launch file" custom actions which will launch the "unregisterDLL.bat" file: 1 custom action scheduled on install as rollback just before the "[&registerdll.bat]" action and, the other scheduled on uninstall as deferred before "Install Execution Stage -> Remove Resources" action group
7. build and test the installation

If you are allowed to, please feel free to attach here the "sample.aip" (project file) I sent you.

@codesynergy:

- Add an option to import a registry files into a component. Since you can already import a registry file into a feature, it seems like it wouldn't take too long to implement this.

This improvement is already on our TODO list. I've improved its priority and we'll update this thread when it will be out. Thank you for your feedback.

All the best,
Daniel

[GlenT]

Thanks, Daniel. I will give this a run and see how it works under testing.

Codesynergy, thank you for your insights.

We have embraced AI as a simpler tool that allows us a relatively simple path to maintaining our installers. In a small business environment (where we have no dedicated installation programmers) it is necessary to rely on tools that get the job done without a lot of extra overhead and expertise required.

Our COM registration needs are relatively straight-forward and simple. We have been reliant in the past on the tool to just do what it claim that it will do. What I'm hearing is that, unfortunately, that seems to be a thing of the past.

For us, COM installation has been a bit of a black box. We used to use self-registration, but Embarcadero removed the ability to self-register about 8 or 9 years, apparently at the request of MS. I have my doubts about viability of trying to use Regsvr32 at install time. Your method sounds more attractive.

As I mentioned in a previous post, it would also be useful to have the ability to export COM and registry data from one AI project to another. The ability to export a working set of COM and registry data would allow a backup set to be saved. It would also allow you to use a tool to directly compare the reg data from two different projects to make sure that they are the same, or to highlight differences.

[GlenT]

I set up a test of the AI project that you sent, in which (partially due to laziness) I installed our existing package on a couple of machines, then ran the sample template project that you provided (with some additions) to install and re-register the same objects in a different location, using a different GUID set, which effectively overwrote the registry entries for the full app. Then I ran some tests.

The results were interesting, in that the test objects installed as expected under Win7 Pro 64 bit, but silently failed to overwrite on the WinXP 32 bit test machine entries (did not fail with an error condition). However, when I ran the test uninstall on the WinXP machine, the test installer did remove the full version registry entries that did not belong to it. I then reran the test installer, and this time it did install as expected.

So while the test is a little unfair (overwriting the full installer's reg entries) it did point out the fact that using this approach could have potentially different results under different versions and configurations of Windows on the target computer.

I'll save this method (calling Regsvr32 at install time) as a potential workaround method, but ultimately, I don't think I would deploy it unless I have no other choice.

[GlenT]

After having a done a bit of research on COM extraction tools, I discovered that our own InstallShield Express 2012 license shipped with such a utility. It is called RegSpyUI.exe and is located in the Support folder under the InstallShield installation in Program Files. It can be run as a free-standing Windows GUI program, that allows you to load .EXE, .DLL or .OCX files (individually or in a folder) extract the COM info to a built-in browser (tree view) and then export the data to a .REG file ready for use. And it seems to work for our stuff.

Now I can export the data to .reg files and archive them. I can do file compares on them to see what has changed. And (with the help of the new per-component .REG import feature that AI is reportedly working on) we will be able to import the registry entries into AI projects and easily verify if they are complete.

Now all we need is the new feature, hopefully sooner than later -- not 3 years please!

[GlenT]

For those who are importing .REG files into AI, do you prepare the .REG entries in advance with the AI tokens for path info, such as

Code: Select all

[#FileName.ocx]

or

Code: Select all

APPDIR\BIN\FileName.ocx

or no path info at all? The extraction tool is defaulting to providing the path info to where the object is found in the source folders.

[Daniel]

Hello Glen,

Now I can export the data to .reg files and archive them. I can do file compares on them to see what has changed. And (with the help of the new per-component .REG import feature that AI is reportedly working on) we will be able to import the registry entries into AI projects and easily verify if they are complete.

Now all we need is the new feature, hopefully sooner than later -- not 3 years please!

This improvement has an increased priority and hopefully it will be available soon. I cannot give you any ETA for the moment, but we'll update this thread as soon as it will be released.

For those who are importing .REG files into AI, do you prepare the .REG entries in advance with the AI tokens for path info, such as
CODE: SELECT ALL
[#FileName.ocx]
or
CODE: SELECT ALL
APPDIR\BIN\FileName.ocx

or no path info at all? The extraction tool is defaulting to providing the path info to where the object is found in the source folders.

Edited: It is recommended to use formatted references as you exemplified to set the registry entries from "Registry" page, so that at install time the registry values are resolved to the install path of their referenced files. However, you should not add the above references in the .REG files which are about to be imported; instead you should edit, after the import operation, your imported registry values (in "Registry" page of your setup project) to use these formatted references as you exemplified.

All the best,
Daniel

[codesynergy]

After having a done a bit of research on COM extraction tools, I discovered that our own InstallShield Express 2012 license shipped with such a utility. It is called RegSpyUI.exe and is located in the Support folder under the InstallShield installation in Program Files. It can be run as a free-standing Windows GUI program, that allows you to load .EXE, .DLL or .OCX files (individually or in a folder) extract the COM info to a built-in browser (tree view) and then export the data to a .REG file ready for use. And it seems to work for our stuff.

That is good to hear. I didn't realize the registry extraction tool could be run as a stand-alone app. I wonder if this tool can be run from the command line, so the registry extraction could be automated.

Now I can export the data to .reg files and archive them. I can do file compares on them to see what has changed. And (with the help of the new per-component .REG import feature that AI is reportedly working on) we will be able to import the registry entries into AI projects and easily verify if they are complete.

Now all we need is the new feature, hopefully sooner than later -- not 3 years please!

I think this is the plan for us also.

[GlenT]

The RegSpyUI.exe tool can be run from a command line. In fact, it is the only way to do a folder (as I found out). When run from the GUI, the tool will process a folder and display the results, but will only export the first object. Apparently, though, it will work properly from the command line (but I have not tried it).

Now the downside, the current AI 12.0 does not seem to like the format of the .reg files that RegSpyUI generates for some reason and resfuses to import them. I will look into this further.

Edit: I think that I have figured out why AI did not like the .reg files exported by RegSpyUI. You have to make sure that you check the option to export them in Unicode format. AI does not like them if they are not in Unicode format.

[codesynergy]

Now the downside, the current AI 12.0 does not seem to like the format of the .reg files that RegSpyUI generates for some reason and resfuses to import them. I will look into this further.

You might check the encoding of the registry files. AI seems to require registry files be encoded using "UCS-2 Little Endian". I use notepad++ to convert.

[GlenT]

Now the downside, the current AI 12.0 does not seem to like the format of the .reg files that RegSpyUI generates for some reason and resfuses to import them. I will look into this further.

You might check the encoding of the registry files. AI seems to require registry files be encoded using "UCS-2 Little Endian". I use notepad++ to convert.

You beat me to it

I think that I have figured out why AI did not like the .reg files exported by RegSpyUI. You have to make sure that you check the option to export them in Unicode format. AI does not like them if they are not in Unicode format. RegSpyUI has this as an option in its GUI.

[GlenT]

FYI, here are the command line options for RegSpyUI: