我们将获得新的开发机器，并升级到Vista 64 Ultimate，以利用我们的8GB内存。我们的经理希望我们在32位虚拟机中进行所有开发工作，以确保我们的代码进入生产环境不会有任何问题。

有什么方法可以保证生成的程序可以在32位操作系统上运行吗？
我不介意使用虚拟机，但是我不喜欢它们如何迫使我们返回"单一"监视器类型视图。我喜欢将VS工具栏移到其他显示器上。

编辑：我们正在使用Visual Studio 2005和2008，VB.NET和/或者C＃

编辑：使用Harpreet的答案，这些是我用来设置Visual Studio IDE来编译x86 / 32bit的步骤：

• 单击生成并打开配置管理器
• 选择活动解决方案平台下拉列表
• 如果在列表中，请选择x86，否则请跳至步骤5. 选择" <新建...">
• 在"新解决方案平台"对话框中，选择" x86"，然后按"确定"。
• 验证为所有项目选择的平台是x86
• 单击关闭。

享受。

谢谢，
基思

解决方案

回答

对于64位OS进行编译是编译器中的一个选项。我们可以从Vista 64位中绝对编译为32位exe。当我们运行该应用程序时，我们可以在TaskManager中看到该进程旁边有一个" * 32"……这意味着它是32位的；)

我相信经理需要更多地了解64位操作系统的真正含义：)

回答

只要我们将可执行文件编译为32位，它们就可以在32位和64位Windows计算机上运行(保证)。使用64台开发机的优势在于，我们可以使用64位编译开始测试代码(以检查指针是否转换为32位整数)，这样一来，将来转换到64位的过程就更容易了(我们应由公司选择)做一个64位版本)。

回答

不是我们问题的答案，而是可能是我们问题的解决方案：VirtualBox(可能还有其他)支持"无缝集成"模式，该模式仅提供第二个开始栏，并允许我们自由拖动窗口。

另外，这是对我们问题的答案，这取决于编译设置。我们可以针对不同的环境进行编译，并且可以使用Visual Studio在64位系统上完美地编译32位程序。无法告诉我们如何使用，但是我敢肯定，某些​​Visual Studio专家可以。

回答

是的，就像亚当说的那样。有3个选项：MSIL(默认)，x64和x86. 我们可以定位x64，它将生成专门用于64位系统的dll，或者我们可以运行x86，它将在32位和64位系统上运行，但与在64位系统上的32位系统具有相同的限制。

MSIL基本上将让JITer发出平台特定的指令(与本地映像相比，性能会有所降低)

编辑：没有语言，所以我说的是.net框架语言，例如vb.net和c＃，C ++是完全不同的动物。

回答

我在用于32位Windows的64位计算机上进行开发。这算不上问题。为了保守起见，应确保将项目设置为以x86模式编译。我们将要遍历解决方案中的每个项目，并仔细检查。我们还可以使用AnyCPU设置，但是这样做的风险会更高一些，因为它在开发机上的运行方式与32位机上的运行方式不同。当然，我们要避免使用64位模式。

我遇到的问题是当应用程序针对64位编译(显式为64位或者AnyCPU编译并在64位Windows上运行)时无法使用的驱动程序。坚持使用x86编译可以完全避免这些问题。那应该揭示开发机器上的所有缺陷。

理想情况下，我们可以设置可以在32位计算机上频繁执行的构建和测试环境。这样可以使管理放心，并避免将VM用作桌面。

回答

我们使用VS 2005开发了一个32位应用程序(即将在2008年推出)，并且刚刚购买了一些新机器，它们上装有XP Pro x64或者Vista Business 64位，以便我们可以利用额外的RAM并同时观看有关如果有商业需要，可以使用64位端口。除了在开发环境中调整一些脚本等之外，我们在此方面没有任何问题。

那些未包含在此升级周期中的开发人员仍然使用32位计算机，因此在检入之前自然会在单元测试和应用程序测试套件运行时遇到问题。

我们还要做的是确保我们有一组由"典型"配置(XP / Vista，2/4/8内核等)组成的"测试构建"机器，用于构建和测试签入集在将它们添加到适当的集成区域之前，我们具有各种用于稳定性，性能等方面的测试套件。同样，这些都不会对运行基于64位OS的32位应用程序带来任何问题。

无论如何，正如其他人已经说过的那样，我不希望这是一个问题，因为是由编译器为目标OS生成适当的代码，而不管编译器实际运行于哪个OS上。

回答

今天发现了这一点：

http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

x64 Development with .NET
  
  Earlier this year I made the switch to a 64-bit operating system - Vista Ultimate x64 to be exact.  For the most part, this process has been relatively painless, but there have been a few hiccups along the way (x64 compatible drivers, mainly, but that's not the point of this discussion).
  
  In the world of x64 development, there have been a few struggling points that I thought I'd outline here.  This list will likely grow, so expect future posts on the matter.
  
  In the wonderful world of .NET development, applications and assemblies can be compiled to target various platforms.  By default, applications and assemblies are compiled as Any CPU in Visual Studio.  In this scenario, the CLR will load the assembly as whatever the default target is for the machine it is being executed on.  For example, when running an executable on an x64 machine, it will be run as a 64-bit process.
  
  Visual Studio also provides for 3 specific platform targets:  x86, x64 and Itanium (IA-64).  When building an executable as a specific target, it will be loaded as a process of that type.  For example, an x86-targeted executable run on an x64 machine will run as a 32-bit process using the 32-bit CLR and WOW64 layer.  When assemblies are loaded at runtime, they can only be loaded by a process if their target matches that of the hosting process, or it is compiled as Any CPU.  For example, if x64 were set as the target for an assembly, it can only be loaded by an x64 process.
  
  This has come into play in a few scenarios for me:
  
  
  XNA - XNA is available as a set of 32-bit assemblies only.  Therefore, when referencing the XNA assemblies, the executable/assembly using them must be targeted to the x86 platform.  If it is targeted as x64 (or as Any CPU and run on a 64-bit machine), an error will be thrown when trying to load the XNA assemblies.
  Microsoft Robotics Studio - The XInputGamepadService uses XNA internally to talk to the Xbox 360 controller.  See above.
  Managed DirectX - While this is already deprecated and being replaced with XNA, it still has its uses.  The assemblies are not marked for a specific target, however I had difficulty with memory exceptions, especially with the Microsoft.DirectX.AudioVideoPlayback assembly.
  Phidgets - Depending on what library you download and when, it may or may not be marked as 32-bit only.  The current version (11/8/07) is marked as such, and so requires a 32-bit process to host it.
  The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application.  To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.
  
  
  The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application.  To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.