Switch to C:\Program Files (x86) ?


  • Our application is .NET, compiled for AnyCPU platform.  It has always installed into C:\Program Files on 64-bit Windows.

    For our app's next version, we will be compiling all our EXEs for x86 (DLLs will continue to be AnyCPU), because we want to force them to always run in 32-bit mode (we have a good reason for doing this, but that's irrelevant).

    Since our app will now be 32-bit, we are supposed to install into C:\Program Files (x86).  However, this is going to result in some nasty migration issues that we have to deal with (our app allows add-ons developed by other business partners, and those are installed into C:\Program Files).

    We could solve this problem simply by continuing to install into C:\Program Files.  But what would be the repercussions of doing so, if any?

    Thursday, October 13, 2011 2:29 PM

All replies

  • If you are certain that your partners code will break, then it seems clear that they are doing the wrong thing because they have been hardcoding C:\Program Files. If they are doing it the right way, then their code will ask for Environment.SpecialFolder.ProgramFiles (or any number of equivalent APIs) and if they are 32-bit then they will get the (x86) folder automatically. So you may be assuming that your partners don't know how to code, and before assuming that I hope you actually check.

    I'm not sure whether Windows will care if you have 32-bit programs in the 64-bit folder - it might. Your code or your clients code may fail when asking programmatically for the Program Files folder. It wil get the (x86) folder, but that's not where you're actually installed.  If some of your clients hardcode C:\Program Files and others use APIs to get the location then you're hosed either way, and the only thing you can do is tell your clients to use the APIs to find out where you are installed, which is what they should have been doing all along.

    Phil Wilson
    Thursday, October 13, 2011 6:19 PM
  • The issue is not that our partners' code will break.  In fact, our add-on's are distributed via package files (like .gadget or .apk files) and installed by our application itself; so they get placed in the correct folder.  They will run fine, regardless whether they are located in C:\Program Files or C:\Program Files (x86).  They obtain folder paths correctly (e.g., Environment.SpecialFolder), and do not have hard-coded paths.

    I really don't want this thread to focus on the specifics of our application.  Basically, my question is will we be violating some important Windows policy by continuing to install what used to be a 64-bit app but is now a 32-bit app into C:\Program Files.  If so, what potential problems could we run into?


    Thursday, October 13, 2011 9:08 PM
  • As long as your code don't care where it is launched from. Is there any reason you want to write code to access the parent folder?

    Windows does treat the program files folder differently (e.g. file system redirection to virtual store), but it looks like you are not writing to program files.

    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Friday, October 14, 2011 11:06 PM
  • Thanks for the reply.  We don't write to program files.
    Saturday, October 15, 2011 1:03 AM
  • nrcaliendo wrote:
    >For our app's next version, we will be compiling all our EXEs for x86 (DLLs
    >will continue to be AnyCPU), because we want to force them to always run in
    >32-bit mode...
    I didn't realize that would work.  So, an AnyCPU DLL JITs to match the
    bittedness of the process it's loading into?
    Tim Roberts,
    Providenza & Boekelheide, Inc.

    Tim Roberts, VC++ MVP Providenza & Boekelheide, Inc.
    Saturday, October 15, 2011 3:56 AM
  • Correct.  All assemblies are JIT'd at runtime (assuming no native image created by NGEN exists), regardless whether it targets x86, x64 or AnyCPU platform.  However, the fate of those that target x86 or x64 is predetermined at compile time.  AnyCPU allows you to essentially postpone the determination of bitness to runtime.  Moreover, an x86 assembly can only ever be consumed by a 32-bit process, and an x64 assembly by a 64-bit process.  AnyCPU will allow a DLL to match the bitness of the consuming EXE, and therefore be loaded into any process.  AnyCPU EXEs will compile to 64-bit on a 64-bit OS, or to 32-bit on a 32-bit OS.

    Because of its flexibility, AnyCPU is useful for components shared by multiple apps, which may not all run at the same bitness.

    Saturday, October 15, 2011 12:05 PM
  • Hi nrcaliendo,

    I am seeking the same solution as you are looking, fortunately I did find it.


    If your 32-bit application designed to install into C:\Program Files\AppName, you can first check if any folder named [AppName] under C:\Program Files, if so, delete it first. Then create the folder [AppName] in your C:\Program Files (x86)\AppName, run the below command:

    mklink /d "C:\Program Files\AppName" "C:\Program Files (x86)\Appname"

    Then the two folder will link together, whenever the files installed into Program Files or Program Files (x86), they pointed to the same physical file path, could be working fine. I did fix my problem by this, hope it's working for you as well. :)

    Friday, March 09, 2012 1:17 AM