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

Posted

技术标签:

【中文标题】当我们在 Visual Studio SSIS 项目中点击调试按钮时——它是在 32 位还是 64 位模式下运行——32 位提供程序是不是与 64 位运行模式兼容?【英文标题】:When we hit the debug button in visual studio SSIS project - does it run in 32 or 64 bit mode - and is 32bit provider compatible with 64bit run mode?当我们在 Visual Studio SSIS 项目中点击调试按钮时——它是在 32 位还是 64 位模式下运行——32 位提供程序是否与 64 位运行模式兼容? 【发布时间】:2021-08-28 05:56:55 【问题描述】:

我有一个安装了 Visual Studio 的新 VM。

我创建了一个新的 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 位模式的 runtime/provider?

假设没有更改设置,当按下调试按钮时,程序执行是 32 位还是 64 位模式?操作系统位数对此有什么影响吗?

【问题讨论】:

【参考方案1】:

你说的很对,也很近。

因为 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 一样,您必须匹配这些外部库的位大小。

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

【讨论】:

默认情况下,假设不更改设置,当按下调试按钮时,程序执行是32位还是64位模式?操作系统位数对此有什么影响吗? 默认是任何 cpu,因此有了以上信息,您总是可以获得应用程序的 x32 进程内运行实例。因此什么都不做,这意味着任何 CPU 的默认设置,因此您将始终获得运行 x32 位的应用程序。不,操作系统位数不会改变这一点。唯一的操作系统位问题当然是如果 PC 是 x32 位操作系统,那么当然永远不能使用 x64 位项目设置。但如前所述,如果您从 VS 外部运行 .exe,则任何 CPU 都意味着项目将根据您启动的命令行提示符版本运行(其中有两个 x32 和 x64 cmd.exe) 但是如果您只是双击该 .exe 的快捷方式?如果您的项目设置为 ANY,则在大多数情况下,您会运行 x64 位版本。因此,从 VS 启动时,任何 cpu = 始终为 x32。但是,当从 Windows 命令行启动或从文件中单击时,相同的 .exe 将几乎总是以 x64 位启动。因此,任何 CPU 都会承担启动 .exe 的“进程”或系统。因此从 VS - x32 启动。从文件探索而不是从 VS 启动 - 您将运行 x64 位版本。 当然,如果操作系统是 x32,那么从 VS 或命令行(或文件资源管理器)中,它将始终是 x32,并且您永远无法将 .exe 作为 x64 运行在仅限 x32 操作系统。 在我的项目属性中,调试设置显示为 64 位。但我没有访问 64 位访问运行时。所以我很困惑它是如何读取 msaccess 文件的

以上是关于当我们在 Visual Studio SSIS 项目中点击调试按钮时——它是在 32 位还是 64 位模式下运行——32 位提供程序是不是与 64 位运行模式兼容?的主要内容,如果未能解决你的问题,请参考以下文章

SSIS 包在 Visual Studio 和命令行中有效,但在代理中无效

SSIS 项目在 Visual Studio 中构建,但不是来自 Devenv 命令行

Visual Studio 2019安装SSIS

部署 SSIS 包时 Visual Studio 2012 崩溃

在 Visual Studio 2012 / 2013 中使用 SSIS BIDS

为什么我的ODBC连接在Visual Studio中运行SSIS加载时失败,而在使用Execute Package Utility运行相同的包时则失败