如题，为啥呢？或者说32为就够了 没有必要开发64位的去浪费开发成本？
------解决思路----------------------
vs部分，你编译程序时，可以选择x86或者64位
------解决思路----------------------
这个问题在去年的TechEd大会上被专门提到。
我把我听到的告诉你，微软说，的确有无数的开发者提议微软开发64bit的Visual Studio，但是微软没有这么做，是因为微软调查了绝大多数的深层需求，他们之所以期待64bit的Visual Studio，是因为他们认为64bit的程序可能拥有更高的性能。但是实际上不是这么回事，64bit程序在x86-64处理器上并不会带来明显的性能提高，它只是增加了处理器的寻址范围，可以使用更大的内存。而对于VS这种并非内存敏感的程序，并不十分需要迁移到64bit下。另外，还有一个历史原因，就是微软一直没有完成64bit下的JIT调试器的Edit and Continue功能，这是因为64bit的JIT是C++团队做的，和原生CLR团队的32bit JIT有很多不同，微软现在正在试图统一两者。如果微软推出了64bit的VS，那么调试的体验会受到限制，这也是为什么微软一直以来没有推出64bit VS的原因。
------解决思路----------------------
还有一个历史原因，就是微软一直没有完成64bit下的JIT调试器的Edit and Continue功能
这才是真正的原因
------解决思路----------------------
何必纠结VS，应该纠结开发出来的产品经常性在64和32转换出各种状况。
------解决思路----------------------
好像没有什么影响。
我碰到过唯一的问题好像就是编译成x64的库，其中如果有winform控件的话，没法放到winform designer上。
------解决思路----------------------
没必要，可以编译和调试x64就行了，IDE本身x86反而比较省资源
------解决思路----------------------
在最近的6、7年，鲍尔默和（或者）辛诺斯机控制微软技术走向的这几年，微软出现了许多严重的技术问题。比如在.net平台方面，有必要一定要让程序员们这么“折腾” 32bit 还是 64bit吗？一些小程序员可能喜欢多背诵点新奇的术语，拿技术术语去应对那些“火大了的”需要软件维护的客户，可是这一点也不好玩儿。
真正好玩儿的就是让程序员在编译产品时真正可以几乎忘记去配置和操心32bit、64bit的问题。不需要什么 AnyCPU、x64、x86之类地去选择，也能保证产品发布了之后稳定可用。
但是我觉得微软没有能力协调各个团队。不是技术上做不到，也不是没有这方面巨大的需求，而是没人有能力搬倒官僚管理者。
------解决思路----------------------
整年纠结在此，而不是建立在比他们更高层次上去化解它。