A long time ago, I created a "suite" of windows forms apps in VB6. I was recently asked to create a MSI installer for these program, which I did using VS 2008. Some of these programs have references to third-party .OCX files. Therefore, I manually added these to the included files in the setup project and in the "File System on Target Machine" section, I specified the "System Folder".
When I tested the installation on a non-64-bit machine, everything went well: the OCX files were installed in the C:\Windows\System32 folder and they were correctly registered during installation. The installed programs all came up correctly.
Then we tried installing it on a 64-bit machine (Win 7). If I left the OCX files in the "System Folder", they were installed in the 64-bit system folder (something like C:\Windows\Systemwow64 (?). While there were no errors during the installation, when I tried to run the programs, I got errors about those files not being correctly registered. For the record, these OCX files are old - so they belong in the 32-bit system folder.
Next, I tried to "force" the files where I wanted them by creating a custom folder in the installation called "System32Hardcode" where the DefaultLocation property was set to "[WindowsFolder]\System32" (note the lack of brackets around System32). When I ran this install on the 64-bit machine, I got errors like this:
Module C:\Windows\System32\filename.OCX failed to register. HRESULT -2147024700. Contact your support personnel.
Since they didn't register correctly here, the programs did not run properly.
How can I handle this? I really don't care what folder they end up in, but I need them to be correctly registered for my programs to work. I messed around with "Custom Actions" in the install project, but I could not figure out how to manually register the files.
I would greatly appreciate any suggestions or comments. Thank you!
That error message seems more serious than just missing registration. It's "The operating system cannot run this application program. ". Have you by any chance got some 16-bit code in this picture?
I don't think any of the OCX files are 16-bit. I know that my applications are 32-bit. Is there a way to determine that? As I mentioned, these are third-party OCX files - I am not sure exactly how/when they were made.
Thanks for your fast reply!
You can change the project target platform to X86.
Right click solution->Configuration Manager -> change the project target Platform to X86
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Thanks for your reply. Unfortunately, when I go to the Configuration Manager, I am not allowed to change the target platform. If I double-click on the field, nothing happens - no error message, no selection. I cannot even enter the "X86" manually.
I would appreciate any further suggestions. Thank you!
Well, I am having the exact issue on my project. I was working on the 32 bit setup project all the while and I had no issues. Now, I am trying to migrate to 64 bit and I just realized that I need to copy the files to the System (64 bit) Folder instead of the System Folder.
But this throws a series of error messages which says something about not being able to register a few .ocx and .dll files. I can of course click on ignore and continue installing. But post installation, my application fails.
I really need to get this sorted. Is there any way I can register the files manually using a custom action script ?
I forgot to post back with my eventual "resolution". Unfortunately, I never could get this to work properly, so I switched to creating the installation program using InstallShield. The installation did the same thing (copied the OCX files to the System32 folder), but it correctly registered them so my programs worked.
I realize that this is not really a "solution" - it is a workaround (one that may be completely unusable for you), but I thought I would post it just to close the loop.
Sorry I couldn't be more helpful....
Thanks Loki70. Appreciate.
I thought this could be something do with the dll files itself. I realized that some of the dll files had to be placed in the SYSWOW64 directory to complete registeration. I figured these were 32 bit dll files a little later. This did the trick for me. But there are some more dll files that are still giving me that error. But these are sort of inconsequential in my project for now. I might have to re-visit them again.
Now that you are saying that it works on Installshield, I sort of need to look at this more closely.
Thanks once again,
- Proposed as answer by 9gwcycn Friday, July 09, 2010 4:53 PM
I resolved those issues by installing in the Win 7 Virtual XP machine. I build the installer with IS 9 Express.
You have to be sure to set the properties of the desktop icon properly : XP Compatibility mode, run as administrator, otherwise the user has to manually start the VM.
This does require a hardware accelerator which seems to be a problem for some low-end laptops.
Part of the confustion around the SysWow64 directory... that is where 32 bit files go.
If a 32 bit process "asks" to see the c:\windows\System32 directory, they would see C:\Windows\SysWow64. It's partly frustrating as you would think the 64 bit files would go into System64 or something... but I can see why they probably did that. So many programmers hard coded the 32 bit path and probably a lot of other "compatibility" reasons.
My guess would be that some files made it into System32, the ocx is in Syswow64.