0

我创建了一个使用 AnyCPU 构建的 ADO.NET 数据提供程序。直接引用时,它在 64 位和 32 位 Windows 操作系统上都可以正常工作。但是,在我的安装程序中,我使用 .NET machine.config 注册了我的 DbProviderFactory,并将我的程序集放在 GAC 中,以便用户可以通过 System.Windows.DbProviderFactories 访问数据提供程序。只要应用程序以 32 位运行,此功能就可以很好地工作。它不适用于为 x64 构建的应用程序。

这就是我发现的。我的安装程序针对 32 位。因此,我的 DbProviderFactory 只会添加到 32 位 .NET machine.config。为了让 x64 应用程序通过 DbProviderFactories 使用我的数据提供程序,它需要使用 64 位 .NET machine.config 进行注册。

我必须有两个安装程序吗?一个针对 32,另一个针对 64?我所有的程序集都是 AnyCPU(因为我不知道也不关心用户的应用程序是什么平台)。

我有点复杂的解决方案是这样的。在安装过程中,我有自定义操作来检查操作系统是否为 64 位(此处)。如果是,我想启动一个运行 64 位控制台应用程序的进程,它将我的 DbProviderFactory 添加到 machine.config(64 位)。我的安装程序本身将使用 32 位 machine.config 进行注册。我尝试过但失败了,因为我不能在以 32 位为目标的安装项目中拥有 64 位程序集。但是,我将尝试使用 AnyCPU 构建控制台应用程序,假设它将在 64 位操作系统上作为 64 位进程运行。

这相当混乱,但我认为它会起作用。为什么这是个坏主意?以及为什么微软说“要将 .NET Framework 应用程序同时分发到 32 位和 64 位平台,构建两个 MSI 包,一个针对 32 位计算机,另一个针对 64 位计算机”(msdn)。因为从技术上讲,我所有的程序集都是 AnyCPU,它会起作用吗?

另外,我正在使用 .NET 3.5

4

1 回答 1

1

回答我自己的问题:

1) 我不需要 32 位和 64 位安装程序。但是,这只是因为我所有的程序集都是 AnyCPU。

2) 这不是一个坏主意,而是一个好主意,因为我只需将一个安装程序分发给客户端,它会神奇地为 64 位机器执行额外的安装操作。

3)如果程序集或包含的引用是为 32 位或 64 位显式构建的,我认为 M$ 表示同时拥有两个安装程序。

最终解决方案:在我的 32 位安装程序中,我在 machine.config 中注册程序集。然后我检查操作系统是否为 64 位(使用我的问题提供的链接)。如果是,我会启动一个为 AnyCPU 构建的命令行实用程序(包含在我的安装程序中),作为一个单独的进程。该实用程序在 64 位 machine.config 中注册我的程序集。这是因为 AnyCPU 实用程序仅在 64 位操作系统上作为新进程启动,并假设它将默认为 64 位进程。完毕。

于 2011-08-08T09:08:09.403 回答