visual-studio - 当我们在 Visual Studio SSIS 项目中点击调试按钮时——它是在 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。一个非常好的示例是当您构建类库代码以共享多个项目时。在这种情况下，任何 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 方面没有任何限制，甚至在强制使用 .净项目cpu设置。

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

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

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

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

问题描述

解决方案

推荐阅读