There is a Windows API [1] that will turn off the compatibility mode. Something like:
Wow64DisableWow64FsRedirection There are also flags [2] that can be added to the RegCreateKeyEx that will allow you to manipulate the registry for the other. [1] http://msdn2.microsoft.com/en-us/library/aa384187.aspx [2] http://msdn2.microsoft.com/en-us/library/aa384232.aspx You really just need to be aware of this and program for it during installation. CHad -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Adam Sills Sent: Monday, March 19, 2007 2:18 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] moving code from a 32 to a 64 bit server Right I didn't mean the installer was being lied to; it's not being lied to it's being given the x86 compatibility location. The program is being lied to, since there is no separate "give me a 64 bit program files" request, only "give me program files". And since .NET 2.0 is native 64 bit, it's being given the correct directory; if you have a 32 bit .NET app run, it will be "lied to" (redirected) to the x86 compatibility directory. Adam.. -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Friday, March 16, 2007 2:19 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] moving code from a 32 to a 64 bit server IMO the system isn't lying - the install is just wrong. The 64-bit program files folder is the [ProgramFiles64Folder] property in Windows Installer - that's what the 64-bit install should specify as the app folder to install into. Similarly there's a CommonFiles64Folder. Phil Wilson -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Adam Sills Sent: Thursday, March 15, 2007 3:21 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] moving code from a 32 to a 64 bit server Our installer was the biggest problem. Our application is about a million lines of C# code (very few of those are p/invoke and even fewer in a C++ DLL or two) and there really wasn't any work we had to do from a code standpoint. On 64 bit Vista (and XP 64) our applications by default ran as 64 bit apps (they were .NET 2.0 apps and there is a 64 bit CLR on both platforms) due to the AnyCPU Platform target that is the default. The only real problem we had was our registry keys and program files installed files were being installed into 32 bit compatibility locations on the box (HKLM\Software\Wow... and Program Files (x86)). Our installer (InstallShield 11.5) requires manual work to indicate a component is 64 bit-compatible to tell the MSI package to install in the 64 bit locations on the box. When a 32 bit application runs and asks for a registry key or for a common file path, the system will lie to them and redirect the request. My installer asked for "[ProgramFilesFolder]" and received "Program Files (x86)". My programs ask for it and get back "Program Files" like I expect. We tested by manually copying our registry keys and other dependent files on the box and we had zero problems running as a native 64 bit .NET application (even our 3rd party UI controls had no issues for us). What we actually ended up doing (at least in the interim) is compiling our applications against x86 Platform (instead of AnyCPU) so when our programs run and ask for registry keys and common file paths, the system tells us the same for both (Vista 64 sees our apps are 32 bit, when we ask for ProgramFiles we get "Program Files (x86)"). My situation may be different from yours, especially if you have a lot of C++ code. We have next to none so it was a surprisingly easy transition (thank you, managed execution environment). Adam.. -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Smotritsky, Alex Sent: Thursday, March 15, 2007 4:24 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: [ADVANCED-DOTNET] moving code from a 32 to a 64 bit server I'm interested in hearing peoples thoughts on this - like is a recompile necessary and such. =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
