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 回答