Question: On a recent episode of [.NET Rocks](http://www.dotnetrocks.com/about.aspx) ([episode 404)](http://www.dotnetrocks.com/default.aspx?showNum=404), they mentioned that a lot of Visual Studio issues could be reduced if you set the platform target to be x86 instead of 'Any CPU'. I did a few Google searches and couldn't find anything about it. 

At my company we have a mix of 32-bit (x86) and 64-bit (x64) developer machines. There are some issues with losing references of third-party components installed under 'Program Files (x86)' vs 'Program Files' when switching back and forth between the developers on different machines. 

Would switching to target x86 machines fix this issue with 'Program Files (x86)'?

Also, are there sites or posts I can read more about this (I couldn't find any!)?

Answer: 
The underlying switch is `/platform:`. I suggest reading *[/platform (C# Compiler Options)](http://msdn.microsoft.com/en-us/library/zekwfyz4.aspx)* first.

If your third-party components are unmanaged code (or the assembly was built with anything but `/platform:anycpu`), you need to target 32 bit (unless the vendor provides a 64-bit version). It is just easier to target the lowest common denominator so building isn't complicated by creating one configuration for 64 and another for 32 bits.

Check out [an answer to Stack Overflow question *Should .NET 'Any CPU' projects bind to Framework or Framework64 DLLs?*](https://stackoverflow.com/questions/319585/should-net-anycpu-projects-bind-to-framework-or-framework64-dlls#319612) as well.
There are many posts on <http://blogs.msdn.com> that discuss the issues and the change in Visual Studio 2010. For example, *[AnyCPU Exes are usually more trouble than they're worth](http://blogs.msdn.com/b/rmbyers/archive/2009/06/09/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx)*.

Of course, no approach is perfect. Personally I think [WoW64](http://en.wikipedia.org/wiki/WoW64) is the worst thing Microsoft ever delivered, but it does help me sometimes.