Where is the upgrade order form?

[artistscope]

I did resolve this problem by creating a 2nd EXE installer and running it from the SUF9 installer. I could have used SUF for that 2nd installer except that it added more than 5 Mb to the overall file size.

My partner insisted on trying InstallShield but had to upgrade his licence, and after forking out a few hundred dollars, then discovered that the licence he had didn't include 64-bit support and that he had to purchase the Pro version to be able to make 64-bit installers... another $1,000+ upgrade fee! Ordering from a local reseller took a week to get his licence code by email, so all up this was not a lot of fun. Of course my advise to was to get his money back and fast, while I find something better for FREE!

The InnoSetup install maker created that 2nd installer smaller than the OCX it contained, eg: the OCX was 968 Kb and the finished installer finished at only 852 Kb.

This was the only way that I could run and register a 64-bit plugin from a 32-bit installer.

[artistscope]

Yes, I do have it set to 64-bit.

[Ulrich]

The image shows the configuration for a 32-bit MSI package (x86) while the cursor is over the correct option for a 64-bit MSI package (x64) - which is the one you should select.

Ulrich

[artistscope]

Yes, that's exactly how mine is set.

[Ulrich]

So I then tried making a 64-bit MSI installer that ended up at 1 Mb, but it failed to register the OCX when run inside a 32-bit installer.

I suspect that you have built a 32-bit MSI package instead of a 64-bit package. With Windows Installer, Setup Factory and InstallShield, the same rules apply. You won't find a magical solution in InstallShield. The image shows where you would set the platform of the MSI package in a MSI Factory project:



Ulrich

[artistscope]

I'm still in trouble with this. I packaged a 64-bit installer inside the 32-bit installer and the 64-bit OCX self registered ok, but that mini installer ended up at 6 Mb which is way to big. So I then tried making a 64-bit MSI installer that ended up at 1 Mb, but it failed to register the OCX when run inside a 32-bit installer.

A partner is recommending that we switch to InstallShield. What can I do?

[artistscope]

It looks like I can't do what I need to do with the one installer. Sure the one installer can create installers for both platforms, but I am finding that a 32-bit installer cannot self-register a 64-bit OCX and a 64-bit installer cannot self-register a 32-bit OCX, so like in my case where I need to register both types of OCX it 's not possible.

I need to move forward on this so I'll create a second installer (64-bit) to include in the 32-bit installer to complete the task and will look forward to a SUF update that may simplify things.

[artistscope]

We have 3 different projects that need to install both 32-bit and 64-bit OCX and self-register them. Two of the installers are for 32-bit apps and the third is for browser plugins only and installs the OCX. The reason for installing both 32-bit and 64-bit OCX is because users will have both 32-bit and 64-bit version of Internet Explorer and may use both for different tasks.

So the ideal is to use one installer for bot 32 and 64 bit, otherwise it will be too confusing for our users. Can you imagine the average net user deciding whether to install the 32 or 64 bit installer based upon whether they will be using the 32 or 64 bit version if IE when they most don't even know what IE is?

[Darryl]

The method discussed using the plugin was required if you wanted the 32-bit setup to be able to access the 64-bit areas of the operating system. This was a workaround given that previous versions of Setup Factory only generated 32-bit setup files.

Setup Factory 9 is able to generate 64-bit native setups as well as 32-bit setups. The proper thing to do would be to create 2 separate setup files, one for your 64-bit files, and one for your 32-bit files. Using that method keeps the files separate and will be clearer to work with. So to register the file, you just need to check the "Register COM Interfaces" checkbox on the control's properties in your project and it should work as it did for 32-bit setups. You can also maintain both platforms in a single project using build configurations, however it's a little more complicated. You can read about that more in the User's Guide.

It's a little unclear at this point when you say it is failing which method you are using. Are you creating a native 64-bit installer, or trying to install the 32-bit and 64-bit files in a single 32-bit setup using the plugin?

[artistscope]

Ok, I feel that we have done a full circle and the issue is still not resolved.

1. I am creating an installer with SUF9 that is being run on a 64-bit computer
2. The OCX is being installed to the correct folder
3. SUF9 is supposed to be self-registering the 64-bit OCX
4. SUF9 is failing to register the OCX

I don't need to read the documentation to realise that I wasted my time and money upgrading to SUF9!

[Ulrich]

Yes, when I wrote about building a 64-bit installer, I meant exactly that. I am not sure why you mention it as "dedicated", because no 64-bit executable can be run on a 32-bit operating system, so they are all implicitly "dedicated".

Yes, of course you can build 64-bit installers in Setup Factory on a 32-bit platform. It looks as it is time that you have a look into the documentation.

Ulrich

[artistscope]

Do you mean a dedicated 64-bit installer? Or do you mean create the installer on a 64-bit computer?

I am running a 32-bit computer, so can I make installers for 64-bit?

[Ulrich]

The installer is being run on a 64-bit computer. It has been verified that the OCX is registerable on a 64-bit computer.
But SUF is not registering the OCX.

You need to build a 64-bit installer (which you couldn't with Setup Factory 8) if you want to use the self-registration of the 64-bit control on a 64-bit operating system.

Ulrich

[artistscope]

If I create a script to run SysWoW64 how will it succeed when the inbuilt function doing the very same thing in SUF9 fails?

[artistscope]

If you are building a 64-bit installer, then self-registration should work correctly for the 64-bit control on a 64-bit platform.

The installer is being run on a 64-bit computer. It has been verified that the OCX is registerable on a 64-bit computer.

But SUF is not registering the OCX.

SUF8 was creating installers for both 32 and 64-bit no problem, and the only reason for upgrading to SUF9 was to properly register 64-bit OCX. If I have to create a script to do the job then I could done that with SUF8 and saved the price of upgrading!