This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: x64 support with .NET AnyCPU assemblies
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 10, 2010
02:27 PM
x64 support with .NET AnyCPU assemblies
Is there any way to force a 32-bit installer to install stuff to the 64-bit Program Files directory? Making two installer is absolutely not an options as my product is an enterprise level application and we are supporting admin installations so one installer needs to support installing on 32bit and 64bit operating systems. My application is mostly .NET assemblies that have been built with AnyCPU to support either type of operating system.
I am using an InstallScript MSI project. I have everything else in the installer setup to support both 32bit and 64bit OSes except being able to install to Program Files instead of Program Files (x86). It is ridiculous to have to make two installer just to install to the correct program files folder when everything else can support both OS types.
Things I've tried include manually setting INSTALLDIR in the InstallScript to use the PROGRAMFILES64 property. Doing this sets the directory correctly and it displays to the user correctly but when you install the application it still puts the files in the x86 path which causes a major bug in my installer where if the user manually specifies the non x86 program files directory. When I try to run those installed files to do some setup or launch the application after the installation, these process don't run because the files weren't installed to the location the user selected so using the INSTALLDIR property gives me the wrong path for where the files were actually installed.
I've also tried using Disable (WOW64FSREDIRECTION) but this seems to be worthless. It still installs the files to the x86 path and if I make the call too early it breaks calls I make to windows API.
I've read a few post on these forums about setting the default TARGETDIR to use instead of but I am unable to find a way to do this. Changing the default INSTALLDIR in the General Information to use [ProgramFiles64Folder] didn't do anything. It still defaulted to the x86 folder when displaying the path to the user.
I've also read a number of post that look to be responded to by InstallShield support that says this is a limitation on windows installers but that seem ridiculous that they let you make .NET assemblies that are AnyCPU but you cant install them correctly. I know that InstallAware supports this functionality so I know it is possible.
Any help would be much appreciated. So far it seams I either need to default to the root of the drive or just install to the x86 path and not worry about it because the application runs the same no matter where it is installed. The whole x86 program files directory just seems pointless and causes problems for everything.
I am using an InstallScript MSI project. I have everything else in the installer setup to support both 32bit and 64bit OSes except being able to install to Program Files instead of Program Files (x86). It is ridiculous to have to make two installer just to install to the correct program files folder when everything else can support both OS types.
Things I've tried include manually setting INSTALLDIR in the InstallScript to use the PROGRAMFILES64 property. Doing this sets the directory correctly and it displays to the user correctly but when you install the application it still puts the files in the x86 path which causes a major bug in my installer where if the user manually specifies the non x86 program files directory. When I try to run those installed files to do some setup or launch the application after the installation, these process don't run because the files weren't installed to the location the user selected so using the INSTALLDIR property gives me the wrong path for where the files were actually installed.
I've also tried using Disable (WOW64FSREDIRECTION) but this seems to be worthless. It still installs the files to the x86 path and if I make the call too early it breaks calls I make to windows API.
I've read a few post on these forums about setting the default TARGETDIR to use
I've also read a number of post that look to be responded to by InstallShield support that says this is a limitation on windows installers but that seem ridiculous that they let you make .NET assemblies that are AnyCPU but you cant install them correctly. I know that InstallAware supports this functionality so I know it is possible.
Any help would be much appreciated. So far it seams I either need to default to the root of the drive or just install to the x86 path and not worry about it because the application runs the same no matter where it is installed. The whole x86 program files directory just seems pointless and causes problems for everything.
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 11, 2010
10:49 AM
Sorry, this is a limitation of Microsoft's Windows Installer; it's just not designed to handle AnyCPU executables in the way you want, and I agree that this is a sad limitation. See Heath Stewart's blog for articles like http://blogs.msdn.com/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx for more information.
If you don't need to deliver your package in an MSI file, you could switch to a (pure) InstallScript project, where it would be a lot safer and definitely more effective to work with the 64-bit folders like you describe. Your desired single package behavior is possible in such an InstallScript project, but not InstallScript MSI or Basic MSI projects.
If you don't need to deliver your package in an MSI file, you could switch to a (pure) InstallScript project, where it would be a lot safer and definitely more effective to work with the 64-bit folders like you describe. Your desired single package behavior is possible in such an InstallScript project, but not InstallScript MSI or Basic MSI projects.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 11, 2010
11:49 AM
Yeah, I've looked at that link before as it has been posted in a few other threads I found.
We want to be able to remotely install our product using WMI which as I understand it currently requires a MSI file.
Can you give me any more information about how using a pure InstallScript project supports the 64bit folders differently?
We want to be able to remotely install our product using WMI which as I understand it currently requires a MSI file.
Can you give me any more information about how using a pure InstallScript project supports the 64bit folders differently?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 11, 2010
02:25 PM
Correct me if I'm wrong -- but as your application is, it still RUNS as a 64-bit application, just one whose files are in the (x86) directory. This almost makes sense as you have an installer that is designed to work on both types of operating system, yet run slightly different on one with 64-bit architecture. That said, I have an application that was never specced to be distributed to 64-bit computers, but due to other reasons, we pushed support up and allowed it -and everything runs fine (we also published AnyCPU .Net assemblies/exe's that installed to the (x86) directory).
