Error 1706. No valid source could be found for product....

[DandamanAUS]

When double clicking on a file .bp7 which is the custom file extension in windows for our SQLite database it should open up our application with it.
This is fine in our previous version.
Also it is fine for the current installation if the previous version is uninstalled manually and then this new one is installed.
HOWEVER if the new one is installed over the top of the old one then the file association results in
"Error 1706. No valid source could be found for product . The Windows Installer cannot continue."

Its trying to look for the .msi file in
C:\Users\DANIEL~1.BRO\AppData\Local\Temp\{14E757C3-B00B-4179-99C4-4960C2064602}\
Why on earth does it need to do that the file association is just supposed to launch our application with the file?
Why is it looking for the msi in the temp location... doesn't windows store the files in the ProgramData Package Cache?
If I drag the file onto the application .exe then it opens fine.

Does someone know the root cause of this issue?
This new installation is a bit more complex because it handles both x86 and x64 where as the previous one was only x86.
x64;1033 vs Intel;1033

I don't want to tell our users to manually uninstall the existing version the install the new one... as InstallShield should be able to do all this as the major update.
Or does my 64-bit compatible installer break some rules?

[Jenifer]

Dandaman wrote:
When double clicking on a file .bp7 which is the custom file extension in windows for our SQLite database it should open up our application with it.
This is fine in our previous version.
Also it is fine for the current installation if the previous version is uninstalled manually and then this new one is installed.
HOWEVER if the new one is installed over the top of the old one then the file association results in
"Error 1706. No valid source could be found for product . The Windows Installer cannot continue."

Its trying to look for the .msi file in
C:\Users\DANIEL~1.BRO\AppData\Local\Temp\{14E757C3-B00B-4179-99C4-4960C2064602}\
Why on earth does it need to do that the file association is just supposed to launch our application with the file?
Why is it looking for the msi in the temp location... doesn't windows store the files in the ProgramData Package Cache?
If I drag the file onto the application .exe then it opens fine.

Does someone know the root cause of this issue?
This new installation is a bit more complex because it handles both x86 and x64 where as the previous one was only x86.
x64;1033 vs Intel;1033

I don't want to tell our users to manually uninstall the existing version the install the new one... as InstallShield should be able to do all this as the major update.
Or does my 64-bit compatible installer break some rules?

Hi,

There are quite few things to ponder about:

This specific issue deals with component-file associations generally:http://helpnet.flexerasoftware.com/installshield23helplib/helplibrary/FileAssociations.htm

I could see file association specific issue with 64-bit in few windows Microsoft forums too.

One more relevant forum topic:https://community.flexerasoftware.com/showthread.php?200007-File-Extension-Association-not-working

Everywhere they state that when you create new component it doesn't create issue,have you tried creating 64-bit component association for x64 installer?

Thanks,
Jenifer