你说的很对，也很近。
因为 Visual Studio 是 x32 位？
那么，如果您的项目设置为 x86（x32 位）或设置为任何 CPU？
然后按 F5 运行 + 调试（或 ctrl-F5 运行不调试的 .exe），然后您将获得（拥有）一个 x32 位运行程序。这里有些谨慎。如果你使用任何CPU？然后再次从 VS f5 运行 - 你得到一个 x32 位进程。
但是，如果你转到 windows 命令行呢？
好吧，如果您启动 Windows x64 位命令行（大多数计算机上的默认设置），那么如果项目是任何 cpu？然后你的应用程序运行将是 x64 位。 （以及任何未管理的代码，例如 Access，或用于 COM 自动化的任何其他 Windows 代码？它会中断。
如果您启动 windows x32 位命令行（使用任何 CPU），那么您将运行 x32 位版本。
所以，从 VS - F5 - 总是 x32 位。
从 Windows 命令行 - 取决于。
那么，上面的建议是什么？好吧，如果您的意图是 + 使用 x32 位进程？然后根据您的意图强制/设置项目。这样，“偶然”就不会欺骗您，您的应用程序将始终按照项目设置运行。
所以，在这种情况下，我确实避免使用任何 CPU。
现在，如果您将项目强制为 x64 位会发生什么？比如这个：
好吧，如果您选择 x64 位？ （不是任何 cpu，也不是 x86）。
然后按 f5（或 ctrl-F5），它将以 x64 位的进程内运行应用程序。我不太确定 VS 是如何工作的，但他们有某种“桥”，可以将 x64 位调试器编组以与 VS x32 位对话。
因此，如果您将项目强制为 x64，那么它将始终以 x64 位运行 - 包括来自 VS。
所以，这意味着：
if you set project to x64 bits - use a connection builder in settings?
You can use the connection builder but since (we assume) that you using
访问 x64 位？那么VS中的测试连接按钮将永远无法工作。
但是，如果您以 x64 运行代码，并且可以访问 x64，那么它将工作。所以只有测试连接按钮失败 - 这是由于 VS 是 x32。
如果您的 Access 版本错误（例如 x32 位），并且您的项目设置为 x64？然后连接构建器将工作，甚至测试连接也将工作（因为测试连接总是来自 VS 的 x32 位）。这具有您建立连接，点击测试连接的效果 - 它说好！但是当你运行项目（f5，ctrl-f5）时，项目运行为 x64，它会失败（这个例子假设 x32 位）。
现在这是从 VS 构建一个编写代码。我不知道用 Visual Studio 构建的 SSIS 包有什么不同。但我们不想将 Visual Studio (VS) 与 sql studio 或其他系统混淆 - 它们没有像 VS 项目那样的项目“cpu”或“位”设置选项。
所以，我非常建议如果您的意图是 x32 位操作，那么总是将 VS 项目强制为 x32 位，因此是时候从 Windows 启动该 .exe，那么它永远不会以错误或未运行的方式运行预期的位大小。
我没有测试过 SISIS 集成项目，但如果从 VS 构建它？然后再次强制/设置项目位大小。
实际上消除了错误位大小的“机会”？然后将项目强制为开发人员打算在此处使用的给定位大小 - 这样就不会有机会。
有时您想使用任何 CPU。一个非常好的示例是当您构建类库代码以共享多个项目时。在这种情况下，任何 cpu 都是不错的选择，因为从那时起，即使是强制使用 x32 或 x64 的项目也可以引用那些外部程序集和库代码。
但是，如果您将这些外部程序集强制为给定的位大小，则只有运行该正确位大小的项目才能使用此类库。
.net 代码（托管）与非托管代码不同。如果您选择任何 cpu，.net 代码能够运行“任一个”x32 或 x64。但是非托管代码（外部非 .net 代码，例如 Access）不能像 .net 代码那样动态更改。我使用“on the fly lost here”这个词。自从一次.net 程序开始运行 x32 或 x64？在终止之前，它会保持该位大小。
因此，任何 CPU 都适用于您编写的外部类库代码，因此希望包含在任何项目中。但是主项目 .exe 程序必须使用一些外部非 .net（非托管）代码？然后你会很好地强制项目位大小设置。
然后回答你最后一个问题？
如果提供者是 .net 提供者，例如 sql 提供者或其他什么？然后是托管代码 - cpu 设置无关紧要。仅当您开始使用不受管理且不是 .net 代码的外部代码系统时。 MS-Access 就是这样一个常见的例子。任何 windows c++ 甚至很多商业程序都是如此。
例如。 Sage/Simply 会计和 Quickbooks 会计？他们提供 .net SDK 来连接这些帐户包。但是它们只有这些桌面程序的 x32 位版本——而且它们不是 .net 程序。因此，一旦再次，您最好将项目强制为 x32 位。
因此，没有 x64 位进程可以消耗 x32 位进程。您也不能使用不匹配的外部库。
但是，如果该库代码和系统是 .net（托管代码），并且是使用任何 CPU 编译和创建的，那么您在使用任何 CPU 时没有任何限制，甚至在使用这些库时都没有任何限制。强制 .net 项目 cpu 设置。
所以整个系统只有在你引入或开始使用外部代码库时才会崩溃。
例如，如果您使用 .net ghostscript 库？它们有两个版本 - x32 和 x64。因此，就像 MS-Access 一样，您必须匹配这些外部库的位大小。
对于 Adobe PDF 来说，这实际上是一个非常讨厌的问题。他们的 pdf 查看器仅支持 x32。事实上，这只是——上个月他们开始提供他们的 PDF adobe 阅读器的 x64 位版本。毫无疑问，他们开始这样做是因为 Office 现在正朝着 x64 位而不是 x32 位系统/程序发展。