Developing with same .Net solution on x86 and x64 OS - references to program files dlls

I'm working in an environment where some developers are working on an x86 environment (still WinXP) and others are working on a 64bit enviroment (Windows Server 2008 R2). The solution has a lot of references to DLLs that live in Program Files. On 32 bit env this is fine, but when moving to 64 bit, these references fail, as they should be pointing to "c:\Program Files (x86)" - every time the solution is checked in and reopened in another environment, the references need to be updated. Is there are nice way to support both environments, or is it simply a case of having to have separate s开发者_StackOverflow中文版olution/project files with different references for each architecture?

Update: Apologies, it appears I was mistaken. The solution was initially created on 32 bit. When I opened it on 64bit, there were issues with references hitting different versions of the dll, so i updated the reference (on 64 bit). When I checked in changes and then re-opened on 32bit, I then got the problem that the (x86) folder didn't exist, and hence the reference was not found. Once I corrected the location (and version) of the references on 32bit, checked it back in, got latest and opened it on 64bit, all was good. Thanks for your time.

---

I would recommend copying your references out of "Program Files" and into a local "Dependencies" folder. You can add the references from there, which will always use a relative path. Since these references are not installed to the GAC (this wouldn't be an issue otherwise), this will keep you from having to change your settings constantly.

---

One solution is to create an NT reparse point on 32 bit machines such that "Program Files (x86)" simply refers to "Program Files". This is what we do.

You can create reparse points using the SysInternals junction utility or perhaps mksymlink if you have a later OS.

---

how about a post-build step to copy from x86 to regular program files ? we are having similar issues and this is more of just thinking out-loud solution