当我们在 Visual Studio SSIS 项目中点击调试按钮时——它是在 32 位模式还是 64 位模式下运行——并且 32 位提供程序是否与 64 位运行模式兼容？

问题描述

我有一个安装了 Visual Studio 的新虚拟机。

我创建了一个新的 SSIS 项目，并尝试使用 oledb 数据源任务来访问 .accdb MS-Access 文件。

但是我看不到提供者。所以我安装了 Access 32 位运行时。现在我可以看到提供者了。我正在阅读，因为 Visual Studio 是一个 32 位工具，我们必须安装 Access 32 位运行时。否则如果我们安装 64 位运行时，那么我们将无法在列表中看到提供程序，因为 Visual Studio 是 32 位并且只显示 32 位提供程序。

当我点击 Visual Studio SSIS 项目中的调试按钮时，它可以访问 MS-Access 文件。我现在很困惑，想问 - 项目运行时，它是在 32 位模式还是 64 位模式下运行？如果答案是 64 位模式，那么它如何使用 32 位提供程序访问 MS-access 文件？这是否意味着在 64 位模式下运行的项目可以使用 32 位模式运行时/提供程序？

假设没有改变任何设置，当按下调试按钮时，程序执行的是 32 位模式还是 64 位模式？操作系统位数对此有影响吗？

解决方法

你说得对，而且离这里很近。

因为 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”或“bit”设置选项。

所以，我非常建议如果您的意图是 x32 位操作，那么始终将 VS 项目强制为 x32 位，因此是时候从 Windows 启动该 .exe，那么它永远不会以错误或未运行的方式运行预期位大小。

我没有测试过 SISIS 集成项目，但是如果从 VS 构建它呢？然后再次强制/设置项目位大小。

实际上消除了错误位大小的“机会”？然后将项目强制为开发人员打算在此处使用的给定位大小 - 这样就不会碰巧了。

有时您想使用任何 CPU。一个很好的例子是当您构建类库代码以共享项目时。在这种情况下，ANY cpu 是一个不错的选择，因为那时强制使用 x32 或 x64 的 EVEN 项目可以引用那些外部程序集和库代码。

但是，如果您将这些外部程序集强制为给定的位大小，那么只有运行该正确位大小的项目才能使用此类库。

.net 代码（托管）与非托管代码不同。如果您选择任何 cpu，.net 代码能够运行“任一”x32 或 x64。但是非托管代码（外部非 .net 代码，例如 Access）不能像 .net 代码那样即时更改。我使用术语“在此处即时丢失”。因为一旦.net 程序开始运行 x32 或 x64？它保持那个位大小直到终止。

因此，任何 CPU 都适用于您编写的外部类库代码，因此希望包含在任何项目中。但是主项目 .exe 程序必须使用一些外部非 .net（非托管）代码？那么你会很好地强制项目位大小设置。

然后回答你最后一个问题？

如果提供者是 .net 提供者，例如 sql 提供者或其他什么？然后是托管代码 - cpu 设置无关紧要。只有当您开始使用不受管理且不是 .net 代码的外部代码系统时。 MS-Access 就是这样一个常见的例子。任何 windows c++ 甚至很多商业程序都是如此。

例如。 Sage/Simply 会计和 Quickbooks 会计？他们提供.net SDK's 接口到那些accountning 包。但是他们只有这些桌面程序的 x32 位版本——而且它们不是 .net 程序。因此，一旦再次启用，您就可以很好地将项目强制为 x32 位。

因此，没有 x64 位进程可以消耗 x32 位进程。您也不能使用不匹配的外部库。

但是，如果该库代码和系统是 .net（托管代码），并且是使用任何 CPU 编译和创建的，那么您在使用任何 CPU 方面都没有任何限制，甚至在您使用这些库时也没有任何限制强制 .net 项目 cpu 设置。

因此，只有当您引入或开始使用外部代码库时，整个系统才会崩溃。

例如，如果您使用 .net ghostscript 库？它们有两个版本 - x32 和 x64。因此，就像 MS-Access 一样，您必须匹配这些外部库的位大小。

对于 Adob​​e PDF 来说，这实际上是一个非常讨厌的问题。他们的 pdf 查看器仅适用于 x32。事实上，这只是 - 上个月他们开始提供他们的 PDF adobe 阅读器的 x64 位版本。毫无疑问，他们开始这样做是因为 Office 现在正朝着 x64 位而不是 x32 位系统/程序发展。