为什么 x86 文件夹存在于 c Sharp 项目文件的 obj 文件夹中？
我的项目文件结构是
ProjectOne
----------Bin
--------------Debug
--------------Release
-------- --Obj
--------------x86 //为什么会这样？
-------------------调试
-------------------发布
----- 我的源文件。
为什么我的文件当前目录是 bin\debug，而不是 projectOne（我的源文件所在的位置）？
执行时，当前目录将默认为可执行文件所在的位置 - 将在您的 bin/debug 目录中。
不过，您可以设置在 Visual Studio 中启动它时希望它从哪里运行（在项目属性中 - 如果您需要更多详细信息，请准确说明您正在使用的 VS 版本/版本）。
至于obj目录的内容 - 你几乎可以忽略整个目录。它充满了 Visual Studio 构建然后使用的中间文件 - 但您几乎不需要直接使用那里的任何文件。
该x86文件夹指的是构建配置管理器中构建的目标平台。它允许您在 64 位操作系统上构建 32 位应用程序。正如 Cody 和 Jon 所说，您可以忽略该obj目录。
该bin文件夹包含您的应用程序的二进制文件（即您的可执行文件）。它被细分为两个（或更多）文件夹——通常是Debug和Release. 这些对应于您的构建配置。编译您的项目时，可执行文件将放置在这些文件夹之一中，具体取决于您执行的构建类型。如果要在开发环境之外运行可执行文件，可以单击在这些文件夹之一中找到的“.exe”文件。
如果您愿意，可以使用项目的“属性”窗口在编译期间更改 Visual Studio 输出可执行文件的位置。
该obj目录包含 Visual Studio 在编译应用程序时生成的中间（或对象）文件。这并不是您真正需要担心或使用其中的文件的事情。
最后，您的源文件保存在根目录中，如解决方案资源管理器窗口中所示。您自己管理这些文件的位置；它们不受 Visual Studio 管理。
目标文件（存储在 Obj 中的文件）是尚未链接的已编译二进制文件。将其视为最终可执行文件的片段，稍后将它们组合成您的可执行文件。
编译源代码时，每个源文件都会松散地编译为一个目标文件。为什么？没有理由*，只是您的特定编译器是如何编写的。其他语言中的其他编译器不会这样做，而是一步将所有内容编译成一个大型二进制文件。但是编写您的编译器的人决定首先编译为单独的目标文件。
现在，您可以想象，如果每个源文件生成一个目标文件，那么每次编译代码时，您的源目录最终会变得凌乱并充满大量 .obj 文件（实际上很多 C 编译器传统上都是这样做的）。随着时间的推移，从事大型项目的开发人员开始编写编译脚本或配置他们的项目以将所有 .obj 文件收集在一个目录中，以减少源目录的混乱。
编写您的编译器的人显然喜欢单独的 Obj 目录的想法，因此他们将其作为项目的默认配置。至于为什么会有一个 x86 子目录，那是因为您的编译器还支持其他 CPU，例如 ARM（适用于 Android、Win Phone 7 和 iPhone），并且还可以区分 32 位和 64 位。
* 注意：实际上有一些很好的理由这样做，包括使编译器代码更加模块化并支持增量编译，但事实上有些人可以在不生成单独的 obj 文件的情况下完成所有这些工作，这意味着这主要是由编译器的开发人员不仅仅是必需品。