Presumably the filesets are different - ie the 32 bit project has 32 bit files, and the 64 bit project has 64 bit files, so handling this with a single project is not practical.

When you start a new project, you get presented with a drop down menu where you select either a 32 bit or 64 bit project. This setting controls whether the component attributes are set to indicate that the component is 64 bit. Consequently, just changing the summary page property to 64 bit is not going to make your project file 64 bit, as you will need to change all the component properties and of course substitute the 64 bit files for the previous 32 bit.

So for your own sanity, having separate projects for 32 bit and 64 bit is the best way to go.

You will need to edit every component to set the attribute value that indicates the component is 64 bit.
Frankly, creating a package from scratch carries less risks of missing something than trying to edit your existing project.

Thanks for the reply. I have one more question.
Hereafter we will be having two installers, one for 32bit and the other for 64bit. Still now we used to install in 64bit machines as 32bit installer which we had already.
Suppose if the user have installed version 5 of our product (which has only 32bit) in some 64bit machine. Now if the user wants to install version 6 of our product which has the installer specific to 64bit in the same machine. The requirement is to uninstall the old version and install the new 64bit version of the product.

In order to get that done, should i use some wrapper to uninstall the existing product if found or Can i do it from Wise Installer itself?

The old version would have copied all the binaries under Program Files (x86) folder and the new installer should copy to  Program Files folder.

Thanks for the Help,
Panneer.

I have not tried creating a 64 bit upgrade to a 32 bit applications yet.
However, were I to do so, the first thing I would try would be to create the 64 bit MSI, then specify the previous 32 bit MSI as a version to upgrade, making sure that the RemoveExistingProducts custom action is re-sequenced so that it is located between InstallValidate and InstallInitialize. In this position, the custom action ensures that the previous version is removed completely before the new version is installed.
The one point I would suggest you also consider carefully, is whether there are any services involved, or any files that are "in use" when you come to run the upgrade, as this scenario normally requires a reboot to get rid of locked files which need deleting. Accordingly, if you have any such files or services, it will be necessary to include actions to stop services and ensure that all files are unlocked prior to the uninstall.

If this approach does not work, then I would be looking to create a wisescript wrapper which would handle the uninstall of the 32 bit application and follow with the install of the 64 bit application. My only concern here would be whether the 32 bit wisescript process could successfully kick off msiexec to run in 64 bit mode.

When you execute a wisescript EXE, any command line attributes you pass to the EXE are automatically loaded into the %CMDLINE% variable, which you can parse in your EXE as required.
The only thing to beware of, is that predefined command line options (such as /s /m /x etc) are stripped out before the remainder are passed to the %CMDLINE% variable.
You will find information about %CMDLINE% and other predefined variables in the Wisescript Editor documentation.

You cannot pass property values as command line arguments to the wisescript, as the command line arguments are treated as TEXT only.

Can I point you in the direction of the Wisescript command "Get Windows Installer property" ??
That is what you need to use if you want to read a property value into a Wisescript variable.